Network Performance: Bandwidth is only part of the problem (2005)
queue.acm.org
queue.acm.org
I'm surprised ACM stoops to this level of unprofessional clickbait.
Long, uncontrolled queues that live at fast-slow transition points and induce pathological latency is a very generic issue and is certainly not unique to IPv4 packets getting bufferbloated at CPEs or whatnot. It's always tempting to use cheap memory to make huge buffers to try to increase utilisation (and thus bandwidth) or decrease queuing loss.
Any practitioner who works in any role (designer, programmer, operator/administrator) with packet-switched networks should have some familiarity with this sort of problem -- even if it's just at a "some queuing is good because it increases link utilisation but if queues are too big and are allowed to stay full then latency goes to hell and the network breaks" level.
If the article itself was fluff, then I'd be upset if I wasted my time reading it. But titles? Who cares?
In fact, I'd argue it's more harmful to have boring, non-clickbaity titles on interesting/informative articles than it is to have clickbaity titles on fluff. At least with the latter, it only takes a few seconds of my time to scan through it and see it's fluff. With the former, I may never read the article and completely miss out because I never gave it a chance, which is a waste.
Wouldn't it be more productive to send them a link?
A common anti-pattern I see in the c# world is a pointless service layer (in a separate process) combined with n+1 crud data lookups. All the service layer brings to the table is a lot of serialization (which can be relatively expensive) and a doubling of network latency.
What's even worse is the commonly implemented solution: caching. The database get's unfairly blamed and a caching layer is added, of course this just adds another layer of network latency, does little for best case performance (data in cache) and worsens the worst case performance. Rant over.
Obligatory latency numbers every programmer should know: https://people.eecs.berkeley.edu/~rcs/research/interactive_l...
Not to mention some of the craziness that happens when a "NoSQL" DB was chosen, when you really needed a relational database.
Worse than that. Middleman services are almost never streaming. So they have to read the entire response, parse it, reformulate it and send it back out. Any IO and CPU bottlenecks are seen by the downstream server as additional latency.