Improving Adobe Commerce Scalability with Edge Delivery Services Storefront

For merchants selling high-demand, limited-inventory products online, scalability of the commerce platform is critical to ensure a seamless user experience. In the past I shared observations from one of our clients demonstrating how, when live systems such as payment processors and customizations are involved, lab-based benchmarks can vary drastically from real-world production performance. We’ve recently migrated that same project from a monolithic Luma frontend to Adobe Commerce Storefront, based on edge delivery services and have observed significant positive scalability benefits for the Commerce backend. In this article, I’ll share some further observations.

Overall Backend Response Time Decreased Drastically

The graph below from New Relic shows the server response time for the PHP powered Commerce backend. The more than 50% decrease in response time starting on March 9^th, when we cutover to the EDS frontend is remarkable.

With the new architecture, the Commerce backend is now primarily (but not entirely) responsible for handling shopping-related Graphql requests. Product lookup operations are off-loaded to Catalog Services and rendering is handled on the client browser. This shift in responsibilities frees up valuable resources for the Commerce backend to focus on core responsibilities.

Significantly Less Tax on CPU Resources

CPU resources have historically been the primary bottleneck when the site came under high load, so any reduction in this area is particularly beneficial. As the backend PHP transactions were now responding much more quickly, it would make sense that the CPU usage would also decrease, which can be seen in the screenshot below.

What This Means

All this adds up to net positives for our client and their customers. As user behavior puts less strain on the Commerce backend more customers are able to browse the catalog and make purchases.