Amasty Research: What server optimizations for Magento really work?

Table of Content

Amasty Research: What server optimizations for Magento really work?

Magento stores owners often look for the ways to speed Magento up in order to increase the level of customer service. Internet is full of recommendations on a fine-tuning of the server software, which suppose to help in attaining maximum performance boost. Which of them really work? Amasty Team has conducted research and is ready to share with you the results of it inside.

In this article we won’t focus on the issues concerning the fine-tuning of web-server, PHP or database server parameters, since it’s too hard to provide accurate settings data that would guarantee the performance increase of a Magento store. Instead, we would analyze a few simple variants of performance boost anyone can implement:

  • PHP accelerator installation;
  • Database server selection;
  • Proper disk drive type selection;

 Looking for the way to optimize your Magento / Magento 2 performance? Have a look at our new Magento 2 Speed Optimizer. By the way, we have the analogue for Magento 1 too.

PHP accelerator installation

Today a few accelerators are available for PHP: APC, Xcache, Zend OpCache. A number of tests show Magento performance boost with the use of any of these accelerators. But which of them provides the highest boost? Is there a difference in the performance depending on PHP version? In this article we will test the above-mentioned accelerators and compare their productivity.

Database server selection

A significant part of the hosting companies offers include database server on the basis of MySQL Community Edition produced by Oracle. Some of the hosting companies that specialize in the server optimization for Magento offer as an alternative PerconaServer produced by Percona.

PerconaServer is an alternative realization of the MySQL compatible database server and can be used in Magento without any code modifications. But is it more efficient than regular MySQL server? Should one switch to this server if he is already using MySQL server by Oracle? In this article we will try to answer these questions.

Proper storage selection

Only 5 years ago the majority of servers were provided with classic mechanic HDD. But today SSD has undoubtedly conquered the market and taken a significant share from their slower colleagues. It wouldn’t take you long to find a server with SSD instead of HDD installed or to upgrade an existing one with a new SSD.

SSD speed exceeds regular mechanical disk in dozens of times. As time passes the price for SSD-based solutions has significantly decreased and the stability has increased. In this article we will try to compare the performance of a Magento store working on HDD and SSD.

Test configuration description

Hardware configuration

CPU: AMD FX(tm)-6100 Six-Core Processor

RAM: 16GB

DISK: SSD 128G (OCZ Vertex4) or HDD 500G (WDC WD5000AAKX)

Test methodology description

Both configurations work on the basis of the operation system Debian GNU/Linux (amd64), Nginx, PHP 5.4.4 or PHP 5.5.9 (10 FastCGI workers), MySQL 5.5.35 or PerconaServer 5.5.36.

To create a store traffic Siege utility is used. It imitates random clicks on links of the store (links are taken from the file sitemap.xml of the store).

$ siege -t 60s -i -f siege.urls.txt -c <num-users>

t 60s — to perform test during 60 seconds

c <num-users> - to imitate simultaneous activity <num-users>

i — to use random delay intervals before the repeated request (imitates reading of the page by the user)

f siege.urls.txt — to specify the file that contains the list of URLs for testing

Since not all have the same amount of visitors, we had a few gradations of the amount of the simultaneous users: 5, 10, 15, 20, 25, 30. This should be enough to estimate the influence of the chosen optimization on the final performance.

HDD vs SSD — should I use old technologies for my Magento store?

Despite the popularity of SSD a significant amount of servers till now use slow mechanical HDD. Among the advantages of them are low cost per 1 Gb, reliability proved by time and the great amount of hosting companies, offering servers with HDD. But is it good to use an old-fashioned technology in the cases, where the speed of customer service is of highest importance?

In order to give you a more detailed picture we have tested the Magento performance on configurations with SDD and HDD.

Server running on HDD disk (catalog/product)

 

Number of concurrent users

 

5

10

15

20

25

30

Response time, secs

0.26

0.30

0.44

0.63

0.89

1.19

Transaction rate, trans/sec

6.72

12.73

15.95

17.53

17.73

17.76

 

Server running on SSD disk (catalog/product)

 

Number of concurrent users

 

5

10

15

20

25

30

Response time, secs

0.20

0.22

0.31

0.45

0.61

0.91

Transaction rate, trans/sec

6.82

14.32

18.55

21.15

22.35

21.22

 

Server running on HDD disk (search)

 

Number of concurrent users

 

5

10

15

20

25

30

Response time, secs

0.226

0.362

0.544

0.724

0.902

1.083

Transaction rate, trans/sec

21.8

27.2

27.2

27.2

27.3

27.2

 

Server running on SSD disk (search)

 

Number of concurrent users

 

5

10

15

20

25

30

Response time, secs

0.176

0.312

0.467

0.619

0.775

0.921

Transaction rate, trans/sec

27.8

31.6

31.7

31.8

31.8

32

 

Response time (less is better)

 

HDD vs SSD performance comparison (less is better)

Diagram Response time shows insignificant excel of SSD over HDD in the tasks concerning customer service (catalog or product page view). This can be put to the fact that in this test Magento performance was limited to the calculation capacity of the CPU units that took part in the test. During the test it took us a lot of effort to achieve the usage of HDD on 80-90%, this is enough though to ignore the speed difference between SDD and HDD in theory. If you don’t use your HDD on 100%, this is not a thin place of the server performance.

But totally different situation (diagram HDD vs SSD performance comparison) happens at the backend operation (e.g. index recalculation, back-up). In this case SSD shows a significant excel in any type of operations. We have also looked into the case, when a server doesn’t contain all the necessary data in the cache of the file system (in the diagram this case is referred to as cold cache). In this case the speed of the operations performance to a great extent depends on the disc performance, since data are to be read from the disc.

These results draw us to the following conclusion:

  • Server should have enough RAM for efficient work of the disc cache. In this case all static data will extracted from a very quick Memory cache and performance of the disc wouldn’t influence these operations.
  • SSD installation will speed up the performance of the reindexation and back-up operations, but it can show no significant increase for frontend operations (in case disc cache works efficiently).

Comparison of PHP accelerators

When PHP interpreter performs the requests received from the web-server, at first code is loaded (script dependencies are found and loaded) and then the result is transformed into the intermediate code (PHP opcode) and only after that PHP interpreter starts the execution of the opcode received.

The essence of the PHP accelerators work lies in the caching of the received at the next to last stage opcode, which lets one skip the stage of code load and transformation for further requests. This way the increase in the performance is received only after the second request of PHP script, opcode of which is already in the cache. This is why you wouldn’t receive performance boost if PHP works in CLI mode. In such case opcode cache is destroyed right after the finish of the script that created it and will be initialized at the next interpreter launch in the CLI mode.

Since PHP 5.5.x contains built-in accelerator ZendOpcache in order to compare the performance of PHP 5.4.4 and PHP 5.5.9 accelerator was forcedly turned off (opcache.enable=0 in PHP.INI).

Since APC is not ported to PHP 5.5.x, PHP 5.4.4 is used to test all accelerators.

PHP 5.4.4, MySQL 5.5.35

Additional PHP settings for this test:

  • memory_limit=512M
 

Number of concurrent users

 

5

10

15

20

25

30

Response time, secs

0.59

0.77

1.37

1.95

2.59

3.33

Transaction rate, trans/sec

4.61

7.73

8.07

7.98

7.86

7.63

 

PHP 5.5.9, MySQL 5.5.35

Additional PHP settings for this test:

  • memory_limit=512M
  • opcache.enable=0
 

Number of concurrent users

 

5

10

15

20

25

30

Response time, secs

0.59

0.81

1.34

1.97

2.53

3.07

Transaction rate, trans/sec

4.32

7.52

8.06

7.96

8.09

8.14

 

PHP 5.4.4 (APC 3.1.13), MySQL 5.5.35

Additional PHP settings for this test:

  • memory_limit=512M
  • apc.enabled=1
  • apc.cache_by_default=1
  • apc.shm_size=64M
 

Number of concurrent users

 

5

10

15

20

25

30

Response time, secs

0.47

0.65

1.04

1.56

2.04

2.50

Transaction rate, trans/sec

4.72

8.74

9.66

9.57

9.71

9.74

 

PHP 5.4.4 (Xcache 3.1.0), MySQL 5.5.35

Additional PHP settings for this test:

  • memory_limit=512M
  • xcache.shm_scheme="mmap"
  • xcache.size=64M
  • xcache.count=6
 

Number of concurrent users

 

5

10

15

20

25

30

Response time, secs

0.51

0.65

1.21

1.63

2.18

2.72

Transaction rate, trans/sec

4.89

8.29

8.85

9.24

9.06

9.07

 

PHP 5.4.4 (ZendOpcache 7.0.3), MySQL 5.5.35

Additional PHP settings for this test:

  • memory_limit=512M
  • opcache.enable=1
  • opcache.memory_consumption=64
 

Number of concurrent users

 

5

10

15

20

25

30

Response time, secs

0.38

0.52

0.78

1.13

1.55

1.93

Transaction rate, trans/sec

5.48

9.85

11.82

12.29

11.96

12.19

 

PHP 5.5.9 (ZendOpcache), MySQL 5.5.35

Additional PHP settings for this test:

  • memory_limit=512M
  • opcache.enable=1
  • opcache.memory_consumption=64
 

Number of concurrent users

 

5

10

15

20

25

30

Response time, secs

0.40

0.47

0.71

1.19

1.52

1.80

Transaction rate, trans/sec

5.49

9.87

12.11

12.05

12.25

12.72

 

Transaction rate (more is better)

Both diagrams show undoubted excel of Zend OpCache accelerator. During the test of PHP 5.4.4 and PHP 5.5.9 without accelerators and with Zend OpCache turned on the performance has no significant differences. This way one can say that there is no point in upgrading to PHP 5.5.x if you are already using PHP 5.4.x. It’s enough to install accelerator Zend OpCache to to the PHP version you're using.

Comparison of MySQL 5.5.35 and PerconaServer 5.5.36 compatibility

One of the main optimizations offered for Magento is the change of the default database MySQL Community Edition to PerconaServer, which is the improved version of MySQL Community Edition and is developed by the independent company Percona.

MySQL 5.5.35

 

Number of concurrent users

 

5

10

15

20

25

30

Response time, secs

0.59

0.77

1.37

1.95

2.59

3.33

Transaction rate, trans/sec

4.61

7.73

8.07

7.98

7.86

7.63

 

PerconaServer 5.5.36

 

Number of concurrent users

 

5

10

15

20

25

30

Response time, secs

0.60

0.85

1.34

2.04

2.59

3.24

Transaction rate, trans/sec

4.52

7.36

7.99

7.85

7.77

7.76

 

Transaction rate (more is better)

 

Response time (less is better)

The test of the database server influence on the performance shows insignificant difference. This can be put to calculations inaccuracy. This lets us say that PerconaServer has no significant differences from MySQL CE, which is proved by performance tests.

The difference in the versions can be important only to those installations that process a significant amount of orders.

Still confused about server optimizations for your Magento store? Drop us a line, and we'll help you straight away.

April 1, 2014
June 5, 2014
February 21, 2014
Comments
Benjamin Samson
April 2, 2014
amazing job !
Reply
Vera Rabkina
April 2, 2014
Our pleasure to hear that :)
BettyFT
April 9, 2014
Hey There. I found your blog using msn. This is a really well written article. I will make sure to bookmark it and return to read more of your useful info. Thanks for the post. I will certainly comeback.
Reply
Ksenia Dobreva
November 6, 2014
Thanks for reading and commenting!
Dave Macaulay
April 11, 2014
Really interesting write up. Certainly going to deploy some of your findings on our clients servers.
Reply
Vera Rabkina
April 11, 2014
Glad you enjoyed it (:
Betty
April 19, 2014
I feel this is among the most vital information for me. And i am happy reading your article. But want to statement on some basic things, The web site taste is great, the articles are truly nice : D. Just right activity, cheers
Reply
Ksenia Dobreva
November 6, 2014
Thanks for reading and commenting!
Eva Monedos
April 29, 2014
Wonderful post! We are linking to this great article on our website. Keep up the great writing.
Reply
Ksenia Dobreva
November 6, 2014
Thanks for reading and commenting!
Joseph Geller
July 31, 2014
Will Magento run on phph5.5? I thought even with the 1.9 release it still requires php 5.4 with the magento php patch for it. I was accidentally upgraded today to php5.5 on a 1.7.0.2 Magento site that was running php5.4 with the patch and it went berserk. I had to recover from a server image i have backed up nightly to get it running again. Also running Ultimo on the frontend.
Reply
Vera Rabkina
August 2, 2014
Joseph, it should run fine. We run PHP 5.5 on our own amasty.com website. Should you experience any issues, you can contact us for assistance. We offer system administration services performed by a highly-qualified administrator.
Nikita S. Doroshenko
August 16, 2014
Is there are any special core changes or local.xml settings that we need to make, to let Magento work with Zend OPcache? You know, to make magenta work with APC, you need to edit /app/etc/local.xml, and to make magenta work with Xcache, you need to edit local.xml too, and plus, you need to change app/code/core/Mage/Core/Model/Cache.php (±line 181) - change $enable2levels to false. And what about Zend OPcache?
Reply
Ksenia Dobreva
November 6, 2014
Hi and thanks for asking! Sorry for the late reply. Opcache is different from APC and XCache because it doesn’t have user data caching. It caches php opcode only, and you don’t need to adjust settings in Magento. So if you want to use cache, consider ZendOpcache + Redis. Hope it helps!
Ralph Leo Bennett
November 6, 2014
Outstanding work there, our Magento store is about to launch and runs alongside a heavily optimised Xenforo instance (and themed as such). From all the work I'd put in testing out countless configurations for speed I'd come to the conclusion that Nginx, Percona and Memcached were the way forward for the forum, with heavily on-page optimisations as well. Seeing the real world HDD/SDD benchmarks and various cache types head-to-head really helps us make a decision moving forward. I host numerous sites and the limited performance testing on Magento forums so far on them showed that Nginx/PHP-FPM greatly outperformed Apache, OpenLitespeed was a bugger with configuration but also looked promising (client was willing to bite though). Last point, of every server I run, not a single one runs native MySQL Server anymore, Percona all the way.
Reply
Ksenia Dobreva
November 6, 2014
Ralph, thanks for the kind words and for sharing your experience, we're always happy to see this kind of practical feedback.
Alex
December 3, 2014
Thanks!
Reply
Oriol
February 21, 2015
Thanks!
Reply
Ksenia Dobreva
June 15, 2015
Thanks for the comment, we're happy it was useful!
Reply
Eric Gajewski
July 16, 2015
We offer our clients well optimized Magento hosting on a Nexcess SIP-500 server, which uses HDD's. They are constantly being pitched by other hosting companies that use SSD's, claiming they provide 200%+ faster load times. Our real world tests had similar results as this. Under normal operating conditions, the load times were actually not perceived as being faster to end users. On the other hand, HDD's are still considered more reliable, which is considerably more important. Who cares how fast it should load if it doesn't! We are still testing PerconaServer, your test results are similar to what we are expecting. By far, the biggest improvement in load times came from installing Full Page Cache by Amasty. The second biggest improvement came from using a well executed content delivery network, CDN. Thank you for keeping us informed on advances for the Magento platform.
Reply
Ksenia Dobreva
July 17, 2015
Hi Eric, many thanks for the kind words and for sharing your valuable experience with the readers! We will work further to deliver useful content and encourage readers to find better solutions.
Kwan
February 26, 2016
awesome! tons of help! thanks !
Reply
Ksenia Dobreva
March 3, 2016
thanks for reading!
Leave your comment

Your email address will not be published

This blog was created with Amasty Blog Pro

This blog was created with Amasty Blog Pro