Stilnest.de is an online platform for exclusive designer jewelry
stilnest.com is an online platform for exclusive designer jewelry

Magento is not only the most popular eCommerce platform, but among the top 5 content management systems in general. The community edition is available for free (open source). Since the first version of Magento was released in 2008, quite a lot of extensions and plugins have been developed and made available to the community in the Magento Connect platform, and various different themes and templates offer individual look and feels.

However, picking all the bricks from the kit to construct your online shop can easily result in a website that offers a lot of functionality and looks quite cool, but actually performs very poorly. Slow response times and bad user experience only increase your bounce rates rather than the conversion rate.

Stilnest.com, a German startup for designer jewelry, was in exactly that situation last December. Let me tell you what we did to solve that problem, identify and eliminate performance hotspots, improve user experience, and increase conversion rates.

Bad performance and first reactions

After Stilnest first noticed that they had very slow response times, their initial reaction was to do what many others would: scale up their cloud infrastructure by starting more instances in Amazon EC2. Another plan was to use CDNs to reduce the load on the webserver. But before they did, they called me and asked for advice.

Identify the real performance hotspot

The first thing we did was to install Dynatrace Free Trial. Providing full functionality and a 30 days free license this was the perfect tool to start with. After placing agents in the webserver and PHP engine, it was just a matter of minutes to see the first mind-shifting results: the problem was not an overloaded server, PHP engine or database, the main issues were actually in the code.

Using 3rd party modules

One thing I usually start with when analyzing application performance is to look into the performance hotspots. Response time contribution is shown by tier. We saw that by far the most time is spent in PHP:

PHP execution presented a major global bottleneck for the page load times!
PHP execution presented a major global bottleneck for the page load times!

Doing a further drilldown to identify the responsible PHP classes and methods pointed out that the LESSC library consumed most of the time. LESSC is a precompiler for stylesheets (CSS), that was part of the used theme:

method-by-cputime

The PurePath showed that this execution was part of every single transaction
The PurePath showed that this execution was part of every single transaction

Not only is LESSC slow, it should not be part of the production environment at all! It was actually meant to be used to precompile the stylesheets on the server, but not as part of the transaction. The web request should just use the final CSS. Having this important insight they changed the settings and were able to reduce the response time by more than 2 seconds!!!

Unexpected behavior of 3rd party modules

The transaction flow is a graphical output of the captured transactions that shows the flow through the entire system, from the user action in the browser to the webserver, the PHP engine, down to the database, or even external services.

Stilnest used a module to allow user authentication via external services. In their configuration they enabled Facebook, but disabled other options. However, the transaction flow showed outgoing web requests to other services like Yahoo, Google or Twitter. This was definitely a bug in their use module and had to be fixed.

Server-side calls to external services that were not used at all
Server-side calls to external services that were not used at all

Implementing new features breaks performance

Product listing with available stock quantity
Product listing with available stock quantity

Early in 2015 Stilnest came up with an improvement for their online shop: the product listings should be enhanced by showing the available stock quantity for each item in the list. After deploying the changes into production they experienced very bad performance values. Using Dynatrace they found out that it was the new module for the stock quantity that was very inefficient.

The solution was to create a batch job to calculate the available quantities and store the results in a server side cache.

The long term consequence is to create an awareness for performance among both developers and testers. By using application performance monitoring along the entire development lifecycle such issues can be avoided from the beginning, or at least identified during testing.

Status Quo

The result of the findings were successfully implemented in Stilnest’s Magento platform, and the result was quite satisfying: higher conversion rates, lower bounce rates, better performance, better user experience.

conversionrate-responsetime

Outlook, next steps

After these first steps that already generated a massive performance boost, there are further plans on the roadmap:

  • Auto-Scaling the infrastructure in EC2 by using performance metrics captured with Dynatrace
  • Using Nginx as Reverse Proxy and Load Balancer
  • Integration and correlation of performance metrics in business monitoring dashboards

Watch out for upcoming blogs in this series, where I will provide you with further details about we realized these next steps.