4 ms·

The client isn't always a browser though.

• jsd1982 10y ago
  True, but that's not directly relevant to the observable problems with pipelining. Any client implementing the http/1.1 pipelining semantics will run into the same issues because of the limitations built into the design.
  • RX14 10y ago
    If you go like this: client ---(HTTP/2)---> nginx ---(pipelining)---> japronto Would that not take benefit of japronto's optimisation?
    • bastawhiz 10y ago
      Correct me if I'm wrong, but nginx doesn't support pipelining outbound network requests. Even if it did, the benefits described in the post (mostly due to making fewer syscalls and having fewer packets to parse) go away because now nginx has to do the work instead of Python. There's probably also some overhead required to collect multiple requests together to pipeline them. You'd just be moving the load around.
      • RubyPinch 10y ago
        I would imagine that nginx would probably do a better job of dealing with web serving (pipelineless and otherwise) than python would, mostly due to age And if the nginx process somehow ends up using more CPU than the python process, then using multiple nginx servers would be fairly easy, compared to multiple application servers
• morecoffee 10y ago
  But it is often a proxy, and proxies are both clients and servers. The number of misbehaving proxies is large enough that it isn't reasonable to turn on pipelining globally, which is why browsers don't.