Loved it!
Although it didn’t give a comprehensive answer on how to preventively solve the problem on any platform.
Is there one?
Or should software developers just stick to one way or another like some kind of an unspoken rule?
The Case of the 50ms request
71–80 of 88 posts
Re: The Case of the 50ms request
#72grr.. I felt stupid going through the puzzle.. but I was looking at that flushHeaders call and thought that might be a problem - simply because I never call that.
Re: The Case of the 50ms request
#73Twine and SugarCube! Interesting to see that pop up here:
Re: The Case of the 50ms request
#74Knowledge 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.
Re: The Case of the 50ms request
#75Really nice game/tutorial. The best job interview I ever had was framed like this. The interviewer told me there was a bug in the system and had a stack of pages he'd printed out that would provide successive clues as to what caused it. I could ask them questions, in effect using the interviewer as a search engine/debugger. It was the closest an interview has ever come to simulating the day-to-day of a web developer.
I've said it before and will say it again: One code review or debugging session gives an interviewer more actionable information than an effectively unbounded number of logic puzzles.
January 3, 2032.
For several years now, programming has been a required course for all grade-school students.
The tech field is flooded with talent, and it is virtually impossible to get a job.
The technical interview has grown at an unbounded rate.
An aspiring engineer walks into the interview room, freshly shaven. He sits down, cracks his knuckles, takes a long sip from his branded thermos.
Waits.
And then it begins. The interview.
10, 100, 1000 logic puzzles. Faster than seems possible, he recites answers memorized from algoexpert.io.
Cut to a wide shot. Speed up time. Stubble, then a beard, appear on his face. The sun rises and sets, and yet he dare not sleep.
Eventually, he forgets language, reason, civilization, coffee. The touch of his baby son's skin, although he's not such a baby anymore.
He grunts, diagrams, and whiteboards. That's all his life is now.
"Ok, well thank you very much! You'll hear from us soon," Says the interviewer. The sounds are foreign to the engineer, but he is lead out of the office and onto the bright street. His car sits there, rusted.
The interviewer motions the next candidate inside.
He doesn't hear from them.
Re: The Case of the 50ms request
#76Earlier quoted context omitted.
I had to read this remark a couple of times before I realised it's suggesting a curl debugging trace is somehow more definitive and less complicated than tcpdump, despite it being a TCP issue. For those of us who grew up reading W.R.Stevens, that might seem absolutely back-to-front. Not only that, curl ain't gonna help you diagnose the next one, which is a Path MTU Discovery issue, or the one after that, which is an…
To be fair, it was much simpler to develop and retain fluency in tcpdump when your interfaces were physical and your protocols weren't encrypted.
It is a lot nicer to tcpdump/wireshark when you can see everything, but most of the patterns of bad behavior are visible with encrypted data too.
Of course it's not as easy as it used to be / there's a lot more hurdles.
Encryption as you mentioned; although if you control the client or the server, you can often log keys and decrypt with wireshark, but it's a lot of steps, and you don't get helpful feedback to find mistakes.
NIC offloading means the OS doesn't necessarily see packets as they are on the wire. Segmentation offload means you may see larger packets than are on the wire, and checksum offload often makes sent packets show as errors but they're fine on the wire. If the NIC mutilates the packet, that's hard to debug.
It's not easy to run packet captures on mobile devices. If you can't get tcpdump on the device, you can't get captures from the client side of your cellular data. A lot of people don't have a network router they can run tcpdump on either, and if not, they can't get the client side of wifi data either.
Re: The Case of the 50ms request
#77Earlier quoted context omitted.
I've said it before and will say it again: One code review or debugging session gives an interviewer more actionable information than an effectively unbounded number of logic puzzles.
January 3, 2032. For several years now, programming has been a required course for all grade-school students. The tech field is flooded with talent, and it is virtually impossible to get a job. The technical interview has grown at an unbounded rate. An aspiring engineer walks into the interview room, freshly shaven. He sits down, cracks his knuckles, takes a long sip from his branded thermos. Waits. And then it begin…
I think you have rediscovered Forlesen! https://www.wolfewiki.com/pmwiki/pmwiki.php?n=Stories.Forles...
Re: The Case of the 50ms request
#78Earlier quoted context omitted.
January 3, 2032. For several years now, programming has been a required course for all grade-school students. The tech field is flooded with talent, and it is virtually impossible to get a job. The technical interview has grown at an unbounded rate. An aspiring engineer walks into the interview room, freshly shaven. He sits down, cracks his knuckles, takes a long sip from his branded thermos. Waits. And then it begin…
I think you have rediscovered Forlesen ! https://www.wolfewiki.com/pmwiki/pmwiki.php?n=Stories.Forles...
Text link: http://www.lightspeedmagazine.com/wp-content/uploads/2014/06...
(Haven't had a chance to read it yet)
Re: The Case of the 50ms request
#79Knowledge 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,…
Agree, 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.
Re: The Case of the 50ms request
#80Knowledge 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,…
There'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.