[users@httpd] Question about mod_status

["arianna.manlio@yahoo.com" <ar...@yahoo.com>]

Hi all,
I'm trying to optimize performance of my web server (Debian Squeeze 
64bit, it's a VM virtual machine with 4 GByte RAM and 4 vCpu).
I'm using standard "deb" package and apache-prefork, with php running as 
module.

I think /server-status give me a lots of information, but how can I 
start customizing directive?
For example, if I see several "K" (keepalive), this is bad?
The problem is: during day I notice OOM errors, and website are 
responding slowly.
So, I'm trying to understand if I must raise my resources, or simply 
change my apache2.conf
Thankyou very much!



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: [users@httpd] Question about mod_status

[Tom Evans <te...@googlemail.com>]

On Tue, Mar 6, 2012 at 8:47 PM, arianna.manlio@yahoo.com
<ar...@yahoo.com> wrote:
> Hi all,
> I'm trying to optimize performance of my web server (Debian Squeeze 64bit,
> it's a VM virtual machine with 4 GByte RAM and 4 vCpu).
> I'm using standard "deb" package and apache-prefork, with php running as
> module.
>
> I think /server-status give me a lots of information, but how can I start
> customizing directive?
> For example, if I see several "K" (keepalive), this is bad?
> The problem is: during day I notice OOM errors, and website are responding
> slowly.
> So, I'm trying to understand if I must raise my resources, or simply change
> my apache2.conf
> Thankyou very much!
>

Keep-alive starvation with prefork - seen that before.

Keep-alives are good, they improve the user experience. However, with
prefork and php as a module, each keepalive connection is an idle PHP
interpreter using memory. If more requests come in, you will need to
spawn more Apache children, and with each child, a new PHP
interpreter.

Personally, I would move to event MPM, and use fcgi to talk to PHP.
You can then strictly control the size (number of processes) of your
PHP application, Apache will handle keep-alives almost for free with
event MPM, and you will have more control over your VPS.

Cheers

Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: [users@httpd] Question about mod_status

[Mathijs <ma...@gmail.com>]

Sounds like you should probably take a look at
http://en.wikipedia.org/wiki/HTTP_persistent_connection to get an idea of
what Keep-Alive means.

If you find that those 'K' connections are hogging up too much resources,
you could try adjusting your KeepAliveTimeout and MaxKeepAliveRequests
directives. See the documentation (
http://httpd.apache.org/docs/current/mod/core.html ) for more information
on those directives.

Also a more thorough guide on getting the most out of your Apache HTTPD
server performance can be found here:
http://wiki.apache.org/httpd/PerformanceScalingUp

Feel free to ask more specifics if the documentation isn't clear.

Kind regards,
Mathijs

On Tue, Mar 6, 2012 at 9:47 PM, arianna.manlio@yahoo.com <
arianna.manlio@yahoo.com> wrote:

> Hi all,
> I'm trying to optimize performance of my web server (Debian Squeeze 64bit,
> it's a VM virtual machine with 4 GByte RAM and 4 vCpu).
> I'm using standard "deb" package and apache-prefork, with php running as
> module.
>
> I think /server-status give me a lots of information, but how can I start
> customizing directive?
> For example, if I see several "K" (keepalive), this is bad?
> The problem is: during day I notice OOM errors, and website are responding
> slowly.
> So, I'm trying to understand if I must raise my resources, or simply
> change my apache2.conf
> Thankyou very much!
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@httpd.**apache.org<us...@httpd.apache.org>
> For additional commands, e-mail: users-help@httpd.apache.org
>
>