Hi Costin.
[EMAIL PROTECTED] wrote:
> Hi Jason,
>
> First, it's really great to see the discussions about performance !
> Your tests are extremely usefull
I'm just returning the favor, after sitting through your ApacheCon session
about the Tomcat performance/benchmarking..
> I use ab and apache very often ( I used it as the main tool to tune
> tomcat
> 3.2 and now 3.3 ).
It's nice, isn't it? I was going to write something like it, but since
it was
already there, I just used it. Like I said, it's got a few bugs, but it
mostly
gives useful information, and works pretty well.
> One thing that strikes me is the fact that I have a
> slower computer ( Celeron / 363 ) my numbers for apache ( with -c 60 )
> are
> usually much smaller.
I may know why this is. Before running my benchmarks, I played with
ab quite a bit on both Apache and on Tomcat4. I wanted to tune the config
files to give me the best performance that I could get on my machine.
I ran lots of tests, changed config values (mainly threading or processing
limits and defaults), and re-ran tests to see how the changes in the config
files affected the performance outcomes. I eventually found what I believe
to be about the most optimal settings *for my machine* for both Apache
and Tomcat4. So, the configs I show in my tests have been tailored to my
machine -- its CPU speed, RAM size, everything. Another machine that
has different specs may not perform well with my machine's configs.. It
may actually perform worse.
I came to the conclusion that each different machine needs tailored config
files, and that there probably is a process that one could follow to
find the
optimal settings for a machine. I've even considered writing some automated
software to run overnight, all night long, benchmarking and tweaking the
configs until the performance of the server on that machine is optimal.
Do you realize how many servers could be substantially more efficient if
everyone did that? Just an idea, but I think I want to do it..
> ( it happens that I used the same test while
> rewriting the static servlet to StaticInterceptor )
> I did another run, here is the sumarry:
> ( ab -c 60 -n 10000 http://localhost/index.html):
>
> - Apache 1.3.12 - DEFAULT CONFIG, no change:
>
> First run: RPS: 344.44
> Total: 67 172 637
> Second run: RPS: 363.40
> Total: 85 163 268
>
> - Apache 1.3.12 - your config file
>
> First run: RPS: 261.27
> Total: 105 228 477
> Second run: RPS: 253.63
> Total: 81 234 402
I think this is good evidence that what I said above is in fact
happening. By raising the number of processes on your machine
(from the default) to the number of processes that are optimal
for my machine, your machine gets bogged down a little by
the weight of all those processes, and can't easily perform as
well as it did before with a smaller number of processes.
This also shows why it's a good idea that Apache's default config
file sets the defaults the way it does.
>
> - Tomcat 3.3 - IBM JDK1.3
>
> First run: RPS: 276.07
> Total: 46 216 3265
> Second: RPS: 345.55
> Total: 17 172 228
>
> - Tomcat 3.3 - Hotspot
> First: RPS: 287.5
> Total: 53 206 764
> Second: RPS: 308
> Total: 42 193 1134
>
> ( after another run the number get lower - almost same as IBM1.3 )
>
These numbers look pretty good.. did you also set the VM options
like "-Xms96m -Xmx96m"? On my machine, that made the maximum
times come down dramatically -- from the thousands of milliseconds
to the hundreds of milliseconds. Of course, with a different Tomcat. :)
It might do the same for yours though, again depending on your machine's
specs.
> Of course, tomcat3.3 is not yet completely tuned, and static file
> handling
> is still far away from what it should be. Also, note that neither apache
> nor tomcat3.3 will cache the file - you should use MMapFile to compare
> with a container that uses caching. ( that adds about 20% performance to
> apache - since Linux is also caching the file accesses are not a very big
> factor )
I think Tomcat4 does cache the file, but also checks just to make sure that
what it's caching hasn't changed on disk.
> ( BTW, last Apache2.0 I tried was almost 2x faster than 1.3 )
Yeah, that's about what I expect too. It can run in a multithreaded way
just like Java servers do. So, no more heavyweight processes to lug
around (not entirely sure this is a big deal on Linux, but on Solaris it
is, and on other OSs I think it is).
Cheers.
--
Jason Brittain
Software Engineer, Olliance Inc. http://www.Olliance.com
Current Maintainer, Locomotive Project http://www.Locomotive.org
