Amasty Research: What server optimizations for Magento really work?

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;

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.

Andrey Tataranovich

Andrey Tataranovich

Andrei believes that only at work people can fully express themselves, so he does his best to implement all his knowledge while in the office. Having made computer science his hobby, Andrei is constantly developing his professional skills. But despite such a busy schedule he always finds time to read science fiction books and communicate with new interesting people.

You may also like...

10 Responses

  1. Benjamin Samson says:

    amazing job !

  2. BettyFT says:

    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.

  3. Dave Macaulay says:

    Really interesting write up. Certainly going to deploy some of your findings on our clients servers.

  4. Betty says:

    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

  5. Eva Monedos says:

    Wonderful post! We are linking to this great article on our website. Keep up the great writing.

  6. 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.

    • Vera Rabkina Vera Rabkina says:

      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.

  7. Nikita S. Doroshenko says:

    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?

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>