• title QA & Testing

    Improving the Performance of a Website

    banner svg

    Before making a large Drupal site go live, we have to check how it’s going to perform in the real world. How long will the pages take to load? How many concurrent users can it handle? Will it crash if there is a sudden surge of traffic? And so on.

    Step 1: Caching Improvements and Optimizations

    We conduct tests on the website pages to find out the load times. This usually shows up that different pages have different load times. And more often than not, most pages will have a load time that is more than what is acceptable.

    The first step is to implement Drupal page caching, so that when a request to load a page comes, it happens off the cache rather than from the database. This brings in improvements. We re-check the page load times and document the improvements seen.

    The next step is to identify the elements that could be slowing down page load. These could be images, or JavaScripts running on them. We take a two-step approach for this. First we take off the images and measure the load times. Then we measure the load times with only the text and images, without the JavaScript. These throw up the pages that need optimizations of images and JavaScript.


    Step 2: Performance Measures

    Our next step is to look at other ways to optimize the website. This involves Views Caching and how Views can be optimized. We ensure that the site implements the recommended best practices for websites in its domain.

    • Page Caching

    • Aggregation of CSS and JS files

    • Implementation of CDN for external files

    • Views Content Caching 

    • Views optimization by looking at queries.

    Step 3: Load Tests

    Once we know the website is well optimized, we run tests to see the performance of the website.


    Stage 1: Testing from one server

    We use the Apache JMeter application, which is designed to load test functional behavior and measure performance. We create a replica of the website we have built, on the same server. Now we install JMeter on another server. We define the parameters with which JMeter will hit the website. For example we can define JMeter to emulate 10 users to access a page on the website initially,  and then in intervals of 2 seconds, 10 new users have to be accessing the website for 12 seconds. This tests the durability of the application and the load it can withstand.

    JMeter gives reports on the page rendering time, error percentages, throughput, and other parameters.

    Along with JMeter, we also run the application monitoring tool New Relic APM which tracks a user’s experience on the browser and gives a visual representation of it. It measures the performance of database queries, and displays the distribution of response times for all transactions. New Relic helps us identify bottlenecks in the application.

    Stage 2: Testing from the cloud

    After we have fixed the issues that the load test throws up, the website is put through a similar test, but this time from the cloud. We use BlazeMeter for this, and we can scale up the loads to a large number of concurrent users. Again we set parameters for BlazeMeter to simulate users accessing the webpages, with New Relic doing the application monitoring as the tests happen. With this combination of tools, we can monitor how the website behave in various types of load conditions, and make it more resilient.

    These very same tests, along with a host of others, are carried out when we do performance and security audits for existing Drupal sites, to identify issues and recommend solutions.