logo level
SME
Agency
Large enterprise
contactOperationalControl Panel
newswebsite-performance

Website performance

In the tenth episode of Hotline27, Roald tells you more about the performance of your website. For many retailers, their webshop is their only source of income, so it is very important that it is fast and stays up and running.

General15/04/2021
Website performance image

A SLOW WEBSITE, WHAT CAN I DO ABOUT IT?

There are several reasons why a website may be slow. The most obvious cause of a slow website is insufficient resources. There is no point in optimising your application if your underlying infrastructure cannot support it.

Another possible cause of a slow website is, for example, a slow SQL query. This query is executed frequently and causes the system to become unstable. You can solve this very simply by buying faster servers with more storage or memory. But of course, this means that your servers also become more expensive, which makes this not the ideal solution for a smaller application.

It is important here not to immediately place the blame for your performance on the application itself, but as a hosting partner we take our responsibility to also look for underlying problems, such as insufficient memory, insufficient CPU, or too few disk IOPS (input/output operations). When these three issues come together, it becomes difficult to determine exactly where the problem is coming from, and in that case it is useful to collect statistics: what are your server’s resources being used for?

LOOKING FOR THE CAUSE OF A SLOW WEBSITE

But how do you start with those statistics? There are a number of tools and methods for that.

Prometheus-exporter

Met Prometheus-exporter kan je pure performantiestatistieken verzamelen zoals CPU, memory en queries. Bijkomend kan je data met betrekking tot queries opvragen: hoeveel queries lopen er, hoe lang duren die, ... Deze data kan je vervolgens in Grafana weergeven in de vorm van een dashboard. Op die manier zie je in het dashboard bijvoorbeeld dat er op een bepaald moment een piek heeft plaatsgevonden en de achterliggende oorzaak duidelijk wordt aangegeven.

Experience & Tools

How do you keep an overview of what the ideal setup is for each environment when you're managing many servers? Well, that’s primarily a matter of experience. In addition, it’s important to investigate the impact on your application when changes have been made to your setup.

But when you can no longer see the forest for the trees, there are tools to help you with this setup. One example is MySQL Optimizer. MySQL Optimizer is a small script that tells you which adjustments you can make to improve your setup. Super handy, right?

Another working method is slow logging. This is a configuration you can easily set up since it’s built into MySQL or PHP by default. With slow logging, you can investigate which PHP traces or MySQL queries are running slowly on your application. This method allows you to filter out the slow processes and optimise them. Unfortunately, the number of log files can become very large. Analysing the logs can point you in the right direction, but won’t fully reveal the root cause of the problem.

NewRelic

NewRelic can provide an answer to what we’re missing with slow logging. NewRelic is a software tool that performs an extensive analysis of what’s happening on your server and displays it neatly in a dashboard. For example, you can see that a user performs a transaction on the homepage of a website and had to wait 20 seconds. NewRelic then shows you which queries are linked to this or reveals, for instance, that there was a delay due to an external API call, and so on. This gives you immediate insight into the cause of your poor performance.

WHEN IS THE APPLICATION TO BLAME?

How do you know something is wrong and that it could be affecting your website's performance? A performance issue can be clearly noticeable from the start, but it can also gradually increase. That’s when it becomes very useful to keep track of load statistics so you can monitor changes. This way, you can see that the server is building up load even though there’s no effect on your application yet, and you can optimise to avoid problems.

Load Testing

To prevent high load from actually causing performance issues, load testing (or stress testing) is very useful. Once the load test is set up, you can theoretically run it after every change to check whether the change has impacted your performance. You can also automate this load testing process.

The most basic software for load testing is AB (Apache Benchmark), which you run from a local PC. Another example is loader.io, which takes it a step further: a number of systems are set up in AWS from which requests are sent to better simulate real-world conditions. One step beyond that is BlazeMeter, which allows you to replicate full flows: a user logging in, ordering an item, adding it to the cart, and completing the checkout process. The implementation takes more work, of course, but it’s the most optimal way to test your application.

THE SOLUTION: CACHING?

If you can’t solve the problem structurally, caching is often a solution. Caching can in some ways be seen as masking the problem. But it’s a logical step if, for example, you want to run a query that consumes a lot of resources, because caching helps free up some of those resources again.

Caching can happen at different levels, but the most performant way is in memory. This can be done in two ways: object caching and page caching.

Examples of object caching are Memcached or Redis, both of which are ‘key value stores’ where you store the results of your database queries so that the next user doesn’t need to execute the same query, but can retrieve the result directly from memory. This is fairly simple to integrate because Memcached or Redis integrations are often already built into your website’s CMS.

With page caching, entire pages are stored in memory. The most well-known service for this is Varnish. So how does Varnish work? Each user navigates to a specific page, and Varnish then checks which URL it is, which cookies are sent, which headers are included, etc. The page is then stored with these parameters. If a new user with the same parameters visits the website, the page is served from memory. This is the most performant way of working, but unfortunately also the most complex to integrate.

HOW CAN I SAVE EVEN MORE RESOURCES?

If you analyse your website’s logs, you’ll notice that many unwanted bots also land on your site and of course consume resources as well. That’s why it’s important and useful to protect your website with a web application firewall so that this type of bot is completely blocked from the server.

Conclusion on performance issues

Don’t just throw more resources at the problem, investigate where the issue really lies. You can solve a problem the quick way or the right way. In short, tackle the problems where they actually occur!

Stay informed

Subscribe to our newsletter and receive the latest updates on our products and services.

By subscribing, you agree to our privacy policy