tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Solofnenko <>
Subject Re: Tomcat with 8 GB memory
Date Sat, 28 Jul 2007 16:53:18 GMT
I can only tell that we run performance testing for our platform and 
found that best performance was achieved by using a separate server per  
user (reusable pool). However the memory requirements were abysmal, so 
we are running two processes in parallel by default achieving good 
performance without requiring much more memory. But unlike [most] web 
applications we have a lot of long lived objects and maybe 
synchronization issues are the major factor in our case. That is why I 
say that only performance tests can say for sure.

- Alexey.

Caldarale, Charles R wrote:
>> From: Alexey Solofnenko [] 
>> Subject: Re: Tomcat with 8 GB memory
>> No, each of two 4GB processes will have only a half of the 
>> objects under the same load.
> There's a significant amount of objects created by the container and the
> webapps that are essentially permanent; with two JVM instances, you now
> have two copies of these, not just one.  The number of short-lived
> objects in existence during request processing is dependent on the
> number of concurrent requests, but not directly on the rate of requests.
>> And I heard that GC does not scale linear with heap size.
> This was true in the days of primitive GC algorithms, but the current
> ones are little affected by gross heap size.  Having labored under the
> old belief myself, I was somewhat surprised when measurements showed
> only very minor variations with different heap sizes.  (That probably
> has more to do with the lower L1/L2/L3 cache hit rates when using larger
> heaps rather than something inherent in the GC algorithms themselves.)
>> And this is without multi-threading performance considerations.
> Note that modern GC operations are parallelized, so reducing the number
> of CPU resources available by running multiple JVMs causes a given GC to
> run longer.  There is little interaction among the parallel GC threads,
> so lock conflicts and cache invalidations don't impact GC much.  (Which
> says nothing about whether or not a given app can benefit from more CPUs
> being available.)
>> As usual, your mileage may vary and only tests can tell for sure.
> Most definitely.
>  - Chuck
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail
> and its attachments from all computers.
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Alexey N. Solofnenko <>
Pleasant Hill, CA (GMT-8 usually)

View raw message