Why shouldn't I use Nginx for Magento

Nginx vs Apache for Magento

We are going to give you a loose analogy – a (Magento) fast-food restaurant.

The cast

The customer (at the drive-through), is the customer on your web store. The till operator (who sits on a chair and hands you the bag of food through the window – Web Server) The chef (who cooks the meals – PHP) The su-chef (who prepares the ingredients for the meals – server subsystem)

The Challenge

The average meal takes 2 minutes to prepare, 12 minutes to cook and 5 seconds to hand to the customer.

Now, lets take the perception of Apache (an overweight, unfit, slow window attendant), the kitchen takes 14 minutes to make the meal, hands it to him – then he passes it to you. He is only passing 1 bag, every 14 minutes, a pretty easy job.

So lets improve performance

We want the business to run faster – so we’ll fire Apache and replace him with Nginx (the Ivan Drago of fast-food service).

The kitchen takes 14 minutes to prepare a meal and Nginx hands the bag of food at lightening pace to you.

But hold on, it has still taken 14 minutes for the customer to get their meal – even though we’ve got the fastest delivery staff available.

That’s because it was never the person handing you the food that was the bottleneck; in-fact – the “slow” person added value by speaking the native language of kitchen staff and being able to receive updates (.htaccess support). Whereas Ivan speaks russian and it requires a translator to stop him working and tell him new updates (edit Nginx config, reload etc. yada yada yada).

The conclusion

Nginx won’t improve performance over Apache for Magento, we have proved in time and time again in benchmark testing and the reason is because PHP (the chef) is the bottleneck.

Nginx/Apache are the front men – and in the case of Magento hosting are no more than marketing tools. It is easy to show how fast Nginx/Lighttpd/Litespeed are over Apache in terms of reqs/s.

On a given server (2.5GHz QC/8GB RAM), Apache is good for around 12k requests per second, Nginx can surpass this with relative ease – hitting around 16k requests per second – but this is for static content. When you start to hit 12 thousandPHP requests per second – then its time to consider dumping Apache, but until then, it will perform par-for-par with anything else.

Our advice

If you’re building a CDN, Nginx is a great choice If you want a static file proxy, Nginx is a great choice (heck, we use it ourselves).

If you want a flexible, high performance web server for Magento, Apache is just as good a choice as Nginx – as at the end of the day, PHP (the chef) is slowing you down, not the web server – never the webserver.

  • Hmm... the problem with analogies is that they cloud the picture. Especially here. Whilst I agree 100% that the main delay is with php, what isn't mentioned is that you can ease the life of PHP in a number of ways:

    Firstly, get the static content out of the way. You can either do this by using a CDN ( especially useful for those of us who generally use standard VPS packages offering only 100Mbit connectivity... a busy, high graphics site can easily swamp that ), but that comes with extra associated $$ cost, or you can let the front end handle it... just watch your peak bandwidth ( fail at your busiest and you'll lose your potential custoners real fast ). Having set this up - I've got busy sites - 10k/day uniques - running nginx on a single vCPU and 128M ( and 20k / hour peak loading in a slightly different configuration ), handing over to 'the worker' who now only has to do a fraction of the work he previously had to.

    The database... once tuned, MySQL ( we use percona these days, not too sure which way Larry's going to go ) does a pretty good job. But it does need enough resources to be able to answer most requests from memory. As websites and their supporting CMSes use databases as primarily read - only resources, they present little load on the server - 30+ years of development have gone into ensuring this is the case ( anyone else out there remember Oracle 5 and before! ), and all modern RDBMSes have got it pretty well cracked ( as an aside, my soul died a little bit when I read about the use of memcached to speed up MySQL. Maybe if you are youtube, but not here in real life please! ).

    OK so we've now got a server that's addressed all the static stuff, and has a database presenting minimal load. What have we got? Far more resources for the worker: php can now be lavished with all of them: run it in fpm mode, sitting there waiting for requests, cache it to the hilt with APC, Memcache, whatever your fancy. You're now making the most efficient use of the available resources.

    Then there's the configuration. Apache can be forced to run php-fpm via a fairly complex mod_fastcgi configuration via dummy directories. With nginx it just works. And as for updating .htaccess on the fly in a production environment... you'll be telling me it's ok to develop on the production server as well next!

    However, when all is said and done, the difference between a well configured apache and nginx platform will always be measurable in a real life environment, as the 'worker' - php has the extra resource that you've freed up to play with. If it isn't then your bottleneck is elsewhere.

    Whether the difference will be big enough to be noticeable is unlikely unless you're really pushing the boundaries of the available hardware - which is never a good idea in a production environment.

    HOWEVER, the difference between a standard VPS, running your favourite dashboard, be it WHM, Plesk, webmin or whatever else UNTUNED, and any properly sized and tuned VPS - whether it runs apache or nginx - will be like chalk and cheese.

    You can always tell those that haven't... 5+ seconds to display a product. Always a giveaway.

    This is just the career SysAdmin in me talking. My goal is a preformant, secure platform that it simple to maintain.

    In my experience nginx/php-fpm(/APC) provides all of that, and I can monitor and tune the resources with ease.

    You NEED to make the effort to tune your VPS.

    That would have been a far more useful article.


    • sonassi

      Hi Steve,

      Thanks for taking the time to write a detailed answer. The article here is directed at a typical Magento user - not a sys admin. The point is to drive home that making a hosting choice shouldn't be based on what web server they use, or similarly, that if they manage their own server - changing the web server shouldn't be an immediate concern.

      Your response reinforces the article by saying that the concern shouldn't be the web server software, but rather the PHP build, the MySQL database or the server hardware itself.

      The advice we give to our customers ...

      If you need to re-sell hosting

      Nginx > Apache > PHP-FPM

      That keeps .htaccess support for your customers, security
      (chroot/multiple php.inis) from PHP-FPM and static file performance from

      If it is just for you

      Pound > Varnish > Nginx > PHP-FPM

      This gives you SSL unwrapping from Pound, static and dynamic (ESI)
      caching from Varnish, un-cached static content from Nginx and dynamic
      content from PHP-FPM

      If you've got no real experience with Varnish or Nginx

      Apache > PHP-FPM

      The truth is that you can do a lot more damage than good with Varnish
      if you do not set it up properly (cached private sessions, unwanted
      un-setting). The same applies to Nginx.

      My final advice, consult a professional - its money well spent.

  • sylvainraye

    Additionally you could add MySQL as a bottleneck if not well configured. And even if good configured, it needs time to handle the thousand requests that Magento can do to the database. The problem is even not PHP but the pair PHP-MySQL

    • sonassi

      A hugely common misconception. Magento isn't bottlenecked by MySQL at all. Even a stock MySQL configuration still won't considerably slow down a Magento store.

      • sylvainraye

        Yes, you're right. I have forgotten that I needed once to save a huge quantity of data in MySQL and I preferred to do it directly with SQL query with join and so on instead of using the Magento Framework which was very slow to do the saving with the collection. However in this case, it was not a PHP problem but the Magento EAV / Collection Framework. I agree that PHP is a bottleneck compared to other programming languages.

  • Pingback: The Best Magento Server Set Up | Sonassi Makes Magento Ecommerce Websites()

  • Nginx works faster and provides better productivity for magento. Use nginx and php-fpm, you'll see the result. It was proved hundreds of times.

    • sonassi

      Victor, you've entirely missed the point of the article. As the worlds largest specialist Magento hosting provider (www.sonassihosting.com) - we're extremely well educated and capable of making this comment.

  • smokewire

    Nice and descriptive comparison but after that said why you still promote Nginx as a choice for your hosting plans. No apache?


    I am wondering?

    • sonassi

      Correct, we do use Nginx - but its *not* for performance reasons. We use it because of more programmatic configuration syntax - it is a better fit for how MageStack operates.

      This article isn't telling anyone not to use Nginx. It is saying that in the pursuit of performance - you shouldn't focus your attention on using Nginx instead of Apache.

      The whole Magento community has bizarre notion that changing to Nginx/Litespeed will provide that desired speed boost - it won't. The bottleneck isn't the webserver.

      Sure, change to Nginx because it has other benefits - but Magento performance is not a reason to use Nginx. Its no faster than Apache.

  • Dario

    To be clear, Magento will work fine on Apache and Nginx and better on Zend.
    The reason why is better to use Nginx is to not overcharge your virtual/dedicated machine.
    Apache is more user friendly than Nginx for new users.

    To run faster with Magento, get a SSD server and optimized for Magento, also try to disable all unusable extensions, get a CDN for images and you will see the big improvements.

    • SteveHoldoway

      To some extent I disagree. Once a server is properly tuned, the primary bottleneck is raw CPU power. Using SSDs will improve the startup time, but not necessarily general performance, as the majority of database requests are reads, and the majority of them can be delivered from database cache.

      I have found nginx to perform better as it is more logical to tune than apache, and as it uses an event driven, non blocking model as it's core design, it is inherently faster and more scalable than apache ( 2.2 and before - haven't looked at 2.4 ). Also, separating php off into fpm mode ( a lot simpler with nginx ) allows an opcode cacher like APC to make an appreciable difference.

      As well as removing unnecessary extensions, you should also look into the performance of those that are left. Try the New Relic plugin ( not for too long, as I think it's based on the xdebug plugin, which I have had performance problems with in the past ), and you could well see some household names coming up as potential problems.

      You can also look at the use of a decent FPC, like Gordon Lesti's offering, backed with a Redis NoSQL data store. However, how much of that effort will be rolled into CE 1.8 I'm not too sure at this point - no spare time to investigate 🙁

      Finally, Zend is not a supported webserver for Magento. That may or may not be of importance to you.

  • I wonder why Magento Team or either Zend Framework team doesn't consider to "compile" their frameworks... something like Phalcon PHP. This should help a bit!

  • Guest

    When I did similar tests I noticed that nginx processed roughly 30% more hits than apache at half the server load. Hence it does make sense to use nginx as you do not need to scale up your farm that much to cope with traffic increase.

    • sonassi

      Your results are going to depend entirely on your test.

      Nginx is faster than Apache for some tasks - but the figures are completely irrelevant when it comes to Magento performance. They are both capable of 10,000+ requests per second, but Magento is only capable of delivering more than around 20 (40 for EE) requests per second per CPU core. So it is completely irrelevant.

      Post your test method and details.

      • Guest

        The method was quite simple - siege with a list of urls to hit the server. First run to populate FPC, second to do actual test. FPC is sort of "static" content so probably that is why it performed better. With regards to speed - the gain may not be great but nginx manages resources better.

        Transactions: 685 hits
        Availability: 100.00 %
        Elapsed time: 299.27 secs
        Data transferred: 6.33 MB
        Response time: 1.68 secs
        Transaction rate: 2.29 trans/sec
        Throughput: 0.02 MB/sec
        Concurrency: 3.84
        Successful transactions: 530
        Failed transactions: 0
        Longest transaction: 24.88
        Shortest transaction: 0.02
        Max CPU Load 4.12

        Transactions: 886 hits
        Availability: 100.00 %
        Elapsed time: 299.26 secs
        Data transferred: 8.49 MB
        Response time: 1.18 secs
        Transaction rate: 2.96 trans/sec
        Throughput: 0.03 MB/sec
        Concurrency: 3.48
        Successful transactions: 731
        Failed transactions: 0
        Longest transaction: 22.07
        Shortest transaction: 0.02
        Max CPU Load 1.97

        • sonassi

          Okay, so looking at your result format, it looks like you are using Siege.

          I'm not sure what hardware you are running but your results look exceptionally poor for a stock Magento store, let alone something with a FPC. The difference between your results are negligible - its less than 0.7 rps difference.

          I've just run a quick test on our shared hosting demo store (me-s1.sonassihosting.com),

          # siege -c200 -t10s 'me-s1.sonassihosting.com'

          Transactions: 2408 hits
          Availability: 100.00 %
          Elapsed time: 9.77 secs
          Data transferred: 9.41 MB
          Response time: 1.00 secs
          Transaction rate: 246.47 trans/sec
          Throughput: 0.96 MB/sec
          Concurrency: 245.60
          Successful transactions: 2408
          Failed transactions: 0
          Longest transaction: 1.68
          Shortest transaction: 0.02

          Your transaction rate is almost 82x lower than what we see from our demo store. How you can derive that Nginx is makes your store faster is baffling.

          I'd also question whether you are even comparing Apache+PHP-CGI with Nginx+PHP-CGI (rather than Apache+Mod-PHP).

          The bottleneck isn't the web server, it isn't Apache.

  • Joshua Micheal

    With all due respect, I disagree entirely with this article. I love my metaphors, but web servers are not restaurant waiters. The memory footprint of apache vs nginx are totally different. For your analogy to make sense, the slow waiter also has to be fat, so fat he's preventing other staff from walking around. That's what Apache does, it uses 10x as much memory, so it slows down mysql & other processes. So your example isn't accurate. In your parlance, the slow waiter is constantly getting in the way of the chef & actually slowing the chef down.

    • sonassi

      Hi Josh,

      I'll certainly concede that Nginx is a more efficient application, there's no question there. But efficiency does not imply performance (otherwise we'd all use SQL Lite over MySQL).

      In a like for like configuration (ie. PHP as a CGI process with either Nginx or Apache) - Nginx won't yield that considerable a memory saving over Apache - I'd venture to say its negligible in the grand scheme of memory in use. Your committed PHP memory allocation will dwarf that of the web server itself. We've conducted many a test that confirms the same.

      Nevertheless, it also doesn't alter the fact that Nginx won't yield a performance increase - Magento is bound by CPU - not memory. You'll run out of CPU resource a long time before RAM becomes a consideration (not to mention RAM is exceptionally cheap anyway).

      Apache is doing nothing more than passing a request from the reverse proxy/end user - to the PHP process - it does nothing else; and it does it in a performant and efficient way. So even changing out to Nginx won't make any difference at all - because they're both capable of requests per second in the tens of thousands - and Magento is lucky to see 40 requests per second on a quad core.

      I would certainly welcome your test results that are to the contrary and demonstrate what you are describing. We've been hosting Magento stores for over 5 years and can categorically state that the web server isn't the bottleneck.

      FYI. Your waiter can be as fat as he likes - because he's got all the time in the world to walk back and forth between the guest's table and the kitchen - because the Chef produces each meal 5,000 times slower than the time it takes him to make a round trip journey.

      • Joshua Micheal

        I see, well... I was comparing nginx+php-fpm to Apache2+mod-php. My task was to free up memory, not to benchmark every possible server setup. I wasted days fussing with Apache's CGI to no avail, and it worked within minutes on nginx.

        My results are that I'm at 50% RAM usage when idle instead of 100%, allowing me to throw more memory at mysql's innodb buffer, which speeds up all applications on the server, not just Magento. I'm also able to downgrade my hosting plan and save $100s.

        Again, metaphors are imperfect. In this case I had some fast chefs in the "restaurant" (static sites) in addition to the slow chef (Magento). Freeing up the memory by switching to nginx made a huge difference for me.

        Also your article is titled "why you shouldn't use nginx". So far we have shown that nginx is just as good as Apache (and maybe even better, especially for static content...). But I do agree that people shouldn't view nginx as a magic solution for Magento. What is a magic solution, is to configure your server to cache the page (Magento's full page cache is a misnomer). Dynamic content can be loaded in via ajax. That will speed ya up.

        Ps > 250 transactions/second is insane [for Magneto]. You must have a lot more hardware than me. I'm working in a restrained memory environment (economy VPS). I'm interested to get your server specs.

        • sonassi

          Hi Josh,

          To be honest, I suspected as much. Most people who claim gains in performance or resource usage from an Apache to Nginx swap is actually because they changed the PHP build too (whilst going from mod_php to fcgi/fpm). And its the PHP change that provides both the bump in performance and reduction in static memory usage.

          Compare Nginx to Apache - with php-fpm on both - and you'll find your results are identical.


          Perhaps not for yourself, but for anyone else reading. On a Linux server - memory usage is a *good thing*, if you're not using your RAM - you aren't allocating it properly. Keeping a good balance between buffers/apps is essential to making your server work as efficiently as it can.

          Nginx is as good as Apache, its better in some respects and worse in others; heck, its our web server of choice on MageStack - but its not because of any perceived performance benefit. It is because its programmatic syntax lends itself better to the bells and whilstles that MageStack offers.


          "What is a magic solution, is to configure your server to cache the page"

          No no no. Absolutely no. Caching != Performance. Its the worst possible approach to seek performance improvements. I've personally written countless articles on this, https://www.sonassi.com/knowledge-base/magento-with-varnish/ and http://magento.stackexchange.com/a/3816/500 - being good examples. It is imperative that a store performs properly without the aid of any form of cache.

          There will always be situations where a page request isn't in the cache and has to be rendered on-the-fly, and quickly. Not to mention, your most important customers are those converting into sales - and you can't cache the checkout process. So if the checkout is slow, they're exceptionally likely to abandon the cart and leave.

          Caching **without addressing the underlying performance first** only hides a symptom, but your core issue is still there. And you'll still suffer a slow admin panel, slow checkout for customers, penalised SEO from crawling uncached URLs.

          Varnish or any other frontend cache should only ever be implemented to reduce resource usage for fast sites - not as a solution to make a slow site fast.

          And even still, a cache won't allow you to downsize your hardware - as there will always be times when the cache could be cold; and the server/solution will still need to cope with the demand during the time it primes/builds.


          Finally, loading in dynamic content via Ajax is again a very poor choice. You pay a penalty for each call, every hit to the Magento bootstrap has a penalty of around 100ms - plus the time it takes to load whatever collection you need. Once you've got 3x ESI calls, you're tripling the PHP thread requirement, the MySQL memory connection per thread, the TCP/IP and socket usage - per each user on the website. Along with adding the extra time of 2x extra bootstrap loads and losing the efficiency of singleton models that would have been available if it were a pure full page load. Anything more than a single ESI call will lead to negative performance and an overall increase in resource usage.

          It may seem quicker on the surface to have a mostly-loaded page with a few AJAX wheels - but behind the scenes, the server is working much harder to produce the same output.


          FYI. Our server's that run shared-hosting customer stores and the demo stores are based on the ME-D1 chassis, https://www.sonassihosting.com/magento-hosting/dedicated/me-d1 - configured with 3.5GHz CPUs, 1TB 10KRPM disks and 32GB RAM.

          Feel free to browse our other servers, https://www.sonassihosting.com/magento-hosting/dedicated - or read a little more about MageStack https://www.sonassihosting.com/magento-hosting/magestack/ and https://help.sonassihosting.com/magestack/an-introduction-to-magestack/

          • Joshua Micheal

            I never said less memory usage is better... But too much can definitely be worse. When I say cache is a magic bullet... I mean its a way to circumvent magento for most pages. Magento is inherently slow. I would be interested what your benchmarks are for an uncached page? PS I still maintain that you haven't presented Any reasons not to use nginx

          • sonassi

            Magento isn't inherently slow. Badly set up hosting, poor quality 3rd party code and templates make it slow. Most of our customers see between 0.3s to 0.7s page load times without the need for Varnish.

            I'd guess you are finding Magento slow, because your are running it in a contended VPS. A VPS is the worst possible environment to run. Magento store in, you are competing not only with the inefficiency of the virtualization technology, but also with shared disk and network I/O and insufficient memory. We wouldn't run Magento on a dedicated machine will anything less than 8GB RAM. Again, there's a number of articles by Sonassi around the internet as to why a VPS is a poor choice.


            We're not saying don't use Nginx, we're saying don't use it because you think you'll see performance improvements. Your time is better invested doing anything else than changing the web server, as it isn't the bottleneck.

            That aside, there's a probably lot of reasons that the average user should use it.

            Lack of htaccess support
            Poorly documented
            Complex configuration options lead to misconfiguration
            Lack of true chained rewrite conditions
            Less stable than Apache + mod_php

          • Joshua Micheal

            I think Magento is clearly slow. Its subjective, but almost a full second to first byte on your 24GB server with all the caching layers is horrible. I was able to get it to 25ms but that's with Enterprise edition's full page cache, and my client's 24GB server. Their EE full page cache had bugs (showed user data to the wrong users), so I had to use ESI (ajax) to pull in customer specific content. With Community edition, I see the same loads as you 0.5 seconds on my VPS.

            I think if Magento weren't inherently slow, you wouldn't see all these blog posts about speeding it up. Look at a site like Facebook that is fast, time to first byte is 40ms and all the content is dynamic. Compare that to Magento where its over a second to serve stale static data to a guest user.

            Configuring nginx for me was easier than Apache. I found the documentation better than Apache. "lack of htaccess support" isn't a flaw of nginx anymore than Apache lacking nginx config file support. As for stability? I threw 10,000 requests at my server with a concurrency of 100 users and has 100% of the requests succeed..

            Also I'd say its pretty well documented nginx is faster for static files, and Magento serves plenty of static files.

          • sonassi

            Hi Josh,

            Actually, the TTFB on our demo store is closer to 0.12s un-cached.

            As 5 years of being the CTO here at Sonassi, an author of MageStack, a consultant for some of the worlds largest Magento stores - and having personally built, configured, tested and deployed a few hundred Magento stores; my experience doesn't quite coincide with your own.

            I'll leave you to it though, it seems like you've picked your route for performance optimisation and I wish you the best of luck with it. We're only trying to help others and remove the myths behind the many laughable "performance" articles you read.

          • Joshua Micheal

            I don't see any links to your demo store, and I'm not saying your ways don't work. I'm just saying you shouldn't tell people to overlook nginx.

            Your link here says your page load times are close to 0.5 to 1s with Magento's cache on https://www.sonassihosting.com/magento-hosting/magestack/ this is to be expected because Magento is inherently slow 😉 Here's an experiment. Add 100 "store views" with a loop, and turn off Magento's cache. You'll see page loads well over 30 seconds. Magento is not fast.

          • sonassi

            Hi Josh,

            (See http://me-s1.sonassihosting.com - its linked in the comment earlier that you referenced.)

            I don't really understand what you are looking to achieve or prove. Doing anything ridiculous with any platform and you are going to show its weaknesses.

            Look how slow this Ferrari goes towing an 40 tonne trailer

            If you've got 100 store views, you haven't architecture your store properly to begin with. But I've personally never seen a Magento store with 30 second page load times (not on our servers anyway ...); but on a VPS, that's probably to be expected.

            People *should* overlook Nginx, its irrelevant, the web server selection makes no difference at all. It has no impact on the page load time of a normal Magento store. You want to shave your 30s page load times down to 0.5? Nginx isn't going to do it, it won't make a single bit of difference.

          • Joshua Micheal

            Switching to nginx sped up my store. Magento's official whitepaper states that it can speed up your store. But I think we have differing definitions of speed. There is latency, and there is concurrency... and often people only care about one or the other. FYI i hit your store with this ab -n 500 -c 50

            I got <20 req/s.

            I hit my store with the same line (http://demo.vehiclefits.com) and got 37 requests per second. I will admit we are running different themes, but I'm sure you've also got better hardware - I'm on a VPS.

            As for 100 store views, and architecting your store properly - Magento claims to have multiple store support, so how is this bad architecture? Its using a feature they provided. There are valid reasons to do this like keeping one record of inventory. Its something Magento claims to do, but does not scale in practice.

            Not sure where you're getting 250req/s. If you truly can get the latency down to fractions of a second for uncached hits, my employer might have some very large clients for you.

            I disagree with you telling people to completely overlook a technology. You should never say "never". Magento themselves recommend nginx, and claim a 10% improvement. Your own software uses nginx, so surely people shouldn't overlook your software.

          • sonassi

            Hi Josh,

            Switching your PHP build is what sped up your store - and that's what you did when you dropped in Nginx. Compare apples to apples - put Apache+php-fpm up against your current Nginx+php-fpm set up and report back.

            Regarding your test, its flawed, for a number of reasons.

            1. 50 concurrent requests isn't anywhere near enough to show the capability, you'll need to use closer to 250, otherwise you are barely loading a single core.

            2. You are testing remotely (see https://www.sonassi.com/knowledge-base/magento-kb/why-siege-isnt-an-accurate-test-tool-for-magento-performance/), if your AB test is queuing (rather than benchmarking) whilst it waits on a response before sending the next, then your concurrency test is still subject to latency. And the majority of latency you are seeing is because of your own ISP (Comcast), hop 13 from 80ms to ~120ms

            sonassihosting.com ( Wed Oct 9 15:24:26 2013
            Keys: Help Display mode Restart statistics Order of fields quit
            Packets Pings
            Host Loss% Snt Last Avg Best Wrst StDev
            1. 0.0% 103 1.3 1.2 1.0 1.9 0.2
            2. 1.0% 103 25.1 8.9 0.4 60.8 14.5
            3. 0.0% 103 21.1 11.3 0.7 204.7 24.4
            4. 0.0% 103 26.8 8.6 0.8 54.6 12.9
            5. te-4-2-155.car2.Manchester1.Level3.net 0.0% 103 30.9 38.7 1.2 201.4 55.1
            6. ae-11-11.car1.Manchesteruk1.Level3.net 1.0% 103 278.3 113.3 75.9 305.9 60.8
            7. ae-4-4.ebr1.London1.Level3.net 0.0% 102 87.5 83.1 75.6 146.4 13.3
            8. vlan104.ebr2.London1.Level3.net 0.0% 102 87.2 82.4 75.6 138.6 12.1
            9. ae-41-41.ebr1.NewYork1.Level3.net 0.0% 102 89.2 82.8 75.7 135.4 12.7
            10. 0.0% 102 94.8 83.0 75.8 131.2 12.1
            11. ae-1-51.edge1.NewYork2.Level3.net 1.0% 102 86.1 83.5 75.7 132.4 12.5
            12. COMCAST-IP.edge1.NewYork2.Level3.net 0.0% 102 93.2 84.8 76.0 142.6 12.6
            13. he-4-15-0-0-cr01.ashburn.va.ibone.comcast 0.0% 102 103.4 90.5 81.4 144.9 12.8
            14. he-4-9-0-0-cr01.56marietta.ga.ibone.comca 0.0% 102 115.5 103.6 94.3 156.7 12.7
            15. he-0-10-0-0-cr01.miami.fl.ibone.comcast.n 0.0% 102 129.0 115.7 106.3 166.0 12.7
            16. he-0-11-0-0-ar03.northdade.fl.pompano.com 0.0% 102 120.1 116.8 107.3 166.6 12.7
            17. et-6-1-0.ar02.stuart.fl.pompano.comcast.n 0.0% 102 124.4 121.8 110.7 197.2 16.3
            18. te-8-1-ur01.ftpierce.fl.pompano.comcast.n 0.0% 102 129.4 120.0 111.7 175.4 13.3
            19. te-8-1-ur01.stluciewest.fl.pompano.comcas 0.0% 102 135.7 120.2 112.1 169.4 13.3
            20. te-8-1-ur01.palmcity.fl.pompano.comcast.n 0.0% 102 135.4 121.2 113.0 170.5 13.2
            21. te-8-2-ur01.hobesound.fl.pompano.comcast. 0.0% 102 135.0 121.8 113.2 171.8 13.5
            22. te-3-0-0-ten02.hobesound.fl.pompano.comca 0.0% 102 134.3 120.9 112.7 171.9 14.1
            23. c-xx-xx-179-7.hsd1.fl.comcast.net 0.0% 102 151.8 131.2 116.1 183.1 16.6

            3. MageStack has a built in L7 DOS filter, the moment you hit ~30 requests, you were blocked by the load balancer. At a guess (given the 500 requests), this is you ...

            Oct 9 14:39:04 lb1 dos-filter: dynamic - soft-block (38) - xx.xx.179.7 - c-xx-xx-179-7.hsd1.fl.comcast.net
            Oct 9 14:39:09 lb1 dos-filter: dynamic - soft-block (100) - xx.xx.179.7 - c-xx-xx-179-7.hsd1.fl.comcast.net
            Oct 9 14:39:19 lb1 dos-filter: dynamic - soft-block (274) - xx.xx.179.7 - c-xx-xx-179-7.hsd1.fl.comcast.net
            Oct 9 14:39:24 lb1 dos-filter: dynamic - soft-block (500) - xx.xx.179.7 - c-xx-xx-179-7.hsd1.fl.comcast.net
            Oct 9 14:39:49 lb1 dos-filter: dynamic - soft-block (462) - xx.xx.179.7 - c-xx-xx-179-7.hsd1.fl.comcast.net
            Oct 9 14:39:54 lb1 dos-filter: dynamic - soft-block (500) - xx.xx.179.7 - c-xx-xx-179-7.hsd1.fl.comcast.net

            Magento isn't built to run 100 stores - there is no use case for a 100 store view deployment. Just because you can do it, doesn't mean it should be capable of performing. Really, the Ferrari analogy is perfect here - just because you can attach a tow rope to a 40T trailer, doesn't mean it was designed to do it.

            3-4 store views, sure, 5-10 - maybe, 10+ - start asking yourself why you have so many store views. Odds are you are using them for the wrong reason (language translation and different designs being the most common misuse).

            Most merchants whose requirement is to have 100+ store views will almost definitely be using a peripheral system for inventory management, not Magento - which would act as the hub, and the Magento store (eBay store, Amazon store ... ) as the spokes. Magento isn't an ERP system, its an e-commerce platform.

            With all due respect to Magento - their own website is one of the slowest websites I've ever used. Their "whitepapers" are fictional marketing tools.

            Again, I'm reiterating here, in pursuit of Magento performance. The web server is not the bottleneck, PHP is. If you want a faster store, stop wasting time messing with the web server and focus on where the actual bottleneck is. At a given point, it will shift - and at that point, you can look at tuning the web server. Note, I say tune - not replace. Apache is a perfectly suitable, perfectly performant product for a Magento store of any size.

            We don't use Nginx for any performance related myth - we use it because we can't get Apache to do many of the complex, behind-the-scenes tasks that MageStack does. If we could re-engineer some of our Nginx modules to run with Apache, we would do it in a heartbeat.

          • HHDev

            Love the Ferrari reference! Lol!!

          • Alex Stephens

            This is a bit wrong. Nginx Definately handles requests BETTER than apache. Apache handles every requests in a different thread, causing disk I/O slowdown along with RAM and CPU hogging. Nginx is a bit more advanced. They adopted an Event-Driven Architecture. This allows nginx to spawn many requests in a single thread thus decreasing disk I/O and RAM/CPU usage. A thread can consume up to 64mb of memory depending on your settings. While Apache will use up ram trying to spawn an endless list of threads, Nginx will go for Event-Driven threads.
            So when Apache serves a 10KB JPEG, it may actually be using a significant amount of RAM. More than Nginx will ever use. It becomes worse if you have slow clients (e.g. smartphones) where the request may keep a thread busy for several seconds.

            Also, if u set php-fpm process manager and ondemand, it will reduce more ram.

          • sonassi

            Hi Alex,

            You are right, Nginx is much more memory efficient. But that wasn't in question, in fact if you read my comments in reply to other questions, you'll see me confirm that Nginx is memory efficient. We like Nginx and hundreds of our servers running MageStack use Nginx.

            But memory efficiency doesn't not mean increased performance for a Magento store. What I was driving at with the article is that most web servers are more than capable of delivering exceptionally high performance. Most will deliver higher than 10,000 requests per second without breaking a sweat.

            Now PHP rendering Magento on the other hand can't get close to 10,000 requests per second, you'd be lucky to hit 100.

            Once you've managed to saturate the web server, ie. Greater than 10,000 requests per second - then you can look at web server optimisations/changes.

          • Eric Covener

            Threads slow down disk I/O? #science

  • jameswagoner

    Seems like I gained more knowledge through a comment discussion than the main article. Thanks to @sonassi:disqus and @joshribakoff:disqus for keeping it a professional debate.

    Question I have is that this article is two years old. Has any enhancements that Magento made to EE versions call for an updated article?

    • sonassi

      Ultimately no. As the bottleneck isn't the web server. Apache can deliver 12,000 requests per second, on a stock configuration on a quad core machine.

      When you are able to get PHP to process more than 12,000 requests per second for a Magento store, then you can consider changing it for performance reasons.

      Otherwise, the original statement is entirely true, the web server simply isn't remotely a bottleneck.

  • learned a lot as well with the discussion initiated by Josh Ribakoff. In my case, I switched from IIS on a Windows Server 2012 with HDD and PHP to Ubuntu server with SSD and Nginx + php-fpm. so yes, performance gain was tremendous, mostly with the disk I/O.

    I just wanted to add that Nginx, although having less support than Apache overall has a clearer support, the syntax is as well, IMHO, a lot more easy. The default is that to get a config done, it is not as simple as dropping a htaccess file by FTP (Though I think I saw somewhere that it would work too).

    Finally, I think the title of the article is the problem, it should rather be "Why Nginx is not going to save my Magento store from the slow response?"

    • sonassi

      The title was more flippant than anything else! We use Nginx ourselves on MageStack - purely for the configuration syntax - as its far more natural and flexible for a developer to utilise.

      • yes, I am no developper (I qualify myself of Tinkerer) but I as well like the way the config works in Nginx, For Apache, I never liked the URL rewrite rules syntax.

        anyway, it was nice to see that Nginx performs same as Apache in some way, and better in other ways.

  • Andrew Shaw

    Has anyone had experience of hosting Magento on LiteSpeed? LiteSpeed launches PHP faster than either NGINX or Apache, and has better opcaching. Since version 5 it also has LightMage cache, which integrates with Magento via a plugin allowing "hole punching" so that private and public caches can be combined by the webserver using "Edge Side Includes". Litespeed say this is 20x faster than NGINX with Turpentine (tuned varnish)?

    • Hey Andrew,

      We performed several thousands of hours of R&D when we wrote MageStack (the Magento operating system); and something that rang true throughout is that LiteSpeed offers absolutely no performance advantage over a standard PHP release for Magento.

      Selected synthetic tests will show in specific situations that LiteSpeed outperforms PHP, but in real-world use for a production Magento store, it doesn't. If anything, the licensing model and costs limit scalability causing a reduction in overall performance.

      Regarding Varnish, do not confusing caching with performance. The two are completely independent technologies. Extensions that leverage Varnish (like Turpentine) do not make sites faster, and test upon test of real-world stores will highlight this fact (see the notes on 3rd party cache modules here, https://www.sonassihosting.com/help/magento-management/cache-management/).

      Caching != Performance and there is no point measuring performance of cached content, because by nature, cached content is instant. The key to performance is to improve performance, not blindly mask poor performance behind a cache.

  • Nam Bui

    Nginx is a waste of time for Magento. Alleviating Apache's processes by adding caching services like Redis and Opcache will make the system perform just dandy. I stopped fooling around with Nginx because Magento was written with Apache in mind; hence all the .htaccess files through the whole application.

    Great article and comments.

  • my developer is stating nginx offers more stability than apache for our magento stores , http://www.audiobuy.com.au - wrong ?

  • What is today's scenario? I read a 3 year year old debate which was really to the point. But I would like to know if there are any advancements

    • Pandu POLUAN

      Apache (using MPM-Worker or MPM-Event) and Nginx are now neck-to-neck.

      The bottleneck is still with PHP-FPM.