2

I currently run an AWS EC2 instance (c3.2xlarge) which has 8 CPUs and 16GB of RAM. The Apache version is 2.4.7 (Ubuntu) and my mpm_prefork.conf currently looks like:

StartServers            40
MinSpareServers         40
MaxSpareServers         80
MaxRequestWorkers       1200
MaxConnectionsPerChild  0

mpm_worker.conf (EDIT: not being used)

    StartServers            8
    MinSpareThreads         100
    MaxSpareThreads         300
    ThreadLimit             256
    ThreadsPerChild         100
    MaxRequestWorkers       600
    MaxConnectionsPerChild  0

Has anyone had experience fine-tuning these figures? Currently it's consuming currently 5GB on these settings so I'm thinking this could be tweaked up a bit more.

1 Answer 1

6

You are either using prefork or worker, so you don't need to adjust both settings.

There's two questions that need to be answered though.

  • What is more important to you, having the "benefit" of more free RAM or having a server that can support more traffic?
  • Are you using PHP via mod_php or a CGI process

Both questions will heavily influence how many threads you actually need, and what is safe to be set.

If you are using mod_php

If you are using mod_php it means that the number of threads you have comprimises of both those used to serve dynamic content and those for static content. So you need to have enough threads to be able to support the number of customers loading all static and dynamic assets at a given time.

The risk is that you need to limit to be higher to cater for static content delivery, but with each thread you add, you are effectively increasing the amount if RAM you are commuting to the process (not used memory, but committed memory). In fact, with Magento, you'll likely have a memory limit of 512MB in PHP - which means for 20 Apache threads, that's actually 10GB of committed RAM. Worse still is that every thread needs its own CPU, if you've got 8 threads at 100% CPU usage, your machine will be at a load avg. of 8. If you've got 20 threads trying to do the same, the load will sprial out of control.

I'm a fan of mod_php but used with just a standalone Apache installation (ie. Without a proxy before Apache serving dynamic content), you run the risk of over allocating memory or CPU resource.

If you are using a CGI instance of PHP

If you are using a CGI instance of PHP (eg. fCGI, fastcgi, fpm), then you don't quite need so many threads in Apache as the dynamic content is handed off to the separate PHP process, so the thread count can be much lower (although your number of PHP threads then come into play).

Keeping Apache

If you want to keep the simplicity and predictability of Apache, then my advice would be to drop the thread count to 16 max. and put a reverse proxy in front (eg. Nginx), to serve the static content.

You'll then be able to lower your memory footprint and keep Apache. Its the best of both worlds.


However, what I haven't mentioned is traffic levels. How many concurrent requests you see on your site in a given window (no, not that useless measurement in Google Analytics live that means nothing), but rather a calculation of the volume of real time requests per second your machine sees.

Because ultimately, your requirements are driven by the volume of traffic you must support, not by some arbitrary goal of reducing memory.

5
  • I actually saw room in the memory and therefore have pointed out that it's using 5GB of ram (and I have about 8GB free). I am using prefork with standard Magento caching and it actually performs better than nginx + Varnish combined when it comes to CPU usage but the page load time is a little slower than the holepunched Varnish way. Commented May 8, 2014 at 1:02
  • Ultimately I'd like some guidance on the mpm_prefork.conf numbers. Commented May 8, 2014 at 1:50
  • Varnish is a cache, it doesn't make your site quicker - it merely allows cacheable content to be cached and delivered from cache. But the page content still has to be rendered first, which is why Varnish has ultimately nothing to do with improving performance. You also need to properly understand how to implement Varnish to use it effectively, 100% of stores we see using Varnish are using it wrong, causing more problems, more bottlenecks and more load than if they weren't using it. Don't attempt to use Varnish unless you have a significant level of experience of how to achritect it. Commented May 8, 2014 at 7:26
  • I never stated Nginx was quicker, see sonassi.com/knowledge-base/magento-kb/mythbusting/…, you've missed my point entirely. I suggested adding another reverse proxy so that you could size your Apache threads accordingly (then also suggested a value for it). I've provided all the information necessary for the level of information you have provided. Those settings are set to suit workload, increase when too low, decrease when too high. But only your server stats can tell you this, not a user on SE. Commented May 8, 2014 at 7:31
  • I did read your article before posting this question and that's actually what got me to remove nginx, believe it or not. You in fact even state that nginx isn't really necessary unless you are making a CDN. I do believe Varnish will make a better better pair with Apache vs nginx. Thanks for your detailed help. Commented May 8, 2014 at 13:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.