undefined | Better HN

0 pointsotterley8mo ago0 comments

> First, we checked the number of TCP connections using lsof -i TCP:2137 and found that only a single TCP connection was used regardless of in-flight count.

It's head-of-line blocking. When requests are serialized, the queue will grow as long as the time to service a request is longer than the interval between arriving requests. Queue growth is bad if sufficient capacity exists to service requests in parallel.

0 comments

yuliyp8mo ago

I guess I'd thought of head-of-line-blocking as the delay from a slow request stalling subsequent ones beyond the throughput limits of the system: i.e. a slow-to-parse request causes other cheap requests to wait.

otterleyOP8mo ago

Everything in a queue is subject to head-of-line blocking by definition; it's really a question of whether the wait time meets your requirements.

voxic118mo ago

Requests are not serialized though. Http2/GRPC multiplexs multiple requests over one TCP connection.

otterleyOP8mo ago

The TCP connection itself is a single bidirectional queue. So if packets are lost or delayed, then multiplexing doesn't buy you anything.

j / k navigate · click thread line to collapse

0 pointsotterley8mo ago0 comments

> First, we checked the number of TCP connections using lsof -i TCP:2137 and found that only a single TCP connection was used regardless of in-flight count.

0 comments

yuliyp8mo ago

otterleyOP8mo ago

Everything in a queue is subject to head-of-line blocking by definition; it's really a question of whether the wait time meets your requirements.

voxic118mo ago

Requests are not serialized though. Http2/GRPC multiplexs multiple requests over one TCP connection.

otterleyOP8mo ago

The TCP connection itself is a single bidirectional queue. So if packets are lost or delayed, then multiplexing doesn't buy you anything.

j / k navigate · click thread line to collapse