New feature: detailed response time

This blog post has moved to Bits Per Second, our new blog.

Last week, we introduced a popular new feature in HowFast called “split time”. You can now see the detail of your backend response time, with the portion of time spent in DNS resolution, TCP connection, TLS handshake, request send, waiting for the first byte of data from your server, response download, and optionally time spent following redirects.

Twitter response’s split time: we can see that Twitter’s backend take a constant time to respond (“wait”), but DNS queries are doubling the total response time every now and then. Increasing the DNS records TTL can reduce the frequency of these peaks — their current TTL is 30min.

This split time is available for the last 60 minutes (with a probe every minute) to see the recent evolution, and also over the last 7 days to see the averaged evolution.

It is now very easy to just focus on the backend response time (“wait”) and measure the performance impact of your last commit.

Let’s see how each portion of the response time is measured:

DNS resolution time

This is the time spent resolving the domain name of your URL. Long story short, the goal is to transform www.your-awesome-website.io into the IP address 2001:bc8:4400:2100::20:20d (or 212.47.238.92 for those without access to the IPv6 world).

We do a DNS resolution for each request sent to the monitored URL. While a classic browser/OS will cache the record locally, we chose to query it each time.

Also, we recently switched to a local resolver, instead of using our provider’s resolver. A cached record now only takes a few milliseconds to be retrieved, while an expired record will still need a bit more (60ms on average).

TCP connection

This is the time spent sending the very first packet to your backend, at the IP address returned by the DNS resolution process. It usually depends on three factors:

• the processing power of the client,
• the distance between the client (the HowFast worker) and the target (your backend), and the “network conditions”,
• the processing power of the backend or load balancer, if applicable.

TLS handshake

This step is only performed if your server is using TLS encryption (hence the “https”). If you are not, you should: there is no valid reason in 2018 to not use TLS encryption on internet communications (it’s fast, useful, easy, and needed). Order of magnitude: no more than 20ms for twitter.com over the last 60 minutes:

With HowFast, you can see how much time TLS handshakes actually take (not much).

Please also note that we are starting a brand new TLS connection for every probe. With “usual” HTTP clients, the TLS handshakes is only performed once for the first request (as well as the DNS resolution, and TCP connection), and the same TCP+TLS connection is reused for subsequent requests.

If this number is high, this may be linked to:

• a low processing power on the client
• a congestioned network or a long distance between the client and the target
• a low processing power on the load balancer / backend.

HTTP request send

At this point, our worker finally started to speak HTTP with your server, hurrah! It can do so because there is a TCP(+TLS) connection established, over which it can send HTTP requests and receive responses.

This “send” step is the time needed to send the HTTP GET request, with its headers, to the target. It can increase in case of bad network connection, or busy target, but is usually quite low.

HTTP wait

In this step, we sent the whole request, and are waiting for the first byte of response from the target. This is usually the time needed by your server to process the request, and generate the full response.

Focusing on this portion of the response time is useful to measure the impact of any performance improvement you just deployed.

HTTP download

In this step, we are downloading the response generated by your server. This time can increase if the network is congestioned or if the response is quite heavy.

Note: if your server starts streaming the response before being done generating it, the time needed to generate the remaining part will be counted as a download time.

Redirects

If you chose to treat redirects as valid responses, HowFast will follow up to three redirects. The time needed to do new DNS queries (if the domain name changed), establishing new TCP and TLS connections and sending, waiting for, and receiving the HTTP response, is summed in the “redirect” step.

In most cases, monitoring only the end URL is preferable, since the performance measurement will be more accurate.

This split time feature is an amazing tool to investigate performance issues:

What is causing these periodic peaks? HowFast will show you!

If you are not already using HowFast, you can sign up for free on https://www.howfast.tech/ and start tracking in seconds! Apart from this split time feature, you will also benefit from 1-minute interval downtime checks with Slack/email notifications, unlimited monitors, performance analysis, and much more. For free.

Let us know what you think of this new feature!