Jump to content

Why does Apache+mod_php on Windows require low RAM usage?


-sandro-

Recommended Posts

Hi all!

I have Apache + mod_php installed on Windows but I can't "relate" it to any of those used on Linux.

 

It only has this:

 

# ThreadsPerChild: constant number of worker threads in the server process

# MaxRequestsPerChild: maximum  number of requests a server process serves

ThreadsPerChild 250

MaxRequestsPerChild  0

 

regarding the children.

 

httpd.exe only takes 12MB of RAM and if I do an "ab" test with a script with only sleep(10) with 30 concurrent connections it only goes to 30MB of usage and it can take all of them together! I did the same on my ubuntu vps also in mod_php and to get 30 concurrent connections I had to start 30 servers and the VPS basically crashed because the RAM usage went over 200MB for the apache processes only. So the question is why the RAM used is -so- little?

 

Link to comment
Share on other sites

By default apache on windows uses a threaded system which means it only has one process but several threads inside that process to handle the requests. As such there is less wasted memory as a lot of the code is shared between all the threads.

 

On linux however apache defaults to using a fork base system for handling requests which means it has to fork off new processes for each of the concurrent requests.  Forking a process is expensive memory wise as the entire set of process data is duplicated for each process.

 

There are directives to control how many processes it will fork off to handle requests before it starts holding connections back.  You would want to adjust these to whatever your vps can handle and whatever is reasonable for the amount of traffic you get.

 

This is the default config for the fork system.

# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          150
    MaxRequestsPerChild   0
</IfModule>

 

StartServers controls how many processes it will create when you first start apache.  These will be created and ready to process requests right away.

MaxClients controls how many process apache will spawn maximum to handle concurrent requests.

The rest of the directives control how apache manages the processes as far as creating and destroying them.  Generally you do not need to change them from their defaults.

 

So at any given time your setup could between StartServers and MaxClients copies of httpd running to handle requests.  On my VPS a typical apache process seems to use around 10Mb of memory, so for each copy of httpd that gets started that is an additional 10Mb of memory being used.  If my site got hammered and apache had to spin up all 150 (MaxClients) process then I'd be at 1500Mb of memory, or about 1.5 gig just for apache.

 

It's possible to get a threaded apache setup on linux I believe but I've never tried it so I do not now how easy/hard it would be or how well it would operate.

 

Link to comment
Share on other sites

My point was: if the threaded system is MUCH better in terms of RAM used why not use this on Linux and by default? I'm able to serve 250 concurrent connections with 120MB used for what on Linux requires to just start 15 children processes!

Link to comment
Share on other sites

The reason why prefork is the default on linux is likely due to compatibility reasons, though I can't say that for sure.  Prior to apache 2 the prefork model was the only option I believe and it remains the default to maintain the same type of system as what apache used to be.  The prefork method is also generally considered to be more stable as if something goes wrong and the worker crashes you only loose the one request/client it was handling.  If a threaded worker crashes you loose all the requests/clients.  The threaded mpm for linux takes some steps to help mitigate this by still forking a few separate processes and then having those processes create threads for processing.  In such a crash you'd still loose a group of clients but not everyone.  Another issue with using a threaded mpm is that you have to ensure your mod_php (and other modules) are thread safe which can sometimes be a problem.  I'm not well versed in the subject but even though PHP does offer a thread-safe build I've heard some criticism that it's not really thread safe, just thread safe enough to get by in most cases without any major problems. 

 

*NIX systems have traditionally been processed based as far as I am aware as well.  It is easy to work with multiple processes in *NIX systems and avoids some of the pain points of threads such as having to make sure two threads don't accidentally stomp on each others memory causing problems.  It's been a long time since I really worked with a linux system at the lower levels but last time I did I seem to recall threading in linux was somewhat of a pain and not well supported/handled.  It's probably better these days but the precedent has been set.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.