Medusa Cache benchmarks: 2.2x faster APIs

Today, we are excited to launch Medusa Cache. Over the past several months, we have focused on improving the performance of our Commerce Modules, Framework, and Medusa Cloud. Our goal was simple: build the world’s fastest commerce platform. Medusa Cache is a critical step in achieving this goal, and we are now making it available to all applications deployed on Medusa Cloud at no additional cost.

Read the full product announcement and the technical deep dive.

As part of launching Medusa Cache, we’re sharing the results of our latest performance benchmarks, which show an average 2.2x improvement compared to previous versions. In this post, we break down the full results across three Medusa versions:

• v2.10.1 - the version before kicking off dedicated efforts around improving performance
• v2.11.0 - the latest version that includes improvements to the framework and modules
• v2.11.0 + Medusa Cache enabled

Methodology

In our tests, we simulated the traffic and setup of a mid-sized DTC business. Every benchmark was run under the following conditions:

Store

We created a Medusa application and seeded it with 500 products, each with 4-20 product variants (approx. 6,000), and each variant had 4 prices (approx. 24,000). Medusa managed inventory for all product variants. The carts were created in one of four regions, with some having tax collection enabled.

Load-testing setup

We used K6 to conduct our benchmarks. The test was configured to run with 420 VUs for 10 minutes, with a ramp-up and ramp-down time of 2 minutes, meaning a consistent load for 6 minutes.

We ran six different scenarios in the test:

You can find the K6 load test in our open-source repository.

Infrastructure

We ran our load tests against an application deployed to Medusa Cloud. Our compute platform is powered by Kubernetes and comes with built-in auto-scaling. Applications automatically scale to meet demand by provisioning new pods when certain request or CPU usage thresholds are reached. Each pod is allocated 1 vCPU and 2GB RAM, which is the configuration we have found to be optimal for Medusa workloads.

Applications on Medusa Cloud rely on a third-party Postgres database provider, which also has auto-scaling built in. The database was configured with a minimum of 1 vCPU and 4GB RAM and a maximum of 4 vCPU and 16GB RAM. In addition to Postgres, applications connect to a third-party Redis provider, underpinning our events system and now also caching layer.

Benchmarks

In these benchmarks, we measured the overall response time of the scenarios (which involves multiple HTTP requests), and, by extension, the response time of the individual requests. The following graphics show the results of our three benchmarks.

Version 2.10.1

The first graphic shows a performance overview of version 2.10.1. The p95 latency was 680 ms, with 88,999 requests made at an average of 140 RPS and a peak of 190 RPS.

Version 2.11.0

The second graphic shows a performance overview of version 2.11.0. The releases between 2.10.1 and 2.11.0 included several performance optimizations across internal tooling and commerce modules. The p95 latency improved to 496 ms, with 90,645 requests made at an average of 142 RPS and a peak of 195 RPS; a 27% improvement in p95 compared to 2.10.1.

Version 2.11.0 + Medusa Cache

The third graphic shows a performance overview of version 2.11.0 with Medusa The third graphic shows a performance overview of version 2.11.0 with Medusa Cache enabled. In addition to the core performance improvements, the application tested here leveraged the new caching layer built into Medusa Cloud. The p95 latency dropped to 309 ms, with 92,855 requests at an average of 145 RPS and a peak of 200 RPS. This represents a ~55% improvement in p95 compared to 2.10.1 and a ~38% improvement compared to 2.11.0 without cache, along with increased throughput as reflected in the higher average and peak RPS.

Conclusion

Our benchmarks show significant performance improvements across all APIs from version 2.10.4 to 2.11.0, and even better with Medusa Cache enabled.

The graphic below shows p95 across all endpoints used in the load tests:

To summarise, upgrading to the latest version of Medusa and enabling Medusa Cache cuts response times by over 55% on average, making it a clear step forward in performance and scalability.

Road ahead

While we have had an intensified focus on improving performance over the last several months, this effort will remain a continuous and high priority for our engineering teams.

You can follow for more updates in our changelog.

If you have questions or comments about the benchmarks, reach out on Discord or create a Discussion on GitHub.