There are many options for improving the performance of an Magento installation but little benchmarking data regarding what sort of improvement they make. In this series of posts I will use a small virtual machine and test the some performance options to see which have the greatest impact on performance.
In this first post I am going to test a completely unmodified Magento installation using the sample data to provide the content. I am going to keep the specs of the machine I run Magento on as low as possible to see what can be achieved on limited hardware.
I followed my own 10 minutes Magento installation guide to get Magento installed in its default configuration:
- 1 GB RAM
- 1 Core (4589.21 bogomips)
- SSD (915.64 MB/sec)
- $5 USD per month
- Debian 10 Buster
- Apache 2.4 (compression enabled as per default setting)
- PHP 7.3
- MariaDB 10.3
- Magento 2.3 with sample data
I spun up a second VM 1GB VM to act as the benchmarking server. This VM is attached to a 1GBps private network that the Magento instance is also a part of so bandwidth will not be a bottleneck.
The following wget command spiders a site, extracts the all the URLs and dumps them to a file:
wget -r -p --delete-after http://magento.example.com 2>&1 | grep http | cut -d" " -f4 | grep ".html" >urls-http.txt
Any URLs that do not contain in
.html will get ignored. They are not needed as Siege will automatically grab them. I created a second file by editing the
http URLs to
https urls so I can benchmark using both protocols.
The Siege command I used was the following:
siege --benchmark --internet --time=60s --concurrent=5 --file=urls-https.txt
I found that setting the
--concurrent number too high caused Apache/MySQL/system failure due to a lack of memory. You will need to play with this figure to find out how far you can push your VM to maximize throughput before system instability.
Warming Magento’s cache
Magento enables a cache with he default installation that is very effective. My first run with siege got around 4 transactions per second. However, once the cache was “warm” that is once all the HTML pages had been generated and cached that number increased dramatically as you can see below. You will need to make sure that you have requested all the pages at least once before you make any benchmarks.
The following are the results for HTTP and HTTPS benchmarks of a default, un-modified installation using standard PHP 7.3:
|Stock server||147 trans/sec||111 trans/sec|
The transactions per second include the requests for images and other page assets so this number does not represent the number of “pages” as you would see in a browser. In fact, the page at https://magento.example.com/men.html makes 206 requests to render in a browser. A lot of these assets will be cached by the browser so turning the transactions per second as shown in the table is quite hard to equate to how many completed pages per second are possible.
This number will be the number I will compare as it provides an absolute and reproducible number which directly correlates with number of pages that Magento instance is able to serve.
In the next post the standard PHP library will be swapped out for PHP-FPM. Due to the amount of caching that is already going on I’m not sure how much difference this will make. PHP-FPM is a quick and simple installation process with packages available in the default Debian repos. It will also be interesting what difference PHP-FPM will make over stock PHP.