Web application performance tuning

It is simple, but takes time

There are three basic ingredients of successful scaling of web application: analysis, clear action plan according to data from the analysis, execution of the action plan according to action plan and not deviating from it. Then the loop starts again.

Before we will dig deeper in those three phases - we have to make some important points:

It is ongoing periodic work, not one time fix every change must be measured and its impact documented for the future it is not about Linux performance tuning (or FreeBSD, windows - any operating system), apache, mysql or other software components of the application - the main thing on which you will concentrate most efforts is your website.

Analyzing the enemy – approaching the battleground

This is starting point and it is very important one – you always need to analyze your systems to know what is going on and why. Like spies before entering foreign country, you must analyze what resources do you have, how they are used, what are main bottlenecks, is it specific to your application or is it well known limitation with software tools you are using. It is so important - that we will stress it again - you need to know where you are before you are going somewhere else in the future.

In the first stage of analysis you need to have at least general view of your application components DOCUMENTED - it can be a picture from whiteboard or six hundred specification documents - your call, but it is a must to have. If you currently do not have it – make it, you will find interesting and important things while doing it (for example – that there is no one person, who knows everything). Every time you will want to analyze and improve web application - you will be bringing the document with you and showing it to other people for them to understand, make comments and improve it. In the document you must have information about components used, software, servers, and flows between various parts of application.

The best practice is to start this document when application is being designed and constantly updates if anything changes. Simplicity and clear view is the key here. Schematics with every small detail will provide you too much information. Generally it is suggested to have a diagram in one page, which you could hang on the wall for everyday usage. If you don't have such overview of your web applications - there is no point to read more. You need to make it before reading more.

Still here? Now let's start with real time performance monitoring. In this part you have very clear view on what resources you have and how they are bound together, but you do not have any idea how do they perform and what are important things to consider - you have an understanding about what car you are driving, why wheels are important, but you still don't have dashboard with indicators. From the performance point of view there are three simple groups:

• How is hardware being utilized - maybe some servers are overloaded, but others are doing nothing?
• How fast are components of your application and application itself - what is the status of database, image processing scripts, and page generation times - which are the slowest components?
• How we correlate performance with systems status - here we will combine system resource usage statistics with web site counters - how many users, how many pictures served and other interesting things real time, so we can conclude what is needed to provide service to users.

Steps to be implemented for real time data gathering: