On Mon, Nov 9, 2009 at 13:59, Graham Leggett <[email protected]> wrote:
> Akins, Brian wrote:
>
>>>> It works really well for proxy.
>>> Aka "static data" :)
>>
>> Nah, we proxy to fastcgi php stuff, http java stuff, some horrid HTTP perl
>> stuff, etc (Full disclosure, I wrote the horrid perl stuff.)
>
> Doesn't matter, once httpd proxy gets hold of it, it's just shifting
> static bits.
>
> Something I want to teach httpd to do is buffer up data for output, and
> then forget about the output to focus on releasing the backend resources
> ASAP, ready for the next request when it (eventually) comes. The fact
> that network writes block makes this painful to achieve.
>
> Proxy had an optimisation that released proxied backend resources when
> it detected EOS from the backend but before attempting to pass it to the
> frontend, but someone refactored that away at some point. It would be
> good if such an optimisation was available server wide.
>
> I want to be able to write something to the filter stack, and get an
> EWOULDBLOCK (or similar) back if it isn't ready. I could then make
> intelligent decisions based on this. For example, if I were a cache, I
> would carry on reading from the backend and writing the data to the
> cache, while the frontend was saying "not now, slow browser ahead". I
> could have long since finished caching and closed the backend connection
> and freed the resources, before the frontend returned "cool, ready for
> you now", at which point I answer "no worries, have the cached content I
> prepared earlier".
These issues are already solved by moving to a Serf core. It is fully
asynchronous.
Backend handlers will no longer "push" bits towards the network. The
core will "pull" them from a bucket. *Which* bucket is defined by a
{URL,Headers}->Bucket mapping system.
Cheers,
-g
