VOMS
Server Stress Test
Yujun Wu
(January 07, 2004)
1. Introduction
In order to test the performance and functionalities, a small shell
program has been written to test the overall functionalities and
scalabilities of VOMS.
The program is not intended to give a precise measurement on the VOMS
performance, but gave an estimate on the overall performance when many
users
query the VOMS server---although it is possible to parse out the
performance value based on the log info.
2. Mechanism
(1). It first generates a proxy using edg-voms-proxy-init;
(2). It then continuously queries the VOMS server using the -noregen
options provided by voms client.
Currently, only single-thread is used in the script, although a
multi-thread version can also be written.
3. Test results
(1). In August, we first used the small script to test VOMS Version:
1.1.20 and found a bug that causes the socket CLOSE_WAIT. That
is, "Everytime when VOMS get contacted, it causes a socket CLOSE_WAIT.
When the number of CLOSE_WAIT reaches a big number, the server hangs
without accepting
new request."
Vincenzo Ciaschini has fixed this bug.
(2). In September, we did another test on VOMS Version: 1.1.22. This is
the result I sent to Vincenzo:
"I run voms for about another 12 hours---after 36 hours run, with all
queries (about 95146) runs successfully. The server is quite stable and
handles everything nice. There is no visible memory leak. The only
thing I met is that there is a possible CPU buildup gradually when
doing the
query continuously."
Later discussion with Vincenzo reveals there was no thing wrong with
VOMS client/server themselves. It is more likely related to the
limit of MySQL
Database Server. I believe under normal usage, it should be fine if our
queries are less than 2/second. Or we have a more powerful server
machine.
I was using a desktop machine as the VOMS server.