Magento 2 performance cost problem
Tags: magento, php, cloud
Published: 2020-12-31 03:37:36

Magento Cloud services (Magento Cloud, MageMojo, Web-Scale, or self-hosted AWS) can scale automatically and free us from thinking about server limits. However, auto-scaling also changes Magento 2 performance issues from a shameful outage into a co$t problem. This is an improvement, but it means it is easy to make expensive mistakes. Magento 2 has costly bugs more than any other eCommerce platforms (ORO, Shopify, Silius, AeroCommerce, etc.).A hosting bill for the moderate website can be at least tens of thousands of US dollars. In this article, I'll try to explain why auto-scaling makes cost problems easier to introduce and suggest a few things to avoid the problem. 


The most straightforward way to set up a Magento website for the middle merchant with 1 million visitors per month (1300 per minute, 23 per second) is to run it on a fixed amount of resources: 1 EC2 Web server with Graviton 2 CPU, Separate RDS MYSQL/Aurora, Cloud Flare CDN. However, such an environment will work only with a good Magento Open Sour. If you are using Magento Enterprise, B2b, and various extensions, you are killing your site performance. Newer use Magento 2 Enterprise! It has more performance bugs. Use well-tested community-driven Magento Open Source (https://github.com/OpenMage/magento-lts) 

![Magento 2 small cloud cost](https://dev-to-uploads.s3.amazonaws.com/i/0fboxyo191zjcp5pem9j.jpg)
Magento 2 hosting cost if you have a good performance: 637$

In this configuration, when the incoming request rate approaches the system's throughput limit, bad things happen. The time to process a request skyrockets, and if you are really lucky, things start to crash. The server response time (TTFB) increases exponentially, usually due to trying to process too many requests at the same time. If the incoming request rate exceeds the throughput, you have a Magento outage, where the best a system can do is serve a fraction of the requests with pure performance and loose customers, less robust systems will fall over.

Fixed capacity: system explodes when requests exceed the limit. For the cheapest AWS C5.large 2 vCPU server (5$), Magento`s request limit is around 1 user per second...
 
In modern systems, we can use auto-scaling to add resources to the system when it starts getting heavily utilized. The figure below shows a hypothetical system that can detect the increasing load and increase the capacity before it is overloaded.

![Magento Auto Scaling cloud cost](https://dev-to-uploads.s3.amazonaws.com/i/lopxy1bjwmfjf960v3vg.jpg)
Magento 2 Hosting price if you have bad performance: $16,258+ monthly cost. Regular Magento 2 website hosting cost is 25 times expensive than well performant and optimized eCommerce system. And it is just the price of the resources. Hosting solutions like Magento Commerce Cloud will charge 3-6 times more for their services. 

Autoscaling: system adds capacity as requests increase

In general, this is an improvement over a fixed-capacity system since it automatically handles unexpected increases in load. However, the cost of operating the Magento system is much less predictable since it depends on the load. Worse, if you add Magento extensions with performance bugs, good auto-scaling will hide it from you. Almost all extensions have such issues, thanks to the broken Magento 2 ecosystem. The only thing you will notice is your bill goes up a lot. Billing data is typically delayed for a day or even month, so this can at least a few days to notice, at which point you might have wasted a lot of money. Magento performance problems are more obvious in fixed-capacity systems. In really bad cases, you deploy a new version, and your service explodes since it can no longer handle the load. Even a small performance issue is often visible on Magento response time charts. As you deploy a new version, the time to process requests goes up.

Magento 2 server response time increases as a new performance bug is deployed. 

In either case, the change is obvious after you deploy it, so you can investigate if this is expected or if you are accidentally burning money.

With really good auto-scaling, large or small performance changes should be invisible. The system notices that the application is doing more work, so it seamlessly provisions more capacity. In my experience, some real-world cloud services work like this. You can throw 10X more work at the system, the performance stays the same, but your bill goes up.

## Create AWS Magento Cloud with auto-scaling in 5 minutes

{% youtube kmnlrXSTQlM %}

Read more : https://github.com/Genaker/TerraformMagentoCloud