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