No clue how I am learning this only now, but better later than never: HTTPS keepAlive
is not enabled by default in Node.js, and it has severe performance implications to network-intense applications.
Just to illustrate the impact, assuming that your server is hosted in us-central1
and it is talking to a service in us-east1
, just the network latency is ~20ms. Since a TCP handshake is a 3-packet event, this means that ~60ms are going to be allocated just to establish TLS handshake.
You can test that with a simple script:
const got = require('got');
const main = async () => {
const response0 = await got('https://posthog.com/');
console.log(response0.timings.phases);
const response1 = await got('https://posthog.com/');
console.log(response1.timings.phases);
};
main();
In this scenario, the above will produce:
{
wait: 1,
dns: 20,
tcp: 72,
tls: 74,
request: 0,
firstByte: 79,
download: 222,
total: 468
}
{
wait: 0,
dns: 1,
tcp: 67,
tls: 69,
request: 1,
firstByte: 73,
download: 234,
total: 445
}
However, watch the total
time if we enable keepAlive
:
const got = require('got');
const https = require('https');
https.globalAgent = new https.Agent({ keepAlive:true });
const main = async () => {
const response0 = await got('https://posthog.com/');
console.log(response0.timings.phases);
const response1 = await got('https://posthog.com/');
console.log(response1.timings.phases);
};
main();
{
wait: 1,
dns: 27,
tcp: 77,
tls: 75,
request: 0,
firstByte: 75,
download: 220,
total: 475
}
{
wait: 0,
dns: 0,
tcp: 0,
tls: 0,
request: 0,
firstByte: 77,
download: 83,
total: 160
}
The second request is 70% faster than the first request!
If your application relies on making many HTTPS calls, then simply enabling keepAlive
is going to result in a significant performance improvement.
Top comments (2)
Just wanted to add this caveat by pointing to this article: connectreport.com/blog/tuning-http...
That's Helpfull. :)