Skip to content

Magento Hosting – Best Practices for Optimum Performance

This article is meant as a guide for you to ensure you’re getting the most out of your Magento Hosting by using best practices developed through real-world experience at NetSpaceIndia Magento Hosting, where we’ve been working with the platform since 2005.
Magento hosting

Magento is a popular and powerful eCommerce platform with very demanding resource requirements. While it should run out of the box, using default configuration settings, I personally recommend extensive post-installation configuration is to achieve optimal site performance (especially for high volume sites).
We outline the differences between default and/or popularly available configurations, listing the benefits and drawbacks of these changes and what we’ve found to be optimal for scaling Magento. These different configurations are extensively benchmarked showing the benefits between configuration options and the maximum performance available from each chosen setting. Using the configuration information contained within this white paper, a load-balanced web server cluster running Magento Enterprise can process over 550 transactions per second (equating to more than 47 million transactions per day). All system-level configuration files are provided at the end of this document and show the exact system settings and application configuration parameters used.
All benchmark application test configurations are also provided to show exactly how each test was run and how, if necessary, each can be reproduced.

Table of Contents

Testing Criteria

Terms and Definitions

The following terminology can at times be confusing concerning the actual process occurring. The terms used throughout this article are defined as follows:


A client who completes an order.


A user and (more specifically) the browser and/or browser mechanism used by the user. It does not, for this paper, always denote the customer of an eCommerce transaction.


The successful completion of the checkout process within Magento.

Orders per second also denoted as O/s or Orders/sec)

The number of orders processed during one second. Request Any HTTP communication sent by a client (browser, etc.) to a Magento server. This includes requests sent over HTTPS and is synonymous with an HTTP request.

Requests per second (also denoted as R/s or Requests/sec)

The number of requests being sent to a Magento server during one second. This metric does not take into account how many requests result in a successful response from the server (that is, a complete transaction).


Any HTTP communication sent by a Magento server to a client. This includes those requests sent over HTTPS and is synonymous with an HTTP response. Bear in mind, responses are not synonymous with a web page. A single web page may have hundreds of individual responses associated with it, including images, HTML pages, style sheets, JavaScript, and other static or dynamic content.


The combination of a successful request and response.

Transactions per second

(also denoted as T/s or Transactions/sec) The number of transactions completed during one second.


Synonymous with a client (for this paper).


A client who simply browses a website and does not complete an order.

Magento Hosting Hardware Architecture

The NetSpaceIndia Dedicated Server used for testing consisted of the following hardware:

Web Application Servers:
Dell R420 2x Intel Xeon 8 Core CPUs E5-2450 @ 2.10GHz
2x 147GB 15K SAS RAID-1 (H710)

Database Server:
Dell R420 2x Intel Xeon 6 Core CPUs E5-2420 @ 1.90GHz
24GB Ram
4x 147GB 15K SAS RAID-10 (H710)

File Server / Caching Server:
Dell R420 2x Intel Xeon 6 Core CPUs E5-2420 @ 1.90GHz
24GB Ram
4x 147GB 15K SAS RAID-10 (H710)

Load Balancer:
Dell R420 2x Intel Xeon 6 Core CPUs E5-2420 @ 1.90GHz
16GB Ram
2x 73GB 15K SAS RAID-1 (H710)

Benchmarking Server (from which all tests were run):
Dell R420 2x Intel Xeon 6 Core CPUs E5-2450 @ 2.10GHz
24GB Ram
4x 73GB 15K SAS RAID-10 (H710)

The testing server was placed across a gigabit network

Anatomy of a Siege Test – Raw Stress Testing

A Siege test was run on each specific configuration for 60 seconds and then repeated once per minute over 100 minutes (for a total of 100 tests). Data was collected after each 60-second run. In addition to the 100-minute tests, additional tests were run for a duration of 240 minutes each to observe any long-term behavior of the Magento configured environment.

To ensure a broad spectrum of targets, we created a static list of pages on the test site using a method popularized by Ashley Schroder on his site, Utilizing the sitemap.xml from the data sets provided by Magento on the active test site, we were provided with over 100,000 pages (including every product and category page) to test.

Each test was run five times against a particular configuration. The test results were then averaged. Before each complete run, all relevant Magento caches were flushed and then pre-warmed by having Siege hit every URL in our test file exactly once. The test file consisted of a complete Magento sitemap.

Anatomy of a Gatling Test – User Modeling Stress Testing

We used Gatling to simulate two basic scenarios:

  1.  A buyer in the following use case (in sequence):
    a. Navigate to the home page.
    b. Navigate to a category page.
    c. Navigate to a product page.
    d. Add product to the cart.
    e. View the cart.
    f. Proceed through the checkout process fully using the check/money order payment method.
  2. A visitor in anonymous catalog navigation (in sequence):
    a. Navigate to the home page.
    b. Navigate to a random category page.
    c. Navigate to a random product page.

Test 1: Apache vs. Nginx:

Apache and Nginx are the two most popular HTTP servers used with Magento. Despite the performance numbers Nginx produces on a properly configured web server, Apache is very competitive when also properly configured. The important step to be considered is how PHP is initiated when running Apache. The standard configuration is to use mod_php and doing so can provide reasonable performance.

Apache with mod_php can be tuned to perform well on moderately loaded systems but for heavily loaded systems Apache with PHP-FPM is preferred. More importantly, however, Apache with PHP-FPM provides for full user separation that isn’t easily attainable using Apache with mod_php.

For this reason, we don’t recommend its use in high-performance environments and don’t explicitly entertain it in this whitepaper. We find most comparisons of Nginx and Apache (Compare Web Servers Type) are unbalanced because of this, as Nginx is benchmarked using PHP-FPM while Apache uses mod_php, suPHP, or some other non-PHP-FPM method of handing off PHP scripts to the PHP interpreter.

We benchmarked both Apache and Nginx with PHP-FPM. This keeps the comparison balanced.


The first test run was a direct comparison of Apache with PHP-FPM and Nginx with PHP-FPM. For this Siege test, we used 250 concurrent users.

The graph shown in Diagram 3 shows the differences between Apache and Nginx when both are utilizing PHP-FPM.

The differences in performance between the two separate configurations were negligible. Nginx had less than a 1% advantage over Apache in performance over every test run. The initial ramp-up period of the graph shows a slower transaction per the second count as the various Magento caches run through their warming period. Once the caches are fully warmed (at about 30 minutes into the test) site performance remains constant.

The variance between runs also becomes very consistent once the caches are warmed (as shown in the graphs in Diagram 4 and Diagram 5)


Choosing whether to run Magento on Apache or Nginx becomes a personal choice for those running the site rather than one based on pure performance.

One advantage of Nginx is it has a built-in proxy cache similar to Varnish. That cache can be used to significantly increase performance beyond the numbers shown here but requires extensive configuration and development to make it compatible with a Magento site.

This advantage over Apache is eliminated given one can use Varnish with Apache to achieve the same results.

The biggest Apache advantage is the benefit of being fully compatible with Magento with no modifications to site rewrites or .htaccess files needed.

Test 2: MySQL versus Percona

MySQL is an extremely popular open-source relational database management system (RDBMS) for use in many web-based applications. Magento fully supports MySQL for its database and it is the recommended database to use in both the community and enterprise editions.

Percona is also an RDBMS, but is a drop-in replacement for MySQL and designed to offer higher performance over MySQL.

The Percona specifically excels at InnoDB storage engine performance with its own InnoDB engine, XtraDB. Percona also offers built-in support for better handling of NUMA-based hardware. This is particularly important when using very large Magento databases

The purpose of this comparison was to see if a properly tuned installation of Percona can outperform a properly tuned instance of MySQL for a Magento site.


For the MySQL and Percona comparison, the Gatling tool was used for all testing. Running a simple Siege test showed no difference between the two systems. Siege is not used in this case as most data is located within the various caches and, once warmed, the database subsystem is barely utilized.

Utilizing Gatling’s capabilities to simulate actual users on the site, we were able to significantly stress the database and exceed more than 7,000 queries per second. The Gatling tests simulate the actual ordering process, creating a significant amount of write-bound queries (which do not occur when a user simply browses the site).

The Gatling testing was performed in two parts. The first was using various concurrencies of buyers and visitors at a 100:1 ratio. This test was run against the MCE-SIP-200 cluster running first with MySQL and then again with Percona. Each test was run five times and then averaged to compare the number of total transactions per second against the cluster.

The results depicted in Diagram 6 show, as the number of buyers and visitors increases, MySQL and Percona have fairly equal results (with a slight margin to Percona). This trend continues until the workload increased to 30 buyers and 3,000 visitors.

This is where Percona’s advantage became apparent. It continued to hold under an increased workload of 50 buyers and 5,000 visitors.

The second part of this test was run to calculate the maximum number of orders per second an MCE-SIP-200 cluster running Percona is capable of processing. Using Gatling, a buyer test without any simulated visitors was run.
Various amounts of buyers, from 750 to 3,000, were queued and run against the cluster to see how many orders by these buyers could be processed per second. A “buyer” in this test consists of the following sequence:

  1. Navigate to the home page.
  2. After which navigate to a category page.
  3. Then to a product page
  4. Add product to the cart.
  5. View the cart.
  6. Proceed through the checkout process fully using the check/money order payment method. Each calculated order is one user performing all of the above tasks successfully.

At the peak of 3,000 buyers, Magento is capable of processing 18.9 orders per second which equate to roughly 1.6 million orders per day.

Test 3: Magento Site versus Optimized Magento Site with Varnish & Turpentine

Varnish is a reverse proxy HTTP application accelerator. Out of the box, Magento is not directly compatible with Varnish due to the dynamic nature of a Magento session-based site. By default, Varnish doesn’t cache requests with cookies and Magento sends a front-end cookie with every request causing a (near) zero hit-rate for Varnish’s cache.

Turpentine provides Varnish configuration files (VCLs) to work with Magento and modifies Magento’s behavior to significantly improve the cache hit rate

A test was performed utilizing Varnish along with the Turpentine plug-in and compared against a site not using Varnish. Because user actions (such as adding items to a cart and checking out) cannot be cached, very few performance differences were noticed during these tests. Where Varnish helps is during a typical user browsing the site.

As can be seen above, running Varnish with Turpentine in front of Apache + PHP-FPM can provide a significant performance increase.

At 250 concurrent users, transactions per second increased from an average of 548 per second to 3,800 per second with Varnish & Turpentine.

At 500 concurrent users, Varnish & Turpentine again outperformed the existing Apache + PHP-FPM setup with an average of 6,940 transactions per second over a one-hour run. This is a benchmarked 1,300% increase in performance, which potentially provides over 600 million transactions per day.

Conclusion and Additional Performance Recommendations

As demonstrated by the above testing and benchmarking procedures, a load-balanced, two web application server cluster with a single database server can process 47 million transactions and over 1.6 million orders per day. Thus, the following should be considered best practices for a Magento installation for maximum performance:

  • Run either Nginx or Apache with PHP-FPM. Both offer nearly identical performance utilizing PHP-FPM, but Apache benefits include better drop-in compatibility with Magento than Nginx. While Nginx requires more custom configuration to work with Magento, it does offer the built-in reverse proxy capability. Bear in mind, one does not simply turn this reverse proxy on; it will require extensive configuration to work with a production-ready Magento store.
  • Use Percona over MySQL if Magento will be used in high traffic installations. Percona provides better all-around performance with Magento along with consistent write performance.
  • Use Varnish as a reverse proxy server in front of your HTTP server. Utilize the Nexcess Turpentine plug-in for better compatibility between Varnish and Magento. In this configuration, a transaction per second increase of 1,300% beyond the 47 million transactions per day cited, along with a 15% improvement in orders per second can be realized.
  • Utilize a two-level cache with memcached as the fast cache and Redis as the slow cache. Be sure available memory in each of these caches is high enough to prevent forced evictions. Evictions can be checked by observing the built-in stats for each cache instance. If using the two-level cache, be sure to apply the two-level cache bug fix.

Final Thoughts

Bear in mind, all results here were tested on Magento Enterprise without any optional extensions or plug-ins installed with exception of the Cm_RedisSession add-on for Redis functionality and the Turpentine plugin where marked as used.

The addition of Magento extensions and plug-ins, depending on their functionality, inte-gration, and usage, can drastically affect overall site performance.

It is always a good practice to benchmark your site before and after an extension installation so you are aware of any performance degradation from it.

Do let me know your feedback in this case study, love to hear about your feedback

Shashi kant Pandidhar

Shashi kant Pandidhar

I’ve been helping businesses to be online for over 15 years. Today my team and I, focus on helping real businesses to overcome real-life challenges and analyse data in a way that can help businesses grow in the right direction of this digital age.

Leave a Comment

About Me

Shashi kant Pandidhar

Shashi kant Pandidhar

I’ve been helping businesses to be online for over 15 years. Today my team and I, focus on helping real businesses to overcome real-life challenges and analyse data in a way that can help businesses grow in the right direction of this digital age.

Related Posts

Follow Us


Subscribe: Trusted By 1M+ Readers

Get the weekly Tech Update straight to your inbox.

WeCreativez WhatsApp Support
Our customer sales team is here to answer your questions. Ask us anything!
👋 Hi, how can I help?