GuidesImproving mod_perl Driven Site's Performance -- Part VII: Performance Tuning by Tweaking...

Improving mod_perl Driven Site’s Performance — Part VII: Performance Tuning by Tweaking Apache Configuration Page 5




               Total RAM Dedicated to the Webserver
  MaxClients = ------------------------------------
                     MAX child's process size

So if I have 400Mb left for the webserver to run with, I can set
MaxClients to be of 40 if I know that each child is limited to 10Mb
of memory (e.g. with Apache::SizeLimit).

You will be wondering what will happen to your server if there are
more concurrent users than MaxClients at any time. This situation
is signified by the following warning message in the error_log:

  [Sun Jan 24 12:05:32 1999] [error] server reached MaxClients setting,
  consider raising the MaxClients setting

There is no problem -- any connection attempts over the MaxClients
limit will normally be queued, up to a number based on the
ListenBacklog directive. When a child process is freed at the end
of a different request, the connection will be served.

It is an error because clients are being put in the queue rather
than getting served immediately, despite the fact that they do not get
an error response. The error can be allowed to persist to balance
available system resources and response time, but sooner or later you
will need to get more RAM so you can start more child processes. The
best approach is to try not to have this condition reached at all, and
if you reach it often you should start to worry about it.

It's important to understand how much real memory a child occupies.
Your children can share memory between them when the OS supports that.
You must take action to allow the sharing to happen. We have
disscussed this in one of the previous article whose main topic was
shared memory. If you do this, the chances are that your MaxClients
can be even higher. But it seems that it's not so simple to calculate
the absolute number. If you come up with a solution please let us
know! If the shared memory was of the same size throughout the
child's life, we could derive a much better formula:

               Total_RAM + Shared_RAM_per_Child * (MaxClients - 1)
  MaxClients = ---------------------------------------------------
                              Max_Process_Size

which is:

                    Total_RAM - Shared_RAM_per_Child
  MaxClients = ---------------------------------------
               Max_Process_Size - Shared_RAM_per_Child

Let's roll some calculations:

  Total_RAM            = 500Mb
  Max_Process_Size     =  10Mb
  Shared_RAM_per_Child =   4Mb
              500 - 4
 MaxClients = --------- = 82
               10 - 4

With no sharing in place

                 500
 MaxClients = --------- = 50
                 10

With sharing in place you can have 64% more servers without buying
more RAM.

If you improve sharing and keep the sharing level, let's say:

  Total_RAM            = 500Mb
  Max_Process_Size     =  10Mb
  Shared_RAM_per_Child =   8Mb
              500 - 8
 MaxClients = --------- = 246
               10 - 8

392% more servers! Now you can feel the importance of having as much
shared memory as possible.

Choosing MaxRequestsPerChild

The MaxRequestsPerChild directive sets the limit on the number of
requests that an individual child server process will handle. After
MaxRequestsPerChild requests, the child process will die. If
MaxRequestsPerChild is 0, then the process will live forever.

Setting MaxRequestsPerChild to a non-zero limit solves some memory
leakage problems caused by sloppy programming practices, whereas a
child process consumes more memory after each request.

Latest Posts

Related Stories