[development] 2k qps

[Tamir Khason]

 Yes, sure it is a one of things to consider - MaxClients.  But it's
not an issue when it comes to server hang. It doesn't have time to
start swap but just hangs. It worked like this with 100-256 clients
configured. Each process takes around 10-13MB. It cannot be decreased
since lot of modules are loaded. Actually we can turn off log module
and info module and may be more here and there...but overall this
doesn't help. The hang happens immediately and not slowly  with the
time. We have simple monitor for load average coming to 5 and then
sending mail. The problem is that load average goes to 100 within a
minute and nothing can alert or work. Sometimes it reaches 500.
Average process amount is around 70-80 until the problem comes to
visit us...So adjusting MaxClients won't help a lot here.
KeepAlive is 15 sec and it's fair. I can reduce it to 3-5 secs..not
sure it might help. Once again, when problem starts all processes are
engaged and system hangs..so keepalive won't help. May be Timeout..but
we cannot decrease its settings otherwise it will cut on image upload.
If I am not mistakening thttpd is discontinued project. In our case I
wanted use TUX but it cannot serve htaccess file. So I am planning run
2 apache.  1 in worker mode and server static content and behind it
prefork mode serving dynamic content only.
We tried to move everything to httpd.conf but seems those Drupal guys
want .htaccess to exist so we have no choice and using it and I do
know that apache makes an extra look for .htaccess in each dir it
accesses.
 Shortly: we cannot turn AllowOverride to None.
Query_cache for some tables could be an interesting thing. We will
surely investigate this one and try.  Also we will look into that
alias thingy you've been talking about.
More than that, we even don't succeed to enter server-status in apache
to see what goes on...everything goes too fast and something kills the
server within the seconds..

 Thanks so far

> From: Amr Mostafa <amr.mostafa at gmail.com>
> Date: Wed, 11 Oct 2006 10:27:54 +0200
> Subject: Re: [development] 2k qps
> To: development at drupal.org
>
> > Check  if the number of Apache processes is too high (e.g. 256 which
> > may not fit in your RAM without swapping), and lower it if necessary.
>
> Regarding this, what I do is watch the process table, see the average
> memory footprint for each apache process, let's say it's 6 mb. You
> have 1000 mb, leave some RAM for mysql and other services, so
> remaining is 600 mb (just an example). 600/6 = 100. And that's the Max
> apache processes I will be allowing. Because more than that it means
> my apache will swap.
>
> If your theme has lots of images, consider tweaking your Keep-Alive
> (http://httpd.apache.org/docs/1.3/keepalive.html) and cache
> (http://www.mnot.net/cache_docs/), it will help save unnecessary
> apache processes. Also, consider serving your non php files under
> thttpd (http://www.acme.com/software/thttpd/) or another light web
> server.
>
> Consider moving your rewriting rules to to conf files instead of
> .htaccess, due to way rewriting works, it internally resets part of
> the request processing cycle when invoked too late (e..g via
> .htaccess) while having it in conf files enables it to take action
> early enough.
>
> Consider removing your .htaccess completely, move the configuration to
> .conf files, and disable .htaccess in apache conf. This will save you
> a few system calls.
>
> If your site is a community one that gets updated a lot, consider
> turning off query cache for some tables. Because in that case, cache
> becomes invalid in very short intervals and maintaining cache becomes
> overhead.
>
> No one sugguested a Drupal performance tip. I will kick the ball off,
> it's a bit nuts, might break things but this is the devel list right ?
> I find many sites not using Drupal's aliases feature. If you are one
> of those, consider turning off aliases lookup. I do this quickly by
> adding return FALSE in first line in
> (http://api.drupal.org/api/4.7/function/drupal_lookup_path). This will
> save you some queries.
>
> Of course you will want to benchmark all that and see what works best
> for you.
>