Magento – Page load time below 0.3s? Magento – Page load time below 0.3s?

More and more often adverts show us that the hosting provider promises us response times of less than 0.3s for Magento instance. Is it possible to achieve such an outcome without interfering with the Magento code? Or is this another marketing gimmick? We felt it’s worth verifying this thesis.

Therefore, we conducted a series of tests, at the same time comparing the influence of the number of cores, additional services such as Varnish, Redis or HHVM, as well as direct comparison with Nginx and Apache. Does the winner reach the limit of 0.3s? You’ll find out below :)


All the tests were performed on two virtual machines (VMware Player 7.1.0), one with Nginx 1.6.2, the other with Apache 2.4.10 server.

After each test (2 calls), appropriate services were restarted. Each machine had the following configuration:

  • 2GB RAM
  • 1, 2, 4 or 8 cores (hardware support for VT-x, VT-d and EPT virtualizations)
  • Debian 8 (RC 1)
  • Linux 3.16.0-4-amd64
  • PHP 5.6.6-2
  • Zend Opcache v7.0.4-dev
  • Varnish 3.0.6
  • Redis 2.8.17
  • MySQL 5.6.17
  • HHVM 3.6.0
  • Magento + Sample Data
  • Magento Redis Session Cm_RedisSession
  • Magento Varnish PageCache powered by Varnish

Hardware configuration:

  • Intel i7-4710HQ 2.5GHz – 3.5GHz 4C/8T
  • RAM DDR3 1600MHz 16GB
  • Graphics card Intel HD 4600 + NVIDIA GeForce GTX 860M 4GB
  • Hard drive Samsung SSD 850 PRO 256GB

The tests were performed for Magento main page + Sample Data with cache enabled.

Varnish – HTTP reverse proxy

Probably all the major websites are using this accelerator. The principle is very simple – it involves “mediating” between the client and backend (Apache, Nginx, etc.) – it’s so-called reverse proxy server.

In the case of a dynamic page that generates one system, the first request goes through Varnish server and is sent to backend, from where the data is collected and stored in Varnish cache.

Each subsequent request is taken directly from the proxy cache, without reference to backend.


Of course, in most situations pages consist of blocks of variable content, such as shopping cart or login, which prevent full page caching. A useful tool in such situations is ESI (Edge Side Includes), which enables caching of individual fragments of pages.

The entire configuration mechanism is based on the Varnish Configuration Language (VCL). VCL files are translated to C, compiled and loaded directly into the accelerator during startup.

They contain defined caching scenarios, definitions of returned headlines, links and rules exceptions, etc.

The tests employed PageCache powered by Varnish module supporting version 3. Currently there is no support for version 4.

Below you can see a comparison of the maximum efficiency of Varnish versions 3 and 4 in conjunction with Apache server on an 8-core machine.


Here you can see the difference of approx. 50% in favor of Varnish 4. If we compare PHP-FPM with Varnish 3 server for Magento, the situation is as follows:


The difference is more than 1400% in favor of the reversed proxy.


Redis is a NoSQL type database server that stores data in RAM and operates on key-value type records.

It significantly increases the speed of applications using sessions and caching system based on file system, which is one of the slowest server components. Even SSDs are not able to match RAM, which can be even 40 times faster. The exception to that rule can be, e.g. RamSan 5000.

Redis also supports replication and working in clusters.


At first glance, we see 10% increased performance in the graph above. However, ab test call doesn’t create a session on Magento. Let’s try to see if we can really get an increase in efficiency using the session.

To do that, we clean the Redis database and generate a query using the telnet command:

redis-cli flushall

telnet 80

> GET / HTTP/1.1

> host:


On the other machine, we check the session ID:



> KEYS *

1) sess_[KEY]

If you are using MySQL, the key is located in core_session table, and the file system can be found in var/session/sess_[KEY].

With this data, we can call ab with -C parameter and the key to our session:
ab -n 1000 -c 100 -C ‘frontend=KEY’

Nginx server results are as follows:



As you can see, using Redis doesn’t provide the intended results. Moreover, it gives the worst results! This is probably due to incorrect implementation of a module for operating  Redis.

HHVM – HipHop Virtual Machine

HHVM is a virtual machine developed by Facebook, based on JIT compilation and allowing for the execution of a code written in PHP and Hack.

It can also be run with PHP-FPM service (e.g. use PHP-FPM for .php files and HHVM machine for .hh files).

The whole process of running a script is to convert the code to HipHop bytecode (HHBC), which is then translated into machine code x86-64, optimized and executed natively.

In the case of a very complex PHP code, it is possible to achieve even more than 14-fold increase in efficiency and a significant reduction in memory consumption.

A very interesting case “Wikipedia on HHVM” shows 45% increase in efficiency compared to PHP5 in the production environment.

Let’s look at the following comparison of maximum Nginx performance with PHP-FPM and HHVM on an 8-core machine for an empty php script, a script executing P1 loops and for the Magento code.

diagrams21For Magento:


When the script is not highly demanding, HHVM slightly loses to PHP-FPM (approx. 10%). The situation is reversed dramatically when the script gets more demanding – the difference in such case is more than 1200% in favor of HHVM!

For Magento there is a 3-fold increase in efficiency.

Loop P1:

for ($i = 0; $i < 100000; ++$i) {

if ($i % 2) {

$j[] = $i * 1440 * 220 – 23;


else {

$k[] = $i * $i * time();



Apache mod_fastcgi and mod_proxy_fcgi + mod_proxy

There are many ways to integrate Apache with PHP-FPM, e.g.: mod_fcgid, mod_fastcgi, mod_proxy_fcgi and mod_authn_fcgi. Currently, the most popular are mod_fastcgi and mod_proxy_fcgi.

mod_extfcgi is currently being developed as the only one to support filters (possibility to add additional data to answers). Below, a brief comparison of mod_fastcgi and mod_proxy_fcgi.

diagram4Apache vs. Nginx

With the same configuration (PHP-FPM running on port 9090), Apache is unable to perform the ab test -n 1000 -c 1000 (just after a few requests it reports an error!).

Nginx performs this test without any problems, and only after 10 000 requests it reports an error when calling ab -n 100 000 -c 10 000…

In Magento tests, Apache wins by 1%.



1, 2, 4, 8…

The number of cores used has a significant impact on the results. The difference between 1 and 8 cores is 309%. One has to remember that the hardware configuration is only 4 cores.

12Test results

Below are the other test results, with the information about the type of test, call number (1 or 2), the number of cores used and configuration.



14A + FPM + PROXY            Apache + PHP-FPM + Proxy Fastcgi

A+ FPM + FAST                Apache + PHP-FPM + Fastcgi

A + HHVM                          Apache + HHVM

A + HHVM + REDIS          Apache + HHVM + Redis session

A + HHVM + REDIS + V  Apache + HHVM + Redis session + Varnish

N + FPM                              Nginx + PHP-FPM

N + HHVM                          Nginx + HHVM

N + HHVM + REDIS         Nginx + HHVM + Redis session

N + HHVM + REDIS + V  Nginx + HHVM + Redis session + Varnish

N + FPM + REDIS + V      Nginx + PHP-FPM + Redis session + Varnish


Reaching the limit of 0.3s doesn’t pose any problems, which initially seemed impossible, taking into account Magento requirements.

The best choice seems to be a combination of Nginx server with a HHVM virtual machine, Varnish reverse proxy server and the session stored in a MySQL database.

Some useful links:

Varnish –
Redis –
Nginx –
Apache –



No comments so far.

Be first to leave comment below.

Your email address will not be published. Required fields are marked *