Hacker News Reader

Comment by e12e | Hacker News Reader

> But the benchmark is not fair when only one server supports pipelining.

Anyone know why go went from 45kreq/s to 150 when pipelining was enabled - without supporting pipelining? Or is your last run with yet more concurrent requests?

View on HN

'coz enabling pipelining for the client has some gains (all requests in one package). Even if the server won't pipeline.

But isn't the flow then:

  1) client: gimme 10
  2) server: here, have 1
  3) client: ok, gimme 9!
  4) server: here, have 1
  ...

?

No. Client sends one packet containing the 10 requests. Server sends 10 packets. Basically, the client avoids 9 extra round-trips and sits and waits for the ten replies. However, this whole thing has many cons, that's why is not even used anywhere.

It's more like this:

    1) client: gimme 10, gimme 9...
    2) server: here, have 10
    3) server: here, have 9
    ...

Edit: There is not always a 1:1 relationship between packets and requests/responses, but it's easier to explain that way. You end up sending less packets when pipelining, plus you don't need to wait for a response to send the next request which also saves time (i.e: client has sent every request and server don't have to wait for the client to receive the response to send another request).

Reply on news.ycombinator.com