On 05 Oct 2015, at 5:13 PM, Eric Covener <[email protected]> wrote: > Is it that common for so much of the server to be tied up in write > completion, or just a very big problem for some systems? Most of my > experience is the opposite problem -- slow (java!) backends rather > than clients not keeping up with the firehose.
It is not common enough for the server to be in write completion. Until now mod_ssl couldn’t enter write completion because it had no way to yield without writing the entire response successfully to the network. As soon as you added SSL the server got synchronous. The key problem to solve was the “mod_cache problem”. How does a backend write into mod_cache at full speed and then go away as soon as possible, while a slow client eventually reads the response? We can now (soon, when mod_cache is taught to be async like mod_ssl is) do that, and that is very cool. The slow clients that become a killer are those on a dodgy mobile phone connection that ends up using a slot for far longer than they should. If that slot is tied through via the proxy to a slow java app, that sucks even more. > It seems like > extending that to handlers (and implicitly, request filters) is more > the "can't be done" part. I’ve been working from right to left, from the network filter backwards to the handlers, and the solution I’ve explored is “if it can’t be done in a handler, make it possible to be done in a filter instead”. The idea is that the handler sets up the filter stack, and then sends down some data to kick things off (or no data like mod_cache does). At that point the handler exits and we’re now in write completion. The filter now (soon) has the power to suspend the connection if we’re waiting for someone else (like a connection from the proxy, a timer callback, whatever), and also has the power to switch the “sense” of a connection from a write to a read. So the output filter might switch the sense to read and then leave, and then when the read event is triggered and we’re kicked, try do a read on the input filter stack. I suspect that a handler can do the same thing right now - switch the sense to read and then suspend itself. On the next read, the handler will be woken up, and off we go, ready to read once. Rinse repeat until we’re done reading. Regards, Graham —
