Julian Gosnell wrote:
>Thanks for these, Heitzso,
>
>Very illuminating.
>
>May I ask what versions of Jetty you used in the tests
>?
>
>Thanks,
>
>
>Jules
>
jetty 3.0.6
>-- Heitzso <[EMAIL PROTECTED]> wrote: > >+ Somebody
>reported that Tomcat stalls at approx.
>
>>40 simultaneous requests.
>>
>>>+ Linux usually treat 100 apache better then one
>>>
>>JVM with 100 threads inside
>>
>>>(my personal opinion, no serious tests were made);
>>>
>>I have no idea about
>>
>>>Solaris and Windows.
>>>
>>Some notes re my experience pushing on this
>>(apache/tomcat and tomcat load)
>>
>>1) I've successfully pushed 1000 parallel requests
>>through tomcat w/ no
>>problem
>>Somebody scream -- there's bs going on here.
>>Actually, due to test harness
>>time in setting up threads some threads finished
>>before all 1000 threads
>>setup.
>>I experienced a large difference in how many threads
>>successfully
>>handled (and
>>elapsed time as viewed client side) depending on
>>server memory, -Xmx
>>setting, and JVM.
>>
>>2) I can't actually pinpoint where the max/min of
>>the response curve is on
>>this, but in a server with limited memory (and cpu?)
>>resources having
>>the combo
>>apache-tomcat can be worse than tomcat alone because
>>of memory
>>swap. So if you have heavy simultaneous requests
>>load the swap time can
>>be worse than the tomcat-slow time (assuming tomcat
>>threads alone
>>to bump into swap memory). For most people this is
>>not an issue,
>>but on memory constrained servers (i.e. 64M RAM) it
>>is a problem.
>>
>>Some data points where client and server on same
>>system that's not memory
>>constrained (750 Athlon, 3/4G RAM, debian unstable,
>>2.4.5 kernel):
>>
>> 600
>>parallel
>> #/s avg max avg max
>>
>>static jetty 8-9 .003-.009 .212@300 .003 .128
>>static tomcat 8-9 .008-.016 .670@600 .016 .670
>>soap jetty 6-8 .042-.330 2.300@200 .039 .715
>>soap tomcat 5-8 .047-2.826 4.837@50 .047 .722
>>
>>So, at 600 parallel requests I saw tomcat responding
>>worse
>>case less than a second for both static and soap
>>(read servlet)
>>response. Although other loads saw response times
>>as bad
>>as 2.3 sec (jetty) and 4.8 sec (tomcat) which I
>>assume were due
>>to garbage collection holdups.
>>
>>Contrast w/ memory constrained server apache static
>>responses over a network (several states separating
>>client/server, times in milliseconds):
>>
>>400 parallel calls to Apache ...
>>min 418, max 48664, average 26315, count 400
>>maximum number of simultaneous threads: 400
>>approximat requests per second: 7
>>
>>Note 26 sec average response time and 48 sec
>>max response time. Test page was bare minimum
>><html><head></head><body>test</body></html>
>>type of file.
>>
>>While I'm tossing out crude (and milage will vary)
>>numbers, Blackdown 1.3.0 (I know 1.3.1 is out,
>>haven't benched)
>>versus IBM jvm 1.3.0 (recent download) on Linux:
>>
>> 600
>>parallel
>> #/s avg max avg
>>max
>>static black. 55-158 .006-.010 .205@600 .007
>>.205
>>static ibm 8-9 .008-.016 .670@600 .016
>>.670
>>soap black. 17-26 .048-1.387 2.976@100 .296
>>1.812
>>soap ibm 5-8 .047-2.826 4.837@50 .047
>>.722
>>
>>Needless to say, it appears that someone optimized
>>blackdown
>>for some of these tasks. BTW, servlet container was
>>tomcat 3.2.2.
>>
>>There's also a developer at our shop who's
>>interested in
>>looking at green versus native threads on linux in
>>the belief
>>that the green threads may out perform native under
>>heavy
>>load. I haven't tested that variation.
>>
>>CONCLUSION: You really need to study your
>>own working load and server env. to assess optimum
>>combo of apache or apache-tomcat.
>>
>>Heitzso
>>
>>
>>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
