On Jan 5, 2006, at 3:41 PM, Duan, Nick wrote:
Thanks Michael for the info. J2EE performance testing depends on many
different factors. Some questions/suggestions for your consideration:
1. It wasn't clear from your report what the HW/SW spec of your test
clients (load workstation). Base on your test scenario, it looks
like
each load workstation would have to generate 200 - 400 user sessions.
If you were using 512 MB RAM in your client as the server, it may
not be
sufficient enough to handle the load.
The users were not evenly distributed across the load generating
hardware, because our software uses load balancing to distribute the
task of generating users. Web Performance Trainer will automatically
distribute users to the most capable load generating engines, and
will cease to add users to a load engine that is generating at it's
capacity. This way, the load generated at 1,000 users in our lab,
compared to the load generated by 1,000 different workstations, is as
close to identical as is possible (only cheaper).
That said, the load engines were (2) PIII's - 800MHz, 1 P4 - 2.4 GHz,
1 Xeon - 2.8 GHz, 1 Sun SPARC. The faster Xeon engine bore the most
significant portion of the load, though with the load distributed
across six workstations, all of the load engines were operating well
below their full capacity.
I hope that answers your question, but if you need more specific
information, please let me know.
2. What was the ramp-up rate? i.e. the number of users added per
second?
Part I ramped to 275 users in the first minute, +11 users / min for
each minute thereafter. Part II ramped to 400 users in the first
minute, +18 users / min each minute thereafter.
3. How were the timeout parameter configured in your tomcat
server and
client? I think many of the errors were caused due to server
timeout.
The timeout parameters were left at their default settings as a
baseline guide. Unfortunately, I don't have the client's timeout
parameters available to look up at this moment, but none of them
would be very short. For the tomcat server, those were of course:
connectionTimeout="20000" disableUploadTimeout="true"
In this test, timeouts would only be logged as errors if they occured
between the request and response. The server should be allowed to
terminate persistant connections without an error being recorded if
there were no connections pending.
4. What was the threading configuration on tomcat? If you have a
Pentium with HT, you can use a large number for configuring tomcat's
thread pool.
The threading configuration used was the default provided with tomcat
at installation time:
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
and, of course, the default pooling strategy.
It would be worth testing in the future to tune some of the thread
count parameters in order to determine how big they should be made,
but that will be left for another test.
Michael Czeiszperger
http://webperformance.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
