Web Application Performance Introduction
In this short article, we explain the meaning of web application performance, how it’s measured and what can be done to optimize your application’s performance. Some of the general rules discussed here can also be applied to other system architectures.
What is Web Application Performance?
If you browse the Internet you may encounter the statement from content delivery leader Akamai Technologies that every 1-second delay in webpage loading means a 7% loss in customer conversions. This is a big number and implies it’s very important for IT managers to pay attention to the performance of the systems their online stores and other web apps run on.
But what exactly is application performance? We can think of system performance to consist of two important elements:
- system responsiveness (aka. system performance in common technical terminology) - the ability of the system to respond to user actions in a timely fashion under normal conditions, in other words: do end users perceive the system as being “fast”?
- system resilience (aka. system scalability in common technical terminology) - the ability of the system to remain responsive under trying conditions, In other words: do users perceive all components of the system to be acceptably responsive both during peak traffic hours as well as in the face of unexpected events?
These are two distinctly different challenges and different approaches and tools should be used to test and optimize to reach the desired levels of performance and scalability. However, from a non-technical point of view, we combine them both and treat as two different aspects of system performance in general.
How to Measure Performance
If your system is already up and running and “in production”, then measuring application responsiveness is pretty straightforward. To run a quick test, do as follows: at a time of the workday when you believe an average number of customers will be visiting your site, use the Developer Tools in Google Chrome to adjust the network speed to a level which approximates the one used by customers and enter your application webpage address. Then simply use the application for a while. That is, do what a typical customer would do and come away with an impression. Is the system responding really nicely? If so, then performance is probably OK. But if you have to wait a while to get basic things done - then you’ll probably need to optimize things. By the way, when doing your test, you should definitely also do it from a mobile device. Why? Because studies have shown that nowadays smartphones and tablets generate the majority of internet traffic.
The formal goal of the above test is to check if your site’s most popular pages feature a TTI (Time-To-Interactive) below 2 seconds. You can measure this using Chrome or even just relying on your own subjective impression.
If you want to check the resilience of your system, you should repeat the above test during peak hours, that is when you expect the number of customers using your site to be close to its maximum. Then compare the times from both tests. If the increase in Time-To-Interactive is linearly proportional to the increase in customers, then it indicates the system performs pretty well. However, if Time-To-Interactive on any page exceeds 2 seconds, you may want to scale up or optimize the system.
At 3 P.M. on weekdays during the winter season a retailer that sells ski equipment usually sees about 25 concurrent users in their online shop. At this traffic level, the retailer’s IT manager knows it should take around 0.5 seconds for the application home screen to become interactive.- well below the “2-second rule”. A couple of weeks before the holidays, however, the manager decides to run a performance test and learns the number of concurrent users on the system at 3 P.M. is now at 50 whereas the time needed to display the home screen has gone up to 1.5 seconds. And although 1.5 seconds is still an acceptable TTI, the IT specialist realizes the time increase wasn’t linear (50/25 = 2 times more customers whereas the time change was 1.5/0.5 = 3 times higher). Further analysis of the data suggests they’ll definitely have a performance problem (TTI over 2 seconds) should traffic levels exceed 65 concurrent customers- something the IT manager knew could readily happen during the last days before the holidays.
As the above example illustrates, it is pretty straightforward to do basic performance testing on an existing system. However, when your system is under development and not yet live, it’s not possible to measure performance without first generating artificial traffic characteristic of what’s expected to happen when real customers are putting the system through its paces. Doing this will be difficult for companies which don’t have in-house IT specialists with the appropriate skills and tools. In such cases, we recommend arranging an application performance audit from an external company with the type of expert resources necessary, such as e-point.
If you do decide to use internal resources to test a system under development, keep in mind that “homemade” performance measurements should only be considered approximations which won’t take into account all potential technical aspects. So the results may be misleading or even incorrect. Indeed, industry experience has proven that the only way to have truly reliable information detailing how robust your future production system will be is to do an audit using external application performance professionals.
How to Optimize
In cases where you know you have some performance issues that you want to address yourself, you first have to find the performance bottlenecks. Experience says there can be many different types.
So system optimization begins with an iterative process aimed at identifying and getting rid of all major causes of poor performance. When you find the first one, you take appropriate measures to eliminate it, then retest. Then you pinpoint the next bottleneck, remove it, retest, and so on. For as long as it takes to reach your performance goal.
To provide a general picture of the optimization process, we mention below some common causes of performance bottlenecks and suitable measures to eliminate them.
- If selected system components show high CPU or memory usage, you might consider scaling up vertically (that is, increase the CPU power or amount of memory resources available) or horizontally (increase the number of application nodes and then appropriately distribute traffic among them). You might also consider optimizing the system source code.
- If your System is not overloaded but threads are waiting - check and increase the associated thread pool sizes, the database connection pool sizes, and other limits that are set in your application server.
- If database queries last too long - obtain the appropriate query plans and optimize them using database indexes or, if needed, database denormalization; to do the latter, you may need to move selected data out of relational databases or implement full-text search outside of the database.
- If requests are stuck in communication with external systems - try moving to asynchronous communication, for example using message queues.
- If your frontend is slow due to the system waiting for analytics or other non-critical scripts to load - try moving the scripts to the end of the page so that the page can become interactive before these non-critical scripts are completed.
- If your webpage is slow on mobile devices, consider upgrading it to the Progressive Web Apps (PWA) standard. This will vastly improve the end-user experience. One of the neat performance enhancements that come along with this is that some caching is done on the client side.
For those who found the information on web application performance testing and optimization interesting but lack the internal resources to undertake these programs, e-point can help. As a first step, consider ordering our free Performance Audit Starter Report for your e-commerce site. Just enter your contact information and site URL and we’ll do some initial analysis and let you know how things look.