How to compare tc4.1 and tc3.3. Was: Tomcat 4.1 slower than Tomcat 3.3

[Reinhard Moosauer <rm...@moosauer.de>]

Hi,

Am Mittwoch, 2. April 2003 18:30 schrieb Chris Agmen-Smith:
> Is Tomcat 4 slower than Tomcat 3?
>

For me, it is faster, see below.

> I've recently tried to port my Tomcat 3.3 webapp to Tomcat 4.1. It's the
> same webapp, the config files are as similar as I can make them, we're
> using the same connector to Apache. However, Tomcat 4.1 chews up CPU like
> you wouldn't believe.
>
> Example: at peak load, one of our Tomcat 3.3 servers served 20,000 page
> impressions in an hour, at an average %usr CPU of 60%. Using Tomcat 4.1, we
> can only serve about 7,000 pages if we down-weight it so that it is at 60%.
>

7,000 per hour is only 2 per second! This is very bad performance.
The old value of 20,000/h = 6 / second = 160 ms per request 
is still pretty heavy. This is a hint not to look in the container but in your 
application.
My experience is:
To compare the performance of a container (& JVM), its best to start with a 
minimal servlet or JSP. You can measure the overhead for the whole request 
process.
With tc4.1.24 and JDK 1.4.1 I have 1.3 ms per request on my 1.6G P4 for a 
minimal servlet. (=750 req/second)
With apache and mod_jk it's a little bit more.
This value is very good. Even compared to PHP4, which achieves only the value 
of tc+apache, but not the pure tc performance.
You can measure this easily with 'ab' or 'ab2' which comes with apache. You 
can even provide session ids to simulate real requests.
You will find tc 4 is faster than 3.3 here.

I have used tomcat for 3 years now and I found the JVM has had more influence 
to performance than the improvements of tc. (The old Sun Java2 JRE's had 
catastrophic performance, compared to IBMs JRE or the new 1.4 from Sun) 

> Old setup:
> Apache 1.3.x -> AJP 1.3 -> Tomcat 3.3.x -> webapp (uses Velocity 1.2 &
> Turbine 2.1)
>
> New setup:
> Apache 1.3.x -> AJP 1.3 -> Tomcat 4.1.x -> webapp (uses Velocity 1.2 &
> Turbine 2.1)
>

Next you should compare the data throughput. This can be done by serving big 
static pages or big JSPs without any intelligence.
(I would like to hear about the result)
 
> We have tried profiling the app using hprof and these are the results:
> Method                             Tomcat 3    Tomcat 4
> java.net.URLEncoder.encode         33.62%      22.60%
> java.net.SocketInputStream.read    14.15%      18.77%
> java.net.SocketOutputStream.write   1.87%       3.47%
>
> The encode method is used by Velocity and Turbine to generate URL links.
> For this particular test, T4.1 used about 1.5 times the CPU that T3.3 used.
> Given that the same number of pages & therefore links are being generated,
> I think this shows that T4.1 is spending significantly more time in
> SocketInputStream.read that T3.3.
>

You really should go to a more powerful profiler. This information is not 
enough to take action.
How about testing a another JVM?

> I have tried to following tuning options, even though they weren't needed
> in T3.3:
> - Removed servlet filters (no effect; not used in T3.3)
> - Reduced logging to bare minimum (no effect)
> - Experimented with numerous JVM settings: -server -d64 -Xmn256mb -Xmx384mb
> -Xconcurrentio (no effect)
> - Tried latest Solaris patches (no effect)
> - Tried 64-bit java (no effect)
> - Changed maxProcessor (# of threads) from default to 20 to 50 to 100 etc
> (no effect)
> - Changed Java/Solaris threading libraries (no effect)
>
> I don't have any more ideas how to fix it; instead I am clutching at straws
>

All these tests should better be done with a minimal servlet. You have to test 
it without your specific implementation.

> :o) Some of those straws include:
>
> - Tuning/hacking/fixing Turbine, in case it is incompatible with the
> Servlet 2.3 spec.
> - Trying even more JVM setting permutations, in the hope that I come across
> the "magic" combination.
> - Disabling socket keepalive in Apache.
>
> Until we can fix this, we are sticking with Tomcat 3.3, which has so far
> been stable, fast and robust (except for allowing sessions between https
> and http).
>

My advice: Take your time and test thourougly, find an optimal solution. 
Then switch.

Maybe it's a good time to check out where your application 'spends it's time'.
There could be a lot optimization possible, considering your long request 
times.
For new apps I found it useful to test out every new servlet or jsp with 'ab' 
and then document the performance.
So you have later a means of finding performance regressions easily.
(BTW: and you find multithreading flaws by simulation concurrent requests.)

Comments?

Kind regards,

Reinhard

> Chris Agmen-Smith

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org