
Network Performance: Bandwidth is only part of the problem (2005) - unmole
http://queue.acm.org/detail.cfm?id=1066069
======
danellis
Do we have to have all these scathing headlines telling us what we do and
don't know? I mean, I've been doing this a while. I do know a thing or two,
and I'm hardly the only one.

I'm surprised ACM stoops to this level of unprofessional clickbait.

~~~
zkms
I don't care about the clickbait, if it gets someone to realise that in most
cases, latency is at least as important a figure of merit than bandwidth or
packet loss, that article does its job.

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.

------
flukus
Developers are generally oblivious to network latency. It's not just a LAN vs
WAN thing either, the LAN will bottleneck if you have to cross the wire 1000
times to full fill a request. n+1 queries aren't necessarily slow because the
database has to do disk reads, they're slow because they have to go back and
forth across the LAN thousands of times. There are seriously a lot of places
out there that think a 10 second wait to load a table with 20 items is
perfectly normal.

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...](https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html)

~~~
WatchDog
I too have seen many occurrences of the dreaded application level JOIN.

Not to mention some of the craziness that happens when a "NoSQL" DB was
chosen, when you really needed a relational database.

~~~
flukus
I think these application level joins (great description, I'm stealing that in
future) are responsible for half the instances NoSql databases (probably more)
because relational ones weren't "scaleable" enough.

------
peterwwillis
Some people, when confronted with a networking problem, think "I know, I'll
make my own protocol." Now they have two problems.

~~~
greglindahl
The 3rd time I tried to re-invent TCP/IP for a particular situation, I got it
right.

------
jrauser
I wrote a talk about this some years ago, "TCP and The Lower Bound of Web
Performance." Here's a relatively recent video:
[https://www.youtube.com/watch?v=C8orjQLacTo](https://www.youtube.com/watch?v=C8orjQLacTo)

------
sliken
I'm aware of gridftp and the HPC version of ssh/scp that helps maximize
bandwidth over high BDP links. Any suggestions for others?

