3 ms·

> 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 su

• nitely 10y ago
  'coz enabling pipelining for the client has some gains (all requests in one package). Even if the server won't pipeline.
  • e12e 10y ago
    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 ... ?
    • nitely 10y ago
      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).