Performance Testing - TTFB (Time to First Byte)

Performance Testing - TTFB, TTLB

When you open any web page, there are series of requests from the client(usually a web browser) and response from the server.

TTFB (Time to First Byte) - Amount of time it took for the client (usually a web browser) to receive the first byte of server response.

TTLB (Time to Last Byte) -  Amount of time it took for the client (usually a web browser) to receive the last byte of server response i.e total time taken to download an object

Both metrics are used in performance testing for analyzing the bottleneck.

I will explain the metrics by taking an example.

Both the requests appear to be hosted on two different servers.
Both the requests tool almost 1 second to complete, but "pic.png" having file size four times grater than the "login.jsp". What is going on? In-order to understand the complete story, we need to know TTFB.

With this additional information, we can understand what is happening.

In case of "login.jsp" after receiving the first byte, it took 09ms to download the remaining content.

Where as "pic.png" received the first byte very quickly but took another 900ms to download the remaining content.

"login.jsp" bottleneck likely to be server side processing, due to heavy CPU usage. This is common for dynamic pages which need to process before sending the response to the client. If the process involve database or other expensive operation, that could be cause of slow performance.
Situation is different for "pic.png", delay is likely due to slow network or poor configuration for the server hosting the image. As the image is not a dynamic content, it will not be consuming more 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) like CDNetworks 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.
Source: browsermob




----