Roy,
Thanks for the starting point on performance analysis for Tomcat 4.0! As we will
all find, benchmarking is an intriguing art. For example, the versions of
Catalina, the JVM, the OS, multiple processors, and memory size will all have
significant impacts.
One Tomcat 4.0 configuration setting that matters a great deal in scenarios like
this is the connection pool sizes (on the <Connector> element in
$CATALINA_HOME/conf/server.xml). The number of "processors" configured here
determines the maximum number of simultaneous request threads that Catalina will
set up -- default maximum is 75. A second setting that matters (but somewhat less
so) is the "acceptCount" property, that determines how many backlogged requests
the server socket will allow -- this becomes the "backlog" property when the
server socket is opened. The default is 10.
A very large chunk of Catalina's processing time is consumed by parsing the
request headers, and converting them into a Request object that is passed on for
processing. Volunteers who want one convenient place to start suggesting
improvements can look at org.apache.connector.http.HttpProcessor -- there is an
instance of this class running for each processor thread that is created.
The initial goal was correct behavior, which seems pretty well in hand. Now it's
time to make it faster, without giving up the correctness :-)
Craig
Roy Wilson wrote:
> 1) Ab with Apache_1.3.9 results
>
> When I ran ab with apache, I ran with concurrency C = 1 or C = 100. I
> initially thought that C had something do with the number of instances of
> httpd, but it seems to only indirectly: as load goes up (due to larger
> C), more children get spawned. What I noted is that ab+httpd CPU usage
> per request goes down slightly as C increases. This appears to be because
> accept(2) processing is "amortized" (as Dan Gaudet put it) over C
> connections. I ran with N = 100,000 because of variability in results
> observed when N was smaller. No errors were observed.
>
> 2) ab with tomcat4-4.0-m4
>
> With Tomcat4, there seemed to be some threading problems (thread queue
> lockouts, unknown threads waiting to be notified). I don't know enough
> about TC to be able to fix or even diagnose what's going on, but
> something does seem fishy to me: Once N and C become "large enough": ab
> quits producing output; the log files show an unknown thread waiting
> notification (possibly an artifact of my shell program); thread queue
> locking occurring (which seems like it might be serious); and cpu usage
> per request seems to INCREASE with C (in contrast with apache_1.3.9).
>
> I have a dual Celeron 400Mhz machine that I ran under a Redhat6.1 smp and
> a up kernel with the JDK1.2 ClassicVM (green threads). The smp kernel
> does suck (as noted by Dean Gaudet): thruput tends to DECREASE with
> increasing C, thread queue locking is noted in one of the log files, and
> ab produces nothing or garbage. I haven't bothered to record data from
> the SMP runs. I have 256MB SD100 memory and a WD Caviar disk (there's
> very little IO, as expected).
>
> Here are the summarized data, running the following command
>
> /usr/sbin/ab -n N -c C
> http://localhost:8080/examples/servlet/HelloWorldExample
>
> N (ab) C (ab) thruput/sec %CPU busy avg proc. time (ab) ms
> 1000 1 79.11 99.67 11
> 20 61.53 100 255
> 40 65.46 100 541
> 60 63.56 100 784
> 80 68.63 100 671
> 100 67.79 100 632
>
> 10000 1 83.95 100 11
> 20 78.21 100 283
> 40 75.41 100 680
>
> When N = 10,000 and C > 40 catalina.log shows an error mesg re: unknown
> thread waiting to be notified. Since the average number of active
> connections/threads is a function of the memory available and processor
> speed, I expect other people will see similar logfile entries with
> different N and C values. I'll send an updated, more flexible, version of
> the bash scripts today or tomorrow as I'm feelin' poorly. :-)
>
> Roy
> --
> Roy Wilson
> E-mail: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> 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]
