tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: How to limit tomcats thread consumption?
Date Tue, 05 Apr 2011 13:12:49 GMT
Part 2, Apache httpd matters..

Michael Jerger wrote:
> Sorry for beeing not precise enough. I was talking about apache VirtualHosts.
> I've two sites enabled www and dev.
> So I've to set Maxclients to the total of both maximums concurrent requests - 
> righ? While writing this - I tend to two seperated apache instances - so I can 
> set maxclients per web.
That is one of those areas where giving a precise answer is not easy, because it depends 
on so many things..

You can run two separate Apache httpd instances of course, each with its individual 
MaxClients setting.  But then you will have to give them separate listening ports, which 
may or may not make other things more complicated in your case.

About Apache "children" versus "VirtualHosts" :

When Apache (pre-fork MPM) starts, it will fork n1 children processes, where n1 is the 
"StartServers" setting.  Then it waits for requests.  When a request comes in, the "main 
Apache" looks for a child that is idle.  If it finds one, it will pass the request to that

one, and go back to listening for more requests.  If another request comes in, same thing.

  If a child is done with one request (that includes the time needed by the back-end 
tomcat to process the request if needed), the child becomes idle again.
If a request comes in and there is no idle child available, Apache will fork again to 
create another child, and pass the request to it.  It will do this, as long as the number

of live children does not exceed MaxClients.  When MaxClients is exceeded, any new request

has to wait (*), until a child becomes available again.
If no more requests come in for a while, and there are lots of idle children, Apache will

start killing off some, until the number of children is back to MinSpareServers.

(*) that is, as long as the "socket queue length" for the listening socket is not 
exhausted.  If it is, the connection will be refused right away.

Now the less obvious part to understand, is that each Apache child is a "full" server : it

can handle a request for *any* VirtualHost.  When it processes the request, it just 
temporarily adopts the "personality" (aka the configuration settings) of the corresponding

VirtualHost to which this request is addressed.
When this request is processed, it goes back to being idle, and maybe the next request 
that this child will handle is for another VirtualHost.

So the concept of "child" (or thread) is separate from the concept of VirtualHost, and 
VirtualHost is just a configuration that one child temporarily adopts for processing one 
Put another way, you can can have one Apache with 50 VirtualHosts, and it will not change

the number of (children) processes of Apache.

In the practice that means that you could just set MaxClients and the other 
children-related counters, to the reasonable number of requests that you want to be able 
to process immediately (auf der Stelle) at any one moment, all VirtualHosts together, by 
having always an idle Apache child to take care of it right away.
If your applications (tomcat included) respond very quickly, then a quite small number of

Apache children may be sufficient to handle the load.  During a peak of requests, some of

them may have to wait a fraction of a second to receive a child to take care of them, but

is might not be noticeable.  And the lower number of Apache children would mean a lower 
number of Tomcat threads also, so each child less in Apache counts double.

Now all of the above would be put in question if the requests to your server are such that

they take a long time to be processed of course.  But that is something that you have to 

To make Apache children more quickly go back to the pool of idle children, you could also

reduce the KeepAliveTimeOut setting.  See
for the explanation.
(the main point being that as long as a child is waiting for another client request, it is

blocked with this one client, maybe for nothing, and cannot go back to the idle pool).

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message