RSS

8 Ways to Troubleshoot Web Application Performance

iStock_000007512157Small

Time after time, we hear about web applications that go down because of too much traffic. Sometimes these are high profile sites like Twitter but most frequently, it happens with smaller start-up services that never anticipated the traffic they have received.

I will give you some tips about how you can troubleshoot and enhance web application performance without necessarily being a techie or having millions of dollar in venture capital to scale your web application.

1. Don’t Do The Same Job Twice

This seems obvious but it is surprising how many use processing resources to do the same job several times. Doing the same job twice is often a result of laziness in application design or a way to try to reduce complexity.Doing the same job multiple times often happens when you repeat the same dynamic operation many times.

Example: If you are dynamically resizing an image on-the-fly you should cache the resized image so the second time the image is requested, it is simply loaded from cache rather than using CPU power to resize it from the original again.

2. Work In Batches And Use Queues

The single most common reason that web applications completely fail under much traffic is that they get clogged with the jobs they have to handle. A system that runs effortless with 4 concurrent jobs to handle can completely crash with 5 concurrent jobs to handle.
Example: We often see this type of problems in registration forms that require server side work. If it’s not strictly necessary with instant feedback to the user about the result you can simply capture the data into a queue and use a scheduled job to process a segment of the queue.

Symptom: The web application crashes with too little memory when you receive more than usual tasks to process.

Solution: Figure out what’s the maximum amount of concurrent tasks that your web application can handle and create a system to capture tasks without processing them.

3. Databases: faster to read than to write

Databases behave just like regular books; they are faster to read than to write. Many types of databases can also just handle one writing process at a time so if several processes want to write to the same database they have to wait in queue.

Symptom: The web application is responding slowly and the CPU and memory usage on the server is high when you have more than one concurrent user.

Solution: You should always try to reduce the number of writing commands to the database. If you are handling temporary data they can be stored in memory rather than in the database. Take a look at all operations that trigger an insert or update of your database to see if you have any unnecessary transactions in your workflow.

4. Eliminate DNS Lookups

DNS is a type of phone book for internet that holds all information about domain name and translates it into IP addresses. In the same way as you look up domain names you can also lookup IP addresses and get them translated into domain names.

Symptom: The browser is hanging for a very long time with the status message “Connecting to…” before the page is suddenly loaded as quickly as normal

Solution: It is always a good practice to eliminate reverse DNS lookups completely. Revers DNS lookup both create a point of failure and slow down the web application if the DNS server is responding slowly or is unavailable.

If you use DNS lookup for internal systems like database servers, it is more effective to hard code the IP address to the hostname in the host file of your operative system.

5. Compress Data Before Transfer

You are probably familiar with file compression like ZIP or RAR files. What most people don’t know is that modern web browsers have a compression functionality built into it allowing your server to send compressed HTTP data to the client. For regular text content like HTML, CSS and JavaScript, this compression technique can reduce your data transfer with as much as 90%.

Although compression and decompression slightly increases the CPU usage on both the client and the web application server, it’s still much faster than to transfer an excessive data volume over internet.

Symptom: Your data transfer bill is quickly increasing and your users experience a slightly slow load time.

Solution: Enable compression of HTTP data before transfer on server side.

6. Force Client to Cache Data

This is the most under-utilized performance parameter in web applications. Many developers believe that since a web application is a dynamic application, we cannot let the user cache information in their client.

I believe that this conclusion is completely wrong; you have a lot of elements that the user should cache forever and never revalidate. This includes all design and layout items. In cases where you need to update css or javascript files, you simply give the file a new name.

All modern browsers have limits for how many connections they can establish to the same server, for example Firefox only accepts 4 concurrent connections to the same hostname.

This means all type of content: images, css, html, etc. If you have six images on a page, the browser will download the first four and wait with the last two until the two images from the first batch are completely downloaded.

To learn more about client cache of data I recommend you to read Caching Tutorial for Web Authors and Webmasters

7. Move the Data Closer To The User

If you have already enabled the best possible strategy on caching of data on clients but the page still seems slow due to many dynamic components that cannot be cached, you will have to move the data closer to the user.

The most efficient way to move data closer to the user is to use Content Distribution Networks. There are a lot of options for these type of CDN services and you will have to research who best covers the area were your user base is located.

For most web applications, it is a relatively easy job to implement a CDN service. However, you need to be aware that the data transfer cost from a CDN service will usually be significantly higher than from a regular hosting provider.

8. Revers Proxy

In reality, many web application owners do not have full control over the code that is implemented. It can be that the developer is no longer available or that you simply bought a of the shelve solution. That’s when a revers proxy can be implemented.
A revers proxy has two use cases in a modern web application. It will work as a transparent caching engine for your web application that will effectively eliminate for the same job to be done twice.

The other use case is for situations where your site experiences an extreme data throughput (more than 100 Mbit/s) where properly designed revers proxy servers can deliver a much higher throughput for cached data than most traditional web servers.

Warning: Installing and configuring a reverse proxy requires a good knowledge about the web application logic; not all content can be cached and the result of miss configured revers proxy services can be catastrophic.

Conclusion

If you are a non-technical entrepreneur, it can often be difficult to determine if you have the right person to look at your performance issue. In the ideal world, you should not let your web application performance troubleshooting relay on your developers.

Developers are great people and they know your solution the best, but most web developers have never been trained or actively worked with infrastructure matters. The infrastructure design and relation between the server and the client will significantly affect the overall performance of your web application. Good developers are always functionality driven and focus on creating high quality code; ironically, this might sometimes be the source of your performance issues.

Other resources regarding this topic includes:

Please use the comment form below to bring your insights about how you troubleshoot web application performance or ask me questions about the challenges that you are facing.

Showing (0) comments | Add one


Leave a comment

 Top