With httperf you can generate high load and it is easy to configure.
You can configure think time between requests. But with session handling on, we see some corrupted requests.
http://www.hpl.hp.com/personal/David_Mosberger/httperf.html
Peter
Mladen Turk schrieb:
Peter Lin wrote:
yeah, I can do that. ... I assume if i grab the nightly for 5.5.x and APR1.1.x I should be ready to go. In the event I need some assistance, you going to be around Mladen :) ?
Well, not at the midnight like your post was, but I'm sure it wasn't a midnight at your time zone :).
I've done testing on SLES9/64 with JDK5 and current apr release from apache (apr-1.1.1). The performance is equal or APR is slightly faster, but what's more important is the scalability for keep-alive connections. Now you can have hundreds of keep-alive connections without going over the thread limit.
Not sure how to test that, but I suppose that test for standard installation should include much higher maxThreads value then for APR implementation.
One other thing. Use some unix for Tomcat, or you will need to patch the APR for windows. The reason is that the APR uses standard windows FD_SETSIZE that is 64. I did recompile the apr with setting the FD_SETSIZE to 16384 before including winsock2.h, so we don't have that limit.
I did that because I thought that unixes has unlimited FD_SETSIZE, but it seems that the common value is 1024, so that is probably our limit for now. Think that we'll need multiple Poller threads if higher number is required. Anyhow don't test more then 1024 concurrent users at the moment, or 64 if using vanilla APR on windows.
More about testing: Right now the code waits for 50ms (configurable or will be) after the request for another keep-alive request, and then goes to the poller if the client didn't provide the request. So that would be valuable to test actually. Let's say that client sends each request with keep-alive in a 100+ ms rate. Not sure if JMeter can make a pause between the requests, but ab can not, and that is what we need to measure basically, since it's more close to the real-world then simply hitting the Tomcat in a loop.
Regards, Mladen.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
