Hello, everybody, and thank you for joining us today. My name is Miguel Balparda and for the last decade I work at each of the largest ecommerce implementations around the globe. Since joining Nexcess, one of the largest e-commerce cloud providers, I’ll help with maintaining contributed to the different open source projects, including Magento 2 and Shopware 6 and several open source initiatives.
Chances are we met somewhere because I love to travel in the last seven or eight years, I have presented different talks in more than 40 countries, mostly on performance, support and open-source software.
During this session, I’ll be talking about one of the things I like the most – performance and clouds. I’m going to start by going over Shopware 6 system requirements. Shopware 6 uses a quite common LAMP stack, in our particular case, MariaDB 10.4 activity engine. Now, one can use Redis branch and ElasticSearch to improve certain parts of the application. For this session, I compiled this bit of test to try to benchmark Shopware 6 to see how it behaves under heavy load. I define a reproducible user flow with a certain number of virtual users visiting the site with a normalized distribution I will compare it to one of the platforms I use the most – Magento 2. We tweaked applications as much as possible to get better performance and that includes using Redis for HTTP cache, Varnish for full page cache, and Elastic Search for catalog search and some MySQL fine-tuning we have for every service.
What is capacity testing?
Now let’s start from the basics. What is capacity testing and why it’s important? Quite frequently merchants and store owners want to know how a store will behave under heavy load. When a bunch of concurrent users are hitting their sites and concurrent requests are being made. Capacity testing is the process we have to answer this question. This is also known as load testing, but in my opinion, capacity testing is a better term to use. By having this information, merchants can plan ahead, and outsiders claim their infrastructure using particularly busy times, including a TV show, appearance and marketing campaigns. In my opinion as a tech user, that user every store should have this information beforehand instead of waiting for their servers to go out in the middle of the campaign. That is one of the main reasons we have been proactively offering this service to some of our larger customers of Nexcess.
So let’s get to it. For these tests, I used K6 one of the leading tools for loading and capacity testing, and I tried to replicate a user journey to have realistic and reproducible metrics. I used the sample data package to emulate a real store and while the Shopware sample data is not as big as Magento’s sample data in my opinion, it was sufficient to test the simple and configurable product, category page, search, and checkout. These are journeys started with a request to the homepage, followed by a visit to a category page. And once that category was loaded, the virtual users headed to a simple product and then added it to cart. When the add to cart was ready, the virtual users search for a configurable product and visit the product page, and added it to cart again.
Shopware 6 Results
With these two products added to the cart the last request was made for the checkout page. We started this test with 20 virtual users simultaneously and ramp it up to 50 virtual users in six minutes. This is how the Shopware 6 results look like. You can see the max throughput was 34 requests. And second, we saw a bunch of HTTP failures and I think this is mostly around the add to cart action. The average response time for Shopware was less than 200 milliseconds, and the 95 percent response time was less than 400 milliseconds. Now you can see in the performance overview, we did around 6000 requests, and the server performance wasn’t much ever degraded. Now you can see, we didn’t see any spikes in the response times, meaning the server was performing quite well under heavy load.
Magento 2 Results
This is how the same test looks for Magento 2. Again, we use the same server, sample data, and the same user journey. The max throughput was around 19 requests, we saw no HTTP failures. The average response time was around 364 milliseconds. At the 95 percent, the response time was around one second. Again, you don’t see any spike in the response time in the performance chart. The request we made with around 4,000. And, at no point, this server was under heavy load. But you can see the response time remained pretty much the same, both for Magento 2 and Shopware. And that usually means that this server can take so much volume.
Now, some of our key findings were that the average Shopware 6 response time was 50% faster. The Shopware 6 max throughput was also 50 percent higher. The 95 percent response time for Shopware 6 was around one-third of Magento 2 here’s where we saw the biggest difference. For Shopware 6, we saw around 10% of HTTP failures, mostly around the add to cart action. Now, in my opinion, these tests are telling us that Shopware 6 can behave or perform better than Magento in certain use cases.
And in my opinion, again, there’s a lot of space for Shopware 6 in the small-medium segment for the ecommerce landscape. After the Shopware Community Day, a couple of weeks ago, I saw a lot of people merchants asking us about Shopware, and I strongly believe Shopware 6 can be a great alternative for a lot of use cases when it comes to small and medium businesses. Magento 2 still shines when it comes to enterprise builds, but I strongly believe Shopware 6 can be a great option for a lot of merchants out there, who doesn’t want to go to a hosted solution or still want to host their own stuff.
Now, this is all I have for this session, and I hope you enjoy it. And I think you know where to find me. You can find me on Twitter or LinkedIn if you have any questions or feedback. And again, thank you for having me today here.