Diese Seite ist auch auf Deutsch verfügbar. Zur deutschen Seite wechseln

Performance optimisation case study: Bibis Beautypalace online shop

EN_Performance-Optimierung_am_Kundenbeispiel_Bibis_Beautypalace-860x325

It’s nothing new that performance and speed are crucial factors of an online shop. Customers do not have patience when something takes “too long” – they’re more inclined to cancel the order and try their luck at a different provider. Our partner Kellerkinder has a few practical tips so that you can get on the fast track and improve your website speed - and bottom line.

The basics

Performance largely depends on having the right setup. It’s worth asking the following questions in advance:

1. How many users do you calculate per minute?

2. How many orders per minute/ per day are submitted?

3. What do you do when something goes wrong? 

The first two questions are easy to answer if you already have an online store or a website. Otherwise, you have to make an educated guess. Then you can move on to answer the third question.

If you assume less than 1,000 visitors per minute, a single web server is sufficient. 
However, if you have underestimated that number, it is relatively difficult to have a solid back-up plan in place. 
Things are a lot easier in a cluster setup. A cluster consists of several servers that distribute the load. Here, the load balancer forms your front line. It’s the load balancer’s responsibility to distribute the incoming queries to the app servers hosting the actual website.
In this setup, other app servers can be added to absorb a higher load during ongoing operation.

From 0 to 100

Before going all out with a new car, it should first broken in with a few hundred kilometres. At least, that is the recommendation of most manufacturers.
The same thing applies with an online shop: ‘testing’ is key. The performance in your shop needs to be tested using ‘load tests’.
A load test can be performed in a variety of ways. Ultimately, all of the different types simulate multiple users that call up a page simultaneously. 

These tests should not only incorporate the peak values, which are supposed to be above the expected average traffic. A long-term test, preferably over multiple hours, is also highly recommended.
Our partner Kellerkinder had to learn this when late one evening (a couple of hours after www.bilou.de/en went live), two of the four app servers suddenly quit working because the cache was full. Luckily, the problem could be found and resolved quickly by increasing the storage configuration of the cache.

We recommend using JMeter for the load test, because it allows you to simulate a typical customer path through the shop, and Shopware has already prepared a sample path for you.

And the solution is ...

The load test will quickly reveal that the database is usually the cause of reduced performance.

With MySQL databases, the query cache is even deactivated by default (depending on the version). This can be configuredwith “query_cache_type”and “query_cache_size”. In addition, the script mysqltuner (GitHub) also gives you some guidanceon which configurations can be modified.

You can also create a master-slave system in the setup to ensure the entire load does not go to one server. This process poses different challenges you need to address. 
What happens, for example, when several orders (on different servers) are completed exactly at the same time, and then all of them are assigned the same order number? Of course, this probability is very low, but such a situation should not be dismissed. 

Here, the plugin from the Shopware Enterprise Edition ‚SwagEssentials‘ with the NumberRange component can help you. This component centralises and optimises number generation using a Redis server, in order to assure the strict sequence of order numbers. The plugin also offers a few other useful advantages when it comes to performance.

… a plugin!

However, if it is not the database, then it’s got to be the plugin. But which one? Usually, multiple plugins have been installed and deactivating them individually in order to test the behaviour is very time-consuming.

A suspicious plugin can be discovered using PHP profiling, for instance. Tools, such as Blackfire or Tideways, can help you see which PHP functions are being called up and how much time they need while a page is being loaded.

performance_killer

This helps to find performance killers: too many and unnecessary SQL queries, loading unnecessary product information on every page of the shop, or calls attached to global events are only a few examples of what can be discovered in multiple performance analyses.

Seek and you shall find

One essential component in your shop is the search function. Here, no one wants to wait for the search to return results. The worst case that can happen is that the search doesn’t find what the customer is actually searching for.

For a high-performance shop or extensive product catalogues, it is thus advisable to put the search function on another server. The advantage is obvious: it takes the load off the actual database.
Smart Search by Shopware provides many beneficial options and extensions, however, the execution still takes place on the same database. 
Third-party providers, like FACT-Finder and Findologic, are a possible alternative. 
But Kellerkinder found ElasticSearch to be the best choice because of its direct integration into Shopware and the flexibility it offers in terms of configuration. It also can be easily used without high costs.

Cache all things!

Finally, Shopware’s own cache shouldn’t be forgotten. Everything that can be called up via the cache should not have to go through the entire Shopware processing. Shopware’s standard version already offers a HTTP cache.

But if someone wants to take it a step further, the cache can be outsourced, for example, to a Redis server or an upstream Varnish server. The advantage of a Varnish server is that the PHP process does not have to be started for the request and the web server can output the content directly. This results in top-notch speed!

Stay with it

Once all measures have been taken and the shop is finally online, monitor the load. It is not only extremely interesting; it is also important for being able to respond quickly in case of emergency.

To give an example, our partner launched their new online shop, bilou, at the end of 2018. The bilou brand stands for particularly unique, sweet-smelling body care products and was founded by the YouTube star, influencer and blogger Bianca “Bibi” Claßen (BibisBeautyPalace).

In the screenshot, you can see the statistics for the queries on one of four app servers – in other words about ¼ of the actual traffic – at the moment of going live.
After the official Instagram page of bilou posted about the new shop, it took a few minutes before the first traffic started. Then, however, it can be clearly seen that the queries per minute shot up after Bibi announced the launch of the shops in her Instagram Story.

instagram_bilou_traffic

Last but not least

For a successful launch of a high-performance online shop, it is important to create the appropriate server setup right from the start.
With a suitable configuration and sufficient testing, you’ll ultimately be prepared for anything.

About Kellerkinder

100% Shopware in a remote-first company – that’s Kellerkinder. Following its motto, “Quality is the best business plan”, it develops complex and individualised solutions based on Shopware. Further information about the agency can be found here.

 

This might also be interesting:

Case Study bilou
Practical tip: Performance optimisation for online shops (in German)
Fundamentals of conversion optimisation for online shops (in German)