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.
(See http://httpd.apache.org/docs/2.2/mod/mpm_common.html#listenbacklog)
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
request.
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
determine.
To make Apache children more quickly go back to the pool of idle children, you could also
reduce the KeepAliveTimeOut setting. See
http://httpd.apache.org/docs/2.2/mod/core.html#keepalivetimeout
and
http://httpd.apache.org/docs/2.2/mod/core.html#timeout
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
