On Mon, Oct 5, 2015 at 10:57 AM, Graham Leggett <[email protected]> wrote: > > What exactly constituted a moon on a stick? I wanted all of the following: > > - I wanted to make httpd asynchronous, and decisively allow httpd to join the > list of servers that can support hundreds of thousands of concurrent requests > across the board, not just as a special case for specific content (files). > > - I didn’t want to wait. This means I wanted whatever change I made to be > backport-able to httpd v2.4. I don’t care to wait 5 years for httpd v2.6 to > finally to appear as the default version in stable OS distros. > > - I wanted to work with what was already there. That meant making the > existing ap_filter API and the existing buckets work with backwards > compatible changes to httpd and no changes to apr/apr-util. > > - I wanted a mechanism that was not brittle. This is probably the hardest > part of async programming, how do you prevent something spinning or hanging? > When the new mechanism is used wrong the thread just becomes synchronous > until the data is written and eventually works anyway, which is existing > behaviour and not the end of the world. > > I am aware that some people have said that it couldn’t be done in httpd’s > design. I figured let me test that hypothesis by trying anyway, the worst > that could happen was that they were right but the server could at least be > improved as best it could. I believe however that there is a good chance the > moon on a stick has been achieved.
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 seems like extending that to handlers (and implicitly, request filters) is more the "can't be done" part.
