You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by John Goodleaf <jo...@goodleaf.net> on 2010/12/09 22:04:16 UTC
Tomcat 6 performance & multiple instances
Google is giving me too many different answers!
I need to serve a single webapp to a lot of people with acceptable latency.
There's no need for multiple contexts or any other funkines. Tomcat 6, JVM
1.6x. I have a hardware load balancer and two 64-bit machines (Windows 2003
Server--not my choice, yes I'd have preferred Linux) each with two CPUs and
8GB RAM.
I also have a consultant who insists we need to set up at least two,
possibly more, instances of Tomcat on each machine for good performance. I'm
more inclined to think that a single instance with tuned Java options will
provide the same performance, but be easier to set up and maintain. If I
needed to serve different webapps or somehow needed to separate things for
some reason, I could see it, but given just the one app/context. it seems
like multiple instances really amounts to second-guessing the OS scheduler.
Also notable: the servers are VMs.
Anyway, I'd appreciate advice, and I don't mind being wrong if you need to
side with the consultant. If it needs to be complicated to go fast, then
that's what we'll do... Ideally, I'd try both ways and hit it with JMeter,
but I lack the time and resources (because mgmt spent the money on our
consultant). So I must beg for answers here...
Thanks in advance.
J
Re: Tomcat 6 performance & multiple instances
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck,
On 12/9/2010 11:09 PM, Caldarale, Charles R wrote:
> I'm also very, very interested in the exact cause for the improvement
> observed with multiple JVMs using "another servlet container" - which
> may have no applicability to Tomcat.
Glad to see someone else is skeptical. I wonder what the environment
was, too: the JRE version is very sensitive: older versions of the
runtime were much slower for even uncontended locks, etc. and of course
GC gets better with every release.
- -chris
> It's worse than that - the compressed OOPs are relative as well, so
> it's an add and a shift. However, if you keep the heap size down (so
> that direct 32-bit pointers are used), that extra overhead is
> eliminated - but now you're constrained by a small heap.
I hadn't thought of them being relative, but I guess the OS is obviously
doing some virtual memory mapping as well. Heh... running a 32-bit JVM
will certainly speed-up memory access, as long as you're willing to live
inside a 1.6GiB heap :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0CcvAACgkQ9CaO5/Lv0PBw7wCggidq59l99UqxGuTRao1rLbtI
tvgAn2QXNYOHwEOo6tjCsEgeUrwTeYwn
=kA2h
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 6 performance & multiple instances
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Subject: Re: Tomcat 6 performance & multiple instances
> I'm not sold on the heap: if you have two GC processes running in
> parallel (that is, in separate JVMs) I'm not convinced that you are
> saving yourself any CPU time. Sure, the CPU time required in a single
> JVM might drop in half, but then you double the number of JVMs so you're
> back where you started. What kind of GC were you using?
There's also the issue of doubling the number of other daemon threads the JVM uses internally, such as the compiler threads, finalizer, reference handler, etc. They don't use much time, but they do take up resources.
I'm also very, very interested in the exact cause for the improvement observed with multiple JVMs using "another servlet container" - which may have no applicability to Tomcat.
> Using NUMA-aware GC would probably help.
Not available on Windows.
> Er, do you mean "compressed OOPs"? I think that will actually slow
> things down, since it requires an extra ADD (more likely SHIFT)
> operation to decode each OOP when referencing the associated object.
It's worse than that - the compressed OOPs are relative as well, so it's an add and a shift. However, if you keep the heap size down (so that direct 32-bit pointers are used), that extra overhead is eliminated - but now you're constrained by a small heap.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 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.
Re: Tomcat 6 performance & multiple instances
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tony,
On 12/9/2010 5:15 PM, Tony Anecito wrote:
> I have done alot of work with another servlet container and your
> consultant is correct. More instances do make a difference. Mainly
> because certain resources like ports/threads and memory management
> for the heap it makes sense.
Ports shouldn't be an issue, though dispatching requests to threads
could be depending on the connector in use. Can you give us an example
of the resource contention you saw drop dramatically with a simple JVM
split?
I'm not sold on the heap: if you have two GC processes running in
parallel (that is, in separate JVMs) I'm not convinced that you are
saving yourself any CPU time. Sure, the CPU time required in a single
JVM might drop in half, but then you double the number of JVMs so you're
back where you started. What kind of GC were you using?
> But you still need to test to determine what works best.
Thank you for saying that, regardless of any other comments ;)
> I agree about the context funkyness. Been there done that. I went
> from 2 cpu to 6 cpu (AMD not Intel) and then tuned my html page size
> and that made a huge difference. My own IT group was floored by the
> performance. My web service response times are down in the 1.5msec
> range using Tomcat and APR. I used to have around 1msec but I think
> the CPU management and added cpu count caused that to happen.
Please clarify: did you simply get a bigger box and experience leaps and
bounds of performance increases, or are you saying that you got a bigger
box /and/ split into multiple JVMs? I just want to be clear... in your
first paragraph above, you said that John's consultant was right and
were very vague about why things might go faster. In the second
paragraph, you talk about upgrading memory and tweaking application
settings and /then/ the IT folks were happy with the performance
characteristics you observed. Were these two separate incidents, or was
everything together? It's just not that surprising to me that tripling
the number of CPUs would improve your webapp's performance -- though
most applications are /not/ CPU bound in my experience.
> Remember to turn off services you do not need and use NUMA and any
> other settings that might help
Using NUMA-aware GC would probably help.
> like operand compression for the 64-bit jvm if you use it.
Er, do you mean "compressed OOPs"? I think that will actually slow
things down, since it requires an extra ADD (more likely SHIFT)
operation to decode each OOP when referencing the associated object.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0BoDEACgkQ9CaO5/Lv0PCC7ACfdOoID8pktL/L0zYboY9MEvNo
l8cAn35NZTxMIqRI56LXNAhxStvwx5w9
=6Y5h
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 performance & multiple instances
Posted by Tony Anecito <ad...@yahoo.com>.
Hi,
I have done alot of work with another servlet container and your consultant is
correct. More instances do make a difference. Mainly because certain resources
like ports/threads and memory management for the heap it makes sense. But you
still need to test to determine what works best.
I agree about the context funkyness. Been there done that. I went from 2 cpu to
6 cpu (AMD not Intel) and then tuned my html page size and that made a huge
difference. My own IT group was floored by the performance. My web service
response times are down in the 1.5msec range using Tomcat and APR. I used to
have around 1msec but I think the CPU management and added cpu count caused that
to happen.
Remember to turn off services you do not need and use NUMA and any other
settings that might help like operand compression for the 64-bit jvm if you use
it.
Regards,
Tony Anecito
Founder/CEO
MyUniPortal (2010 JavaOne Dukes award)
http://www.myuniportal.com
----- Original Message ----
From: John Goodleaf <jo...@goodleaf.net>
To: users@tomcat.apache.org
Sent: Thu, December 9, 2010 2:04:16 PM
Subject: Tomcat 6 performance & multiple instances
Google is giving me too many different answers!
I need to serve a single webapp to a lot of people with acceptable latency.
There's no need for multiple contexts or any other funkines. Tomcat 6, JVM
1.6x. I have a hardware load balancer and two 64-bit machines (Windows 2003
Server--not my choice, yes I'd have preferred Linux) each with two CPUs and
8GB RAM.
I also have a consultant who insists we need to set up at least two,
possibly more, instances of Tomcat on each machine for good performance. I'm
more inclined to think that a single instance with tuned Java options will
provide the same performance, but be easier to set up and maintain. If I
needed to serve different webapps or somehow needed to separate things for
some reason, I could see it, but given just the one app/context. it seems
like multiple instances really amounts to second-guessing the OS scheduler.
Also notable: the servers are VMs.
Anyway, I'd appreciate advice, and I don't mind being wrong if you need to
side with the consultant. If it needs to be complicated to go fast, then
that's what we'll do... Ideally, I'd try both ways and hit it with JMeter,
but I lack the time and resources (because mgmt spent the money on our
consultant). So I must beg for answers here...
Thanks in advance.
J
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 performance & multiple instances
Posted by Pid <pi...@pidster.com>.
On 12/9/10 9:04 PM, John Goodleaf wrote:
> Google is giving me too many different answers!
>
> I need to serve a single webapp to a lot of people with acceptable latency.
> There's no need for multiple contexts or any other funkines. Tomcat 6, JVM
> 1.6x. I have a hardware load balancer and two 64-bit machines (Windows 2003
> Server--not my choice, yes I'd have preferred Linux) each with two CPUs and
> 8GB RAM.
>
> I also have a consultant who insists we need to set up at least two,
> possibly more, instances of Tomcat on each machine for good performance.
I'm late to this thread, but I'd still be interested to hear the
reasoning behind the above. There are (largely historical) reasons for
doing this for some setups, but I don't see it as required/standard
practice for high performance sites.
(Maybe we don't know enough about your environment.)
p
> I'm
> more inclined to think that a single instance with tuned Java options will
> provide the same performance, but be easier to set up and maintain. If I
> needed to serve different webapps or somehow needed to separate things for
> some reason, I could see it, but given just the one app/context. it seems
> like multiple instances really amounts to second-guessing the OS scheduler.
>
> Also notable: the servers are VMs.
>
> Anyway, I'd appreciate advice, and I don't mind being wrong if you need to
> side with the consultant. If it needs to be complicated to go fast, then
> that's what we'll do... Ideally, I'd try both ways and hit it with JMeter,
> but I lack the time and resources (because mgmt spent the money on our
> consultant). So I must beg for answers here...
>
> Thanks in advance.
> J
>
Re: Tomcat 6 performance & multiple instances
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John,
On 12/9/2010 5:15 PM, John Goodleaf wrote:
> I agree [about benchmarking] and wish I had the time and resources to
> do it. I need to deploy on very short timelines. There actually was a
> performance testing phase budgeted, but it got killed after the
> "business owner" dragged her feet on requirements early in the
> project. Not that I'm bitter or anything...
So... there was a benchmarking stage planned, but it's been bagged in
favor of a consultant who simply tells you how to improve performance
without any way to verify that the "improvements" are accomplishing
anything?
> The application in question is pretty damned fat. It's typical corporate
> bloatware (it's an interface to Documentum). However, there are few
> operations that are noticeably more memory intensive than others. Many parts
> of the app actually rely on pushing an applet to the client. There are
> several of these applets, each relatively small, and they account for about
> 1 in 25 transactions based on my admittedly sketchy profiling. (User
> operation profiling; I have not profiled the code.)
Pushing an applet to a client should be roughly equivalent to the client
downloading static content. Are you saying that those transactions are
minimal (/only/ 1 in 25) or quite frequent?
> There is a pool as you describe, and it will be a big, deep pool. The other
> edge probably applies though.
How many simultaneous requests do you expect to service at any one
point? The connection pool only needs to be (roughly) that big. Also,
you can't possibly use more db connections than the (sum of) maxActive
setting(s) on your Connector(s) in a single Tomcat instance. How big are
we talking?
The good part about synchronization on something like a db connection
pool is that only the borrow/return operations are synchronized... the
duration of the borrow is not relevant to performance -- except that
obviously connection unavailability for other requests might be an
issue. If you have a big enough pool, though, then you shouldn't be
worried about that.
> The app is fairly stable. However, it requires IE 6 or 7 (don't blame me)
> and insofar as I've seen stability problems, it has more to do with IE. In
> other words, on the vast majority of hangs/freezes/whathaveyou, the server
> logs show no problem at all. The catch is on the IE side. In any case, I
> don't anticipate crashing JVMs.
So, your clients crash but the server hums along? I guess if MSIE is the
client platform, that's the best you can do :)
(To be fair, MSIE 9 looks great... finally. It only took Microsoft 4
versions to get MSIE to be good again.)
> I'll see what I can get him to cough up. My suspicion is that he's
> repeating a formula arrived at long, long ago by a guy who doesn't work
> there any longer. I have not observed him to possess any special skills in
> the Apache/Tomcat arenas.
If he tells you to change all your StringBuffers to StringBuilders then
you know he's just wasting your time ;)
> Thanks for your well written and thoughtful response. Can I hire you as a
> consultant?
If you're serious, contact me off-list if you need anything specific.
I'm willing to give general advice for free on the list. ;)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0BkM8ACgkQ9CaO5/Lv0PDTSwCfe071+s3ijKMckFo+2qQXUYOL
7IoAn2aZ/48ujp42XbJ98UmIr1ZlssO3
=7dyR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 performance & multiple instances
Posted by John Goodleaf <jo...@goodleaf.net>.
On Thu, Dec 9, 2010 at 1:28 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John,
>
> On 12/9/2010 4:04 PM, John Goodleaf wrote:
> > Google is giving me too many different answers!
>
> :(
>
> > I need to serve a single webapp to a lot of people with acceptable
> latency.
>
> That ought to be possible. What is "acceptable latency" for your system?
> Do you just want to get byte 1 as fast as possible? Or do you mean that
> you want total response times to be "acceptable"?
>
I guess that IS a bit vague. I think the measure the users will use
implicitly is "page turn." Total response time, in other words.
>
> > There's no need for multiple contexts or any other funkines. Tomcat 6,
> JVM
> > 1.6x. I have a hardware load balancer and two 64-bit machines (Windows
> 2003
> > Server--not my choice, yes I'd have preferred Linux) each with two CPUs
> and
> > 8GB RAM.
>
> Sounds good. You didn't mention what kinds of CPUs you have. Since they
> are 64-bit, they are probably of reasonably recent manufacture.
>
They are VM, so, fake 2.4Ghz Xeon
>
> > I also have a consultant who insists we need to set up at least two,
> > possibly more, instances of Tomcat on each machine for good performance.
>
> At this point, I'm skeptical of that argument, though under certain
> conditions it might make sense.
>
> > I'm
> > more inclined to think that a single instance with tuned Java options
> will
> > provide the same performance, but be easier to set up and maintain.
>
> I agree with you thus far -- without any other requirements being
> indicated.
>
> > If I
> > needed to serve different webapps or somehow needed to separate things
> for
> > some reason, I could see it, but given just the one app/context. it seems
> > like multiple instances really amounts to second-guessing the OS
> scheduler.
>
> Not really, since the threads in one instance aren't that different than
> the threads in multiple instances. What you're doing is limiting the
> effectiveness of things like VM-based synchronization, etc.
>
> > Also notable: the servers are VMs.
>
VMWare ESX. I do not know exactly which ESX version (hosting provider walls
this off...).
>
> Hmm... which one? Some of them have terrible performance under certain
> conditions. For instance, we have some OpenVZ instances that have
> horrible I/O performance, stalls, etc. while the CPU seems to be great.
>
> > Anyway, I'd appreciate advice, and I don't mind being wrong if you need
> to
> > side with the consultant. If it needs to be complicated to go fast, then
> > that's what we'll do... Ideally, I'd try both ways and hit it with
> JMeter,
> > but I lack the time and resources (because mgmt spent the money on our
> > consultant). So I must beg for answers here...
>
> Honestly, benchmarking should be the root of all your decisions when
> performance is concerned.
>
> I agree and wish I had the time and resources to do it. I need to deploy on
very short timelines. There actually was a performance testing phase
budgeted, but it got killed after the "business owner" dragged her feet on
requirements early in the project. Not that I'm bitter or anything...
> A couple of thoughts on the whole thing:
>
> Each JVM has a minimum amount of memory under which it can possible
> operate. Running multiple JVMs (as opposed to a single one) on a single
> machine will inflate the amount of memory required for the whole system
> with no perceivable benefit in and of itself. If your consultant tells
> you that the garbage collector will have to work less, he or she is
> right in that each JVM will (likely) have fewer objects to deal with but
> then you've got two (or more) GCs operating on the same set of CPUs, so
> it's basically a wash.
>
> Since Java is greedy about memory, it's generally best to give the JVM
> as much memory as you can afford to. If you split a JVM into two JVMs,
> you're lowering the ceiling of each JVM's max memory and potentially
> opening yourself up to an OutOfMemoryError if you have certain
> operations that require lots of memory. This is a very tough thing to
> get a handle on, since any operation that could potentially take down a
> "small" JVM can certainly take down a big one, too. But, if the
> memory-heavy operations are relatively infrequent, or you can limit the
> number of simultaneous memory-heavy operations, you can have more of
> them running in one big heap than in two (or more) smaller ones.
>
The application in question is pretty damned fat. It's typical corporate
bloatware (it's an interface to Documentum). However, there aref ew
operations that are noticeably more memory intensive than others. Many parts
of the app actually rely on pushing an applet to the client. There are
several of these applets, each relatively small, and they account for about
1 in 25 transactions based on my admittedly sketchy profiling. (User
operation profiling; I have not profiled the code.)
>
> Monitor locks (aka synchronization) can be "improved" by running
> multiple JVMs. Let's say you have a shared resource that is very
> popular. One obvious example is a database connection pool. If you have,
> say, 1000 threads actively requesting connections from that pool,
> contention is relatively high for the lock that protects the integrity
> of the pool regardless of the size of the pool. If you split into two
> JVMs, then you only have (on average) 500 active threads fighting for
> the lock, and you may see performance improve slightly. There is another
> edge to that sword, though: you are likely to sacrifice any performance
> gains with (somewhat) limited contention by putting another component in
> front of Tomcat to decide which JVM handles the request.
>
There is a pool as you describe, and it will be a big, deep pool. The other
edge probably applies though.
>
> If you have an unstable application, running additional JVMs (that is,
> more than your hardware and/or network setup requires) can help
> alleviate those stability problems: instead of 1/2 of your users getting
> their sessions expired because the webapp and/or JVM crashed, you might
> be able to get away with 1/4 or 1/8 of your users being interrupted.
> That's only a stop-gap solution, though: you should fix your webapp :)
>
> The app is fairly stable. However, it requires IE 6 or 7 (don't blame me)
and insofar as I've seen stability problems, it has more to do with IE. In
other words, on the vast majority of hangs/freezes/whathaveyou, the server
logs show no problem at all. The catch is on the IE side. In any case, I
don't anticipate crashing JVMs.
> Finally, if you are running a fault-tolerant website with all the
> bells-and-whistles, you are probably using either distributable sessions
> or something reasonably comparable (webcache, etc.). In those cases, the
> overhead of communicating session information between the JVMs will kill
> your performance many orders of magnitude faster than any single-JVM
> inefficiency you could find.
>
> I'd be happy to hear specific reasons why multiple JVMs would improve
> the performance of a webapp. Tell your consultant you want those
> specifics, and definitely let us know so we can comment on them. Who
> knows... he or she may have some good points that I hadn't considered.
>
> I'll see what I can get him to cough up. My suspicion is that he's
repeating a formula arrived at long, long ago by a guy who doesn't work
there any longer. I have not observed him to possess any special skills in
the Apache/Tomcat arenas. I'm not expert by a longshot either, but then I'm
not billing $200/hr to give people information on the topic. (I don't mean
to be too hard on him, he's likable and definitely expert in other topics.)
Thanks for your well written and thoughtful response. Can I hire you as a
consultant?
J
Hope that helps,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0BSgkACgkQ9CaO5/Lv0PD1vwCgwmTCWUxp8itw9wuUjS4o7ANd
> o2EAn2L7iz1PGo3q3jUTB902RnE5U/4i
> =sKEt
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat 6 performance & multiple instances
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John,
On 12/9/2010 4:04 PM, John Goodleaf wrote:
> Google is giving me too many different answers!
:(
> I need to serve a single webapp to a lot of people with acceptable latency.
That ought to be possible. What is "acceptable latency" for your system?
Do you just want to get byte 1 as fast as possible? Or do you mean that
you want total response times to be "acceptable"?
> There's no need for multiple contexts or any other funkines. Tomcat 6, JVM
> 1.6x. I have a hardware load balancer and two 64-bit machines (Windows 2003
> Server--not my choice, yes I'd have preferred Linux) each with two CPUs and
> 8GB RAM.
Sounds good. You didn't mention what kinds of CPUs you have. Since they
are 64-bit, they are probably of reasonably recent manufacture.
> I also have a consultant who insists we need to set up at least two,
> possibly more, instances of Tomcat on each machine for good performance.
At this point, I'm skeptical of that argument, though under certain
conditions it might make sense.
> I'm
> more inclined to think that a single instance with tuned Java options will
> provide the same performance, but be easier to set up and maintain.
I agree with you thus far -- without any other requirements being indicated.
> If I
> needed to serve different webapps or somehow needed to separate things for
> some reason, I could see it, but given just the one app/context. it seems
> like multiple instances really amounts to second-guessing the OS scheduler.
Not really, since the threads in one instance aren't that different than
the threads in multiple instances. What you're doing is limiting the
effectiveness of things like VM-based synchronization, etc.
> Also notable: the servers are VMs.
Hmm... which one? Some of them have terrible performance under certain
conditions. For instance, we have some OpenVZ instances that have
horrible I/O performance, stalls, etc. while the CPU seems to be great.
> Anyway, I'd appreciate advice, and I don't mind being wrong if you need to
> side with the consultant. If it needs to be complicated to go fast, then
> that's what we'll do... Ideally, I'd try both ways and hit it with JMeter,
> but I lack the time and resources (because mgmt spent the money on our
> consultant). So I must beg for answers here...
Honestly, benchmarking should be the root of all your decisions when
performance is concerned.
A couple of thoughts on the whole thing:
Each JVM has a minimum amount of memory under which it can possible
operate. Running multiple JVMs (as opposed to a single one) on a single
machine will inflate the amount of memory required for the whole system
with no perceivable benefit in and of itself. If your consultant tells
you that the garbage collector will have to work less, he or she is
right in that each JVM will (likely) have fewer objects to deal with but
then you've got two (or more) GCs operating on the same set of CPUs, so
it's basically a wash.
Since Java is greedy about memory, it's generally best to give the JVM
as much memory as you can afford to. If you split a JVM into two JVMs,
you're lowering the ceiling of each JVM's max memory and potentially
opening yourself up to an OutOfMemoryError if you have certain
operations that require lots of memory. This is a very tough thing to
get a handle on, since any operation that could potentially take down a
"small" JVM can certainly take down a big one, too. But, if the
memory-heavy operations are relatively infrequent, or you can limit the
number of simultaneous memory-heavy operations, you can have more of
them running in one big heap than in two (or more) smaller ones.
Monitor locks (aka synchronization) can be "improved" by running
multiple JVMs. Let's say you have a shared resource that is very
popular. One obvious example is a database connection pool. If you have,
say, 1000 threads actively requesting connections from that pool,
contention is relatively high for the lock that protects the integrity
of the pool regardless of the size of the pool. If you split into two
JVMs, then you only have (on average) 500 active threads fighting for
the lock, and you may see performance improve slightly. There is another
edge to that sword, though: you are likely to sacrifice any performance
gains with (somewhat) limited contention by putting another component in
front of Tomcat to decide which JVM handles the request.
If you have an unstable application, running additional JVMs (that is,
more than your hardware and/or network setup requires) can help
alleviate those stability problems: instead of 1/2 of your users getting
their sessions expired because the webapp and/or JVM crashed, you might
be able to get away with 1/4 or 1/8 of your users being interrupted.
That's only a stop-gap solution, though: you should fix your webapp :)
Finally, if you are running a fault-tolerant website with all the
bells-and-whistles, you are probably using either distributable sessions
or something reasonably comparable (webcache, etc.). In those cases, the
overhead of communicating session information between the JVMs will kill
your performance many orders of magnitude faster than any single-JVM
inefficiency you could find.
I'd be happy to hear specific reasons why multiple JVMs would improve
the performance of a webapp. Tell your consultant you want those
specifics, and definitely let us know so we can comment on them. Who
knows... he or she may have some good points that I hadn't considered.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0BSgkACgkQ9CaO5/Lv0PD1vwCgwmTCWUxp8itw9wuUjS4o7ANd
o2EAn2L7iz1PGo3q3jUTB902RnE5U/4i
=sKEt
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org