Magento/Adobe Commerce Cloud Autoscaling Performance
After my post about really bad Magento Commerce Cloud performance, Adobe has made several improvements. Let's check performance and what was done.
Historically, Magento 2 Cloud architecture consisted of 3 vertically scalable web nodes, each containing an entire tech stack (PHP-FPM, Crons, Redis, MySQL, Elastic Search ). The new feature is a PHP web-server scalable infrastructure that provides a tiered solution with a minimum of 6 nodes: 3 nodes for the core database and other services and 3 nodes for the web-server. The core servers scales vertically (increases in size), and the web tier scales horizontally (increases instance count) and vertically (changes base instance type and size).
Scaling must use the same instance type and size for each node:
M5 or M5n instancesfor each core nodeC5 instancesfor each web node
Core Nodes:
There are 3 core nodes for data storage, cache, and services: ElasticSearch, MariaDB, Redis, and more. When the core tier approaches capacity, the only way to scale is to increase the server size, such as boosting the CPU power and memory. Capacity is limited to the size of the node that is available.
Pretty big tire. Magento doesn’t have issues with normal software like Redis or Mysql written on C. The performance of the web node and Magento PHP core is the main infrastructure bottleneck. Split architecture with multiple availability zones products network latency performance issues. LAtency to Redis and Mysql ~ 1ms. Magento has 600 SQL request per page and 200 Redis call. 600 + 200 = 800ms just network wait time. High Availabilities (HA) are, in general, redundant for 90% of merchants. You are having a 1% chance to have issues with your single availability zone however you ale losing too much per performance in the network. Disable HA is not designed with this cloud.
Web Servers
There are 3–6 nodes (web nodes) for processing requests and web traffic: php-fpm and NGINX. In addition to vertical scaling by increasing power and memory, the web tier can scale horizontally by adding extra web servers to an existing cluster when constricted at the PHP level.
The web tier scales vertically instances, to accommodate an increase in process requests and higher traffic requirements.
Consider an example that the web node instance type is C5.2xlarge with 8 CPU and 16Gb RAM. The number of requests to the site increased greatly. You can add an additional C5.2xlarge node to handle the increase in php-fpm processes or you can change each instance type to C5.4xlarge with 16 CPU and 32Gb RAM. Adding an additional node reduces the risk of insufficient surge capacity.
We are using this architecture however we sill having an issue with performance because of Magento cloud broke architecture (Redundant Availability, overcomplicated MySQL Gallery Cluster replication, and Redis performance issue, GlusterFS file system, No Proper Monitoring tools, what you will have it is just NewRelic with additional performance problems with 50% overhead to TTFB)
Tested Configuration Magento Cloud :
3 core nodes:
m5.24xlarge AZ 1a
m5.24xlarge AZ 1a
m5.24xlarge AZ 1b
3 x 3.1 GHz Intel Xeon Platinum 8175 (Skylake) / 96 vCPU / 384 GiB memory
Total: 288 vCPUs
6 web nodes:
c5.12xlarge AZ 1a
c5.12xlarge AZ 1a
c5.12xlarge AZ 1a
c5.12xlarge AZ 1b
c5.12xlarge AZ 1b
c5.12xlarge AZ 1b
3 x 3 GHz Intel Xeon Platinum 8275L / 48 vCPU / 96 GiB memory
Total: 288 vCPUs
Just AWS resources cost per month:
+-------+------------+------------+------+---------------+
| Count | Unit price | Total cost | Type | Instance size |
+-------+------------+------------+------+---------------+
| 3 | $3,363.84 | $10,091.52 | m5 | 24xlarge |
+-------+------------+------------+------+---------------+
| 6 | $1,489.20 | $8,935.20 | c5 | 12xlarge |
+-------+------------+------------+------+---------------+Total: $19 026/month + the Staging environment however it has 3 web nodes ~ 14 000 AWS resources cost. ~ 33 000 Total.
It is just an approximate price of the resources if to buy directly from AWS.
Magento Cloud will add an additional 100% and it will cost around $50K per month.
We will use Apache Benchmark tools for the test and will test 1,5,10,20,30,50,60,80,120,180,200,260 concurent page views.
Ok, what performance we will have for these resources:
+--------------+------+
| cuncurrency | TTFB |
+--------------+------+
| 1 | 1500 |
+--------------+------+
| 5 | 1500 |
+--------------+------+
| 10 | 1500 |
+--------------+------+
| 20 | 1500 |
+--------------+------+
| 30 | 1500 |
+--------------+------+
| 50 | 1500 |
+--------------+------+
| 60 | 1600 |
+--------------+------+
| 80 | 1900 |
+--------------+------+
| 120 | 2500 |
+--------------+------+
| 180 | 2800 |
+--------------+------+
| 200 | 3250 |
+--------------+------+
| 260 | 3900 |
+--------------+------+
| 300 | 4000 |Performance Chart visualisation:
Base performance of the page response time: 1200ms
Response degradation after concurrent 60 requests and so huge resources can’t help fix Magento 2 Core performance. From the good, we still have responses, slow bu without errors.
We can make decisions the web site can handle ~ 60 simultaneous requests without performance degradation for the catalog pages. FPC can hide a little bit of this problem however FPC pages don’t have 0 server load footprint. Magento has ajax requests to slow Magento backend :
/customer/section/load/ 740 ms
/welcome/customer/index 250ms
/swatches/ajax/media/ 250 ms
So workload of the ajax request approximately = 1000ms = page load. IT can reduce throughput almost twice. To 30 concurrent pages per second
Checkout pages performance ratio to the catalog pages is 1 / 5 because of heavy not optimized API workload. It is around 10 requests to checkout pages simultaneously.
