[email protected] wrote:
[...]
I am not a specialist in high-throughput Apache/Tomcat configurations,
but just some basic data :
First, I think that other people on this list more qualified than I am,
will tell you to set up a test configuration, try it out by simulating
the real situation you are expecting as closely as possible, and look at
where the bottlenecks really are.
Second, assuming you are indeed running a threaded Apache (worker mpm),
there is not much stopping you from allowing a lot more threads at the
Apache level. I have seen numbers mentioned on this list higher than
500 threads in a single Apache.
Apparently, each additional thread uses very little additional memory.
The numbers you see under Linux using "top" for instance are a bit
misleading, because much of what you see actually overlaps.
What I mean is that you can probably totally saturate your back-end
Tomcats, before you really run out of threads at the Apache level.
Of course I may be wrong there, since I don't know which real number of
simultaneous requests you are expecting to have in total, nor how long
your slow requests can really take to process.
But the calculation should be straightforward.
Say a slow request takes on average 5 seconds to process, and you expect
a maximum of 20 of these to arrive per second. Then you need 100 threads
in Tomcat to process them (the first one is free again after 5 seconds
and can be re-used). And you need also at least 100 threads in Apache
to handle those connections (*). Then do the same for your "fast"
requests, and add up the numbers. And add up another 20% just for
breathing space.
Then add another 20% to the number of Apache threads, just for peaks.
(**)
Does that lead to an outlandish number ?
If yes, then you need a bigger boat ;-)
If not, then all you need is a mechanism to select, at the Apache level,
which request is re-directed where. There are several possibilities
there, from JkMount/JkUnMount to mod_rewrite and mod_proxy and
mod_setenvif, to <Location> sections with "SetHandler jakarta-servlet",
and all the balancing stuff.
Running 2 instances of Apache, either on the same host or separate
virtual machines, will not make a big difference, but will introduce
some inconvenients (such as needing two different hostnames or ports).
Unless you put yet another Apache in front again; but that's getting a
bit devious, no ? (although I'm sure that there are people out there who
have and need that kind of stuff).
(*) otherwise you would indeed run out of threads in Apache to handle
front-end client connections, while you have idle capacity at the Tomcat
level. That would be silly indeed.
(**) If an Apache thread tries to connect to a Tomcat, and that Tomcat
has temporarily run out of threads to process the call, the connection
will be held for a while in the wait queue of the TCP socket of the
Tomcat connector. As soon as a Tomcat thread is available again, the
connection will go through and grab the Tomcat thread.
I believe the standard Tomcat configuration allows for 100 waiting
connections per Connector, but that is configurable too.
Now also, as a parting shot, do not loose track of the fundamentals : if
your average slow request takes 5 seconds to process, and you can shave
1 second off that by optimising your application, you gain 20% of your
front-end and back-end threads and servers.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [email protected]
" from the digest: [email protected]
For additional commands, e-mail: [email protected]
