3 ms·

Sorry, I'm tired so I'm probably just missing something. It's the binary wrapped by the author's program writing a couple of bytes at a time to stdout right? Wh

Sorry, I'm tired so I'm probably just missing something. It's the binary wrapped by the author's program writing a couple of bytes at a time to stdout right? Why would TCP_NODELAY be relevant when it writes to stdout instead of a TCP socket?

zokier 4y ago
It's just part of narrative, the commonality is programs making excessive short writes > I pretty much forgot about this until the TCP_NODELAY post crossed my path, and then was reminded of this. Clearly, short writes are pretty common.
- c7DJTLrn 4y ago
  I see, thanks. I guess this is due to shoddy code looping through a buffer and calling write() for each byte. So I don't think strace would be revealing anything because it's doing what the author of the black box binary intended. They might not know the performance penalty or might not care.
  - pjc50 4y ago
    > I don't think strace would be revealing anything because it's doing what the author of the black box binary intended That's what it's revealing - the actions of the black box binary.
  - jerf 4y ago
    The problem is worse than that. The particular case on the blog may be shoddy code. But it is easy to encounter cases where the bit of the code that is emitting is most naturally written as making a ton of little write calls. Here's an example. I have some code that streams a very large JSON array out from a DB query. It loops through the results of the DB query and constructs that individual value to send out, then goes to the next one. The resulting write calls are basically '.Write({the JSON object})', and '.Write(",\n ")'. But the JSON objects are individually small. I don't quite end up with literally one write call per character, but you can imagine it's not that hard to end up with several million '.Write("[1,2,3]"', '.Write(",\n ")', which translated to packets is still a problem. Since I'm aware of this problem, I know to put a coalescing buffer between my writer and my network. Any serious language will have one somewhere. The challenge isn't finding it or using it, the challenge is knowing you need to. But you shouldn't really think of the code writing that JSON object out as "shoddy code". It would be an inappropriate separation of concerns for that code to also be inlining its own coalescing buffer implementation into itself. That code should be making a ton of little .Write calls, to keep it simple and focused on its one task. It only becomes "shoddy code" if it is run in a context where the code calling it fails to provide it a coalescing buffer of some sort, be it a language feature, a socket without TCP_NODELAY, etc.
    - moloch-hai 4y ago
      Shoddy is as shoddy does. If your language doesn't provide a convenient way to pass in a coalescing absorber of bytes, that doesn't incur a whole function call (never mind system call) per byte, for the JSONy thing to use, maybe a better language is in order.
csande17 4y ago
TCP_NODELAY is not directly involved in the author's binary. But sending a ton of network packets that only have a few bytes each is pretty much the same problem as making a ton of write() calls with a few bytes each.
pifm_guy 4y ago
The problems are identical when you pipe stdout through SSH...

zokier 4y ago

It's just part of narrative, the commonality is programs making excessive short writes > I pretty much forgot about this until the TCP_NODELAY post crossed my path, and then was reminded of this. Clearly, short writes are pretty common.

c7DJTLrn 4y ago
I see, thanks. I guess this is due to shoddy code looping through a buffer and calling write() for each byte. So I don't think strace would be revealing anything because it's doing what the author of the black box binary intended. They might not know the performance penalty or might not care.
- pjc50 4y ago
  > I don't think strace would be revealing anything because it's doing what the author of the black box binary intended That's what it's revealing - the actions of the black box binary.
- jerf 4y ago
  The problem is worse than that. The particular case on the blog may be shoddy code. But it is easy to encounter cases where the bit of the code that is emitting is most naturally written as making a ton of little write calls. Here's an example. I have some code that streams a very large JSON array out from a DB query. It loops through the results of the DB query and constructs that individual value to send out, then goes to the next one. The resulting write calls are basically '.Write({the JSON object})', and '.Write(",\n ")'. But the JSON objects are individually small. I don't quite end up with literally one write call per character, but you can imagine it's not that hard to end up with several million '.Write("[1,2,3]"', '.Write(",\n ")', which translated to packets is still a problem. Since I'm aware of this problem, I know to put a coalescing buffer between my writer and my network. Any serious language will have one somewhere. The challenge isn't finding it or using it, the challenge is knowing you need to. But you shouldn't really think of the code writing that JSON object out as "shoddy code". It would be an inappropriate separation of concerns for that code to also be inlining its own coalescing buffer implementation into itself. That code should be making a ton of little .Write calls, to keep it simple and focused on its one task. It only becomes "shoddy code" if it is run in a context where the code calling it fails to provide it a coalescing buffer of some sort, be it a language feature, a socket without TCP_NODELAY, etc.
  - moloch-hai 4y ago
    Shoddy is as shoddy does. If your language doesn't provide a convenient way to pass in a coalescing absorber of bytes, that doesn't incur a whole function call (never mind system call) per byte, for the JSONy thing to use, maybe a better language is in order.

csande17 4y ago

TCP_NODELAY is not directly involved in the author's binary. But sending a ton of network packets that only have a few bytes each is pretty much the same problem as making a ton of write() calls with a few bytes each.

pifm_guy 4y ago

The problems are identical when you pipe stdout through SSH...