httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm MacCárthaigh <>
Subject Re: 3.0, the 2011 thread.
Date Wed, 15 Jun 2011 23:40:15 GMT
On Wed, Jun 15, 2011 at 3:01 PM, Paul Querna <> wrote:
> I think we have all joked on and off about 3.0 for... well about 8 years now.

At least!

> I think there are exciting things happening in C however.

I love C, but unless we can come up with something radical, it's hard
to see a way out of the prison it creates. That realisation led me to
hacking mostly on functional-oriented servers. I'll try to explain why
- in case any of those thoughts are useful here too :)

I like the things you've pointed out, but they seem relatively
cosmetic. Things like the parser, async, event and portability
frameworks are really cool - but hardly fundamental. Anyone could use
those, in any language - it's not a real leap in the field. Similarly,
SPDY, websockets, COMET and so on are ultra-cool - but are still
potential bolt-ons to almost any kind of webserver. It sucks that we
don't do them well, but doing them better won't fundamentally change
the market or the pressures on adoption.

Today webservers are almost entirely network I/O bound - disk seek and
CPU speeds are pretty great these days, way faster than is really
neccessary. In a properly architected set-up, end-user delay is really
about the limitations of TCP. You can multiplex and use keepalives as
much as you want, you'll eventually realise that the size of the world
and speed of light mean that this inevitably ends up being slow
without a lot of distributed endpoints.

But we have some cool secret sauce to help fix that. I think the best
architectural thing about Apache is buckets and brigades. Using a list
structure to represent portions of differently-generated content like
that is great. Imagine how much better wordpress would run if PHP
represented the php scripts as a some dynamic buckets intermingled
with some static file io buckets (and even repeated when in loops).
There'd be a lot less data to copy around.

Now imagine a backend that could identify the dynamic buckets and, by
forbidding side effects, parallellise work on them - a bucket as a
message in message-passing system of co-routines, for example. Imagine
that in turn feeding into a set of co-routine filters. That's
fundamentally different - it parallelises content generation, but it's
really really hard to do in C.

Then next, imagine a backend that could identify the static buckets
and re-order them so that they come first - it could understand things
like XML and Javascript and intelligently front-load your transfer so
that the content we have ready goes first, while the dynamic stuff is
being built. It's a real layer-8-aware scheduler and content
re-compiler. Again it's really really hard to do in C - but imagine
the benefits of a server layer that really understood how to model and
re-order content.

These are the kinds of transform that make a webservers job as optimal
as it can be. Network data is the most expensive part of any modern
web application, in terms of both time and money, so the ecosystem
faces huge economic pressure to make these as optimal as possible over
time. Things like SPDY are just the first generation.

It'd be cool if Apache 3.0 could do those things - we have some great
building blocks and experience - but it feels like a language with
support for first-order functions and co-routines would be better at

Again, I'm just thinking out loud :)


View raw message