Writing archive

My sender wrote 2.6 MB to a peer that never read anything, and every send() said success. I looked where these bytes waited, what setsockopt really does to the buffer sizes, how a blocking sender is slowed down for free, and how an unbounded queue breaks this.

When an index has every column a query needs, SQLite never opens the table. For one row this saves almost nothing. For 67,245 rows it was 98 ms against 21 ms with a warm cache, and 875 ms against 24 ms with a cold one.

Three send() calls arrived in one recv(), and one send() of 1 MiB arrived in seventeen. TCP keeps the bytes and their order, not the boundaries between your writes. I broke a small JSON reader with two inputs and fixed it with a length prefix and with lines.

Two indexes with the same two columns in a different order. For the same query, one reads 1,885 entries and the other 27,243. I measured why on a SQLite table of one million rows, and found that the leftmost-column rule has an exception called skip-scan.

My client wrote each request in two small pieces, and almost every request took 43 ms or more on loopback, where a round trip costs microseconds. I followed it with strace, ss and the kernel counters to see how Nagle's algorithm and delayed ACK wait for each other.