Case study: Brille24

 “Load Impact performed brilliantly in both consulting, service and expertise”



Brille24 used Load Impact to verify that their new E-commerce platform could handle their existing traffic levels. They were able to identify and fix performance-related problems before going live.

About the customer:

Brille24 is Germany’s leading online-optician with customers in more than 115 countries around the world. They offer a wide range of glasses of that can be purchased via their E-commerce website.


Brille24 commonly have more than 2,500 concurrent clients using their online shop. They planned a launch of a new version of the E-commerce platform and this launch collided with a large marketing campaign. To minimize risk of failure they decided to load test the new system before going live.


  • Validate that the new E-commerce platform could handle existing traffic levels, with some margin
  • Detect potential weak points in the system before launch
  • Establish a baseline for further testing

Test set up:

Load Impact assisted in executing the tests during non-business hours so not many customers would be affected. Prerequisite data was collected, scenarios created and two ramp-up tests were performed from one load zone to generate up to 5,000 concurrent users on the site.

Service environment:

  • Apache
  • PHP
  • MySQL
  • Linux

User scenarios:

The users landed on and then proceeded to browse through the (glasses) section, selecting various filtering options. Some users would add products to their shopping cart and others would browse to other parts of the site.

Test execution:

Started configuring the tests and then ran a few smoke tests. Those small scale tests showed that there might be a few issues with the database, therefore we decided to start a scenario running from 100 to 1000 concurrent users. While the test was conducted we monitored the processes, CPU, bandwidth and memory usage of the servers.


  • The first test uncovered issues with the load balancing and the database cluster
  • The issues were addressed and a second test was executed, showing that the system could then handle the target traffic level 


  • Weaknesses were found and fixed, allowing the system to serve its expected 2,500 concurrent users
  • Brille24 could go ahead and launch the new E-commerce platform without risk of losing sales due to poor response times or stress-related failures

At 100 clients the user load time was 7,4 seconds, 325 clients = 29,5 seconds, 550 clients = 58 seconds, 775 clients = 93 seconds, 1000 clients = 89 seconds. Note: User load time is an aggregated result metric. It represents how much time it took the simulated users to perform all the HTTP transactions in a user scenario.


The overall performance of the site seems to be subject to some minor but critical flaw(s) in the configuration, code or hardware. The system specified by Brille24 would be able to handle much more traffic than was indicated by the tests. During the two separate ramp-up tests performed during the night, a possible problem relating to the load balancing of the servers was discovered. During the tests, the CPU maxed out on servers 2, 3, 4 and 5 while the activity on server 1 was virtually nonexistent. Server 6 also showed low activity but as it is the asset server serving the site with static data this should be seen as normal. * Weaknesses were found and fixed, allowing the system to serve its expected 2,500 concurrent users * Brille24 could go ahead and launch the new E-commerce platform without risk of losing sales due to poor response times or stress-related failures 


Run a number of smaller tests on specific functions to root out the performance issue followed by optimization of the found function. When this is done, do another large scale ramp-up test. Brille24 has a total of 61 HTTP requests on the main page and a total weight of 947.7K bytes with empty cache, distributed as follows:

The web metrics standard is 42,14 giving us a delta of 18,86. By minifying and combining the Javascript files and CSS files on the page it's possible to get down to 42 requests. And if some of the CSS images are combined into sprites the amount of requests can be lowered even further. 

Network size/KB
Average size transferred over the network per page, including HTTP headers for is 955,3KB - which should be slimmed down if possible. The benchmark value according to the web metrics scale is 312,04KB. 

Average image network size
The average network size of the images per page is 665KB, this should, if possible, be lowered to around 200kb. This might be a bit ambitious but running a quick image reduction algorithm on the site it was found that 114,52KB could be removed from the 665KB - leaving a much more pleasing 550,48KB average per page. 

Browsing products
A new database query is performed each time a filter is selected. Change this to sort the data that is already available. 

Add expiration headers to files
A first-time visit to a page may require several HTTP requests to load all the components. By using Expires headers these components become cacheable, which avoids unnecessary HTTP requests on subsequent page views. Expires headers are most often associated with images, but they can and should be used on all page components including scripts, style sheets, and Flash. 

Add gzip Compression
Compression reduces response times by reducing the size of the HTTP response. Gzip is the most popular and effective compression method currently available and generally reduces the response size by about 70%. Approximately 90% of today's Internet traffic travels through browsers that claim to support gzip. 

Move all JavaScript down
JavaScript scripts block parallel downloads; that is, when a script is downloading, the browser will not start any other downloads. To help the page load faster, move scripts to the bottom of the page if they are deferrable.

Feedback and Knowledge Base