httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Httpd 3.0 or something else
Date Mon, 09 Nov 2009 22:10:59 GMT
On Mon, Nov 9, 2009 at 16:19, Graham Leggett <> wrote:
> Greg Stein wrote:
>> 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.
> How is "pull" different from "push"[1]?

The network loop pulls data from the content-generator.

Apache 1.x and 2.x had a handler that pushed data at the network.
There is no loop, of course, since each worker had direct control of
the socket to push data into.

> Pull, by definition, is blocking behaviour.

You may want to check your definitions.

When you read from a serf bucket, it will return however much you ask
for, or as much as it has without blocking. When it gives you that
data, it can say "I have more", "I'm done", or "This is what I had
without blocking".

> You will only run as often as you are pulled, and never more often. And
> if the pull is controlled by how quickly the client is accepting the
> data, which is typically orders of magnitude slower than the backend can
> push, you have no opportunity to try speed up the server in any way.

Eh? Are you kidding me?

One single network thread can manage N client connections. As each
becomes writable, the loop reads ("pulls") from the bucket and jams it
into the client socket. If you're really fancy, then you know what the
window is, and you ask the bucket for that much data.

> Push however, gives you a choice: the push either worked (yay! go
> browser!), or it didn't (sensible alternative behaviour, like cache it
> for later in a connection filter). Push happens as fast the backend, not
> as slow as the frontend.

Push means that you have a worker per connection, pushing the response
onto the network. I really would like to see us get away from a worker
per connection.

Once a worker thread determines which bucket to create/build, then it
passes it along to the network thread, and returns for more work. The
network thread can then manage N connections with their associated
response buckets.

If one network thread cannot read/generate the content fast enough,
then you use multiple threads to keep the connections full.

Then you want to add in a bit of control around reading of requests in
order to manage the backlog of responses (and any potential memory
buildup that entails). If the network thread is consuming 100M and 20k
sockets, you may want to stop accepting connections or accept but read
them slowly until the pressure eases. etc...


View raw message