2 ms·
Knowledge of delayed ack and nagle's algorithm wasn't necessary to solve. The explanation didn't mention the flushHeaders call, which is apparently the fix. I
by avidiax 6y ago
Knowledge of delayed ack and nagle's algorithm wasn't necessary to solve.
The explanation didn't mention the flushHeaders call, which is apparently the fix. I didn't run any tests, just looked at the JS and figured that sending 2 packets is worse than sending 1 w.r.t. latency.
It's also a pretty strong intuition that the client side tends to have issues, since the server is usually well-tested and standardized. Also, very often people are measuring wrong, so checking the JS to be sure the time recorded is accurate is also important.
https://nodejs.org/api/http.html#http_request_flushheaders https://nodejs.org/api/http.html#http_request_flushheaders
- Seb-C 6y agoAgree, this knowledge is unnecessary. The first thing I did was use curl to check if it's a client or server problem. Then I looked at the code and immediately noticed the unnecessary flush call, the unnecessary loading of the whole file in memory and the unnecessary fs.stats.
- bajsejohannes 6y agoThere's a huge difference between solving an instance of a problem and understanding the problem. Enough commits of "this seems to fix the problem" and the codebase becomes really hard to work with.
- avidiax 6y agoIt's not reasonable to expect that developers understand how everything works. There are billions of lines of code deployed that work for reasons that the developers either don't know or only think they know. In this case, in my judgement, you only need to know about the delayed-ack/Nagling concepts if there's a engineering requirement to keep the flushHeaders call, and the 50ms latency is a dealbreaker (i.e. not merely a curiosity). Even then, it's not clear how to fix unless you can disable one of those features.