When doing any type of performance testing, whether it be production monitoring, load testing, stress testing, or simple performance tuning, one of the most important data metrics is the Time to First Byte (TTFB). As the name implies, TTFB is the amount of time it took for the client (usually a web browser) to receive the first byte in a given request. While the total time it took to download the object (ie: Time to Last Byte – TTLB) is also important, the TTFB usually tells a more important story, especially when it comes to software layer optimizations.

For example, consider the following two objects downloaded as seen by BrowserMob during a free load test:

Both of these requests took ~1 second to complete, but that’s where the similarities end. The JPEG is four times larger in file size than the index.jsp request. They also appear to be hosted by entirely different web servers (example.com vs your-ad-partner.com). What’s going on here?

Well, without knowing the TTFB it’s difficult to say. It could be that the web server and network connection hosting the JPEG is simply four times slower than example.com. But suppose we also knew the TTFB for each of these requests:

With this additional information, it’s much more obvious what is happening. Now we can see that in the case of index.jsp, once the first byte was received it only took an additional 10ms to get the remaining content. This is very different from some_ad.jpeg, which received the first byte fairly quickly but then took another ~950ms to to finish downloading.

What this tell us is that the bottleneck for index.jsp is likely due to some server-side processing, possibly tied up by heavy CPU usage. This is very common with requests for dynamic pages (eg: extensions with .jsp, .aspx, .php, etc). That’s because dynamic pages often will not begin sending back the any content until the internal page has completed processing. If the page needs to connect to a database or do another “expensive” operation, that could be the cause of the slow performance.

In the case of some_ad.jpeg, the situation is entirely different. The different between the TTFB and the TTLB is fairly large, meaning that the overhead is likely just a network delay caused by some slow performing connection somewhere between the client and your-ad-partner.com. It could also be due to a poor configuration of the web server hosting the image, but it definitely is not due to any dynamic content that might be taking up large amounts of CPU.

So how do you resolve these different situations?

In the case of objects with long TTFB times, like index.jsp, the solution often requires a software-level optimization. It could involve adding a database index, introducing some object-level caching, or a configuration change (such as database connection pooling). Be careful to fall in to the trap of throwing more hardware at the problem to solve these types of issues. While it might work in the short term, these issues almost always are due to sub-optimal software and throwing extra hardware at the problem will be like putting a band-aid on a bullet hole.

In the case of objects with relatively short TTFB times but overall long TTLB times, the solution is usually very different. While there may be a software solution, such as configuring Apache’s connections to be better optimized for the server it runs on, most of the time the root cause is due to network/hardware-related issues. Check with the ISP that hosts the server to confirm the max bandwidth throughput allowed. If the object response is slow during peak times but fast during off-peak times, it may need extra web servers (ie: hardware).

Alternatively, you might want to look at a Content Delivery Network (CDN) to help host the objects in a physically closer location. For a low-cost CDN, check out Amazon’s CloudFront service, which can let you host images and other static objects in nine separate locations around the world. This is a great, low-cost solution for people who want to serve static content to many different geographies but don’t have the budget or desire to open mutliple data centers.

Tweet This Post 

No tags