Site: US UK AU |
Nexcess Blog

Nexcess Publishes Comprehensive Magento Optimization Guide With Benchmarks

April 8, 2013 7 Comments RSS Feed

Nexcess Publishes Comprehensive Magento Optimization Guide With Benchmarks

Southfield, MI, April 8, 2013 – Nexcess, a provider of optimized Magento hosting and Magento Platinum Hosting Partner, has published “Magento Hosting: Best Practices for Optimum Performance”, a free white paper that contains guidance and analysis regarding the best configuration of Magento Enterprise Edition and the applications it relies on.

Based on extensive testing, the white paper makes a number of suggestions for configuring Magento for optimum performance. Nexcess found that Apache and Nginx, when configured properly, produce roughly equivalent performance, that full page caching with a Redis backend produces significant performance enhancements, and that using Varnish in front of the HTTP server with the Nexcess-developed Turpentine plugin can increase transaction per second throughput by as much as 1,000%.

“Magento is very capable and relatively quick out of the box, but eCommerce requires the best possible performance; reduced performance leads directly to lost sales,” commented Chris Wells, President and CEO of Nexcess, “This white paper, based on our long experience with Magento and careful empirical testing, sets the standard for highly performant Magento deployments.”

Nexcess tested various configurations using one of their MCE-SIP-200 server clusters, which consists of a pair of application servers, a database server, a dedicated file server, a firewall, and a dedicated load balancer. Benchmarking was carried out with the open source HTTP-based benchmarking utility, Siege, and the Gatling stress tool.

The white paper presents the benchmark results of various configurations in order to determine the most performant combinations. Among the configurations considered in full are:

  • Whether to use NFS or locally synced file storage.
  • Which of Nginx or Apache produces the best performance and with which configurations.
  • Whether MySQL or Percona are the best choice of database server and under which conditions each is appropriate.
  • A comparison of an optimized standard Magento site and a Magento site optimized with the Varnish web application accelerator and the Nexcess-developed Turpentine plugin.

Also discussed are the use of memcached, PHP-FPM, Redis, and Alternative PHP Cache. Additionally, the white paper contains extensive discussion of the Magento Enterprise Full Page Cache and the various other caching options Magento Enterprise offers.

“Magento Hosting: Best Practices for Optimum Performance” is available for free and can be downloaded from the Nexcess website:

About Nexcess
Nexcess is a Southfield, Michigan-based managed hosting company founded in 2000, with wholly owned data centers located in Dearborn, Michigan and Southfield, Michigan. Nexcess offers a variety of hosting services ranging from entry-level packages to custom clustered/complex hosting configurations, with an emphasis on mission-critical hosting for high-profile eCommerce web sites. For more information, visit

Posted in: Magento, News Releases
  • Best whitepaper on Magento performance.

  • I know right?!

  • Hacksmith

    “Full page caching with a Redis backend” is one of the least intelligent ways to use Redis.

    Redis is an in-memory service with data structure storage and operations with persistence to disk. *But* it only does one operation at a time, which makes it most suitable for small pieces of data (session data, for example), or larger data that is stored in Redis in smaller chunks (keys within a data structure).

    If you use Redis for fullpage caching and your pages are full-fledged web pages, like on a media site or ecommerce site, you will no doubt get terrible performance.

    Fullpage caching is better implemented with a service like Memcached (which is multi-threaded).

    Caching in general (fullpage caching being one case) implies that computation and work is done elsewhere, so persistence to disk shouldn’t really matter, but if it does, and you don’t want to have to warm your cache, you can save the data to disk or use a Memcached equivalent (a multithreaded one) that does persistence.

  • Hacksmith,

    Redis is indeed single-threaded (as stated in our results within
    the white paper). Because of this, it could potentially suffer during
    extremely high workloads. Even with the highest traffic tests
    we threw at it, its single-threaded design was not a performance
    limiting factor when used with the full page cache. The
    Cm_Cache_Backend_Redis module (which was also used) implements pipelining
    and allows Magento to send multiple commands to Redis without waiting
    for the replies and, finally, read the replies in a single step
    (thus increasing performance).

    Redis, when used for the Magento full page cache, will still outperform file based caching
    (even being single-threaded) as Redis does not have the additional
    filesystem I/O overhead. The full page cache data also does not require
    persistence. Due to the fact a multiple web node clustered
    environment was being tested, any file-based cache storage would not be
    recommended (leaving the choices of Redis or memcached). While memcached
    (in theory) would be able to outperform Redis when used for the full page
    cache under extremely heavy workloads, its use would break Magento admin
    cache flushing capabilities due to its lack of tag support.
    Consequently, the use of memcached as storage for a full page cache is
    not recommended. Additional information regarding Redis and its
    single-threaded design versus memcached and its multi-threaded design (along
    with recommended use cases) can be found within the white paper.

  • Hacksmith

    Thanks for clarifying Brad,

    You are right, a central service is far better than caching to disk, especially becuase you have multiple servers able to access the same cache. If you only use Redis for your fullpage cache, you may be able to get by (but your site will most likely die with a slight DDOS attack).

    This recommendation seems a little problematic to me because I see some developers from the Magento community having the perception that it’s so much better to use Redis instead of Memcached for their caching… but I have to strongly disagree on this… because if they apply this idea to caching larger objects (hundreds of kilobytes to megabytes) performance disappears. That’s just not what Redis is made for or ideal for, just as a MySQL installation with a high transaction rate isn’t ideal for session storage on high volume sites…. This is one area where Redis would shine (session storage)

    We’ve had both of these experiences at our company. Redis gave us awesome performance for sessions and certain data manipulations, but when larger objects were stuffed into it (100-500KB for example) and accessed on each hit, occasional errors were seen (because Redis would be busy) and during a DDOS things went south fast.

    I understand the lack of tagging that memcached has. We overcame this by implementing very simple namespacing within memcached and simply reset entire namespaces when necessary.
    For each namespace (e.g. “chairs”) we generate a random value and store it under the key “chairs”.
    When someone wants to access the key “sofa” from the namespace “chairs”, we load the value stored at “chairs” (for example 24352345) and append that to “sofa”
    –> we get 24352345_sofa… and that is the key we use to store and retrieve the value for “sofa” under the namespace “chairs”. Resetting the namespace is as simple as changing the value for “chairs”
    This has worked exceptionally well for us.

  • Thak you for creating this white paper it sure will come in handy

  • Aleksey Korzun

    Just wanted to chime in with few small corrections:

    “Redis, when used for the Magento full page cache, will still outperform file based caching(even being single-threaded) as Redis does not have the additional
    filesystem I/O overhead.”

    While this is true for extremely high load conditions (where everything else can keep up and you rely on caching 100%) for smaller number of requests, overhead for sending data to Redis instance could be slower than raw I/O.

    For example, 5 r/s could be faster on direct I/O access than network I/O even with Redis and 100 r/s will most likely be faster on Redis.

    “Consequently, the use of memcached as storage for a full page cache is
    not recommended.”

    Why not? If anything full page caching SHOULD be on memcached as it perms better and with combination with IgBinary it will be firing off extremely fast.