Gerhardus.Geldenhuis@xxxxxxxxxxxxxx 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: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|