Re: Is async the answer

["Akins, Brian" <Br...@turner.com>]

On 1/18/08 12:18 PM, "Colm MacCarthaigh" <co...@allcosts.net> wrote:


> Hmmm, it depends what you mean by scale really. Async doesn't help a
> daemon scale in terms of concurrency or throughput, if anything it might
> even impede it, but it certainly can help improve latency and
> responsivity greatly. On the whole, it's easy to see how it might make
> the end user experience of a very busy server much more pleasant.


I also wonder is that has actually been tested or if it's just a "factoid"?


>> Response time never increased in any measurable amount.
> 
> I suspect it might though if the scheduler became bound, async would
> route the interupts more efficiently.


But, I wonder if the scheduler would become bound in a "reasonable" amount
of traffic.


> discussions on scalability baffling, the reality is that modern hardware
> can outscale pretty much any amount of bandwidth you can buy regardless
> of the software. 

Bandwidth generally isn't an issue for us anymore (thanks to gzip).  We can
still overrun the CPU with small objects requests/responses.  On "large"
objects (ie, over 16k or so), the CPU is bored when multiple gig interfaces
are full.



> The scalability wars should really be over,
> everyone won - kernel's rule :-)

Which is why I hate to see a ton of work go into async core if it actually
does very little to help performance (or if it hurts it) and makes writing
modules harder.  It braindead simple nowadays to write well behaved high
performance modules (well, mostly) bcs you rarely worry about threads,
reads/writes, etc.  Full async programming is just as challenging as
handling a ton of threads yourself.


My $.02 US worth (which ain't much).


-- 
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies

-- 
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies

Re: Is async the answer

[Colm MacCarthaigh <co...@allcosts.net>]

On Fri, Jan 18, 2008 at 02:31:11PM -0500, Akins, Brian wrote:
> On 1/18/08 2:20 PM, "Colm MacCarthaigh" <co...@allcosts.net> wrote:
>  
> > I think so, in some environments anyway. If you have a server tuned for
> > high throughput accross large bandwidth-delay product links then you
> > have the general problem of equal-priority threads sitting around with
> > quite a lot of large impending writes.
> 
> Doesn't sendfile (and others) help in that case?  Also RAM is cheap,
> bandwidth isn't :)

Oh if you can use sendfile, you use it sure, and whether its used async
or not isn't going to make a big deal, all of the benefits are the zero
copy, the DMA, the TOE, and so on. That's not even a consideration,
async is really for dynamic content, proxies, and other non-sendfile
content.

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

Re: Is async the answer

["Akins, Brian" <Br...@turner.com>]

On 1/18/08 2:20 PM, "Colm MacCarthaigh" <co...@allcosts.net> wrote:
 
> I think so, in some environments anyway. If you have a server tuned for
> high throughput accross large bandwidth-delay product links then you
> have the general problem of equal-priority threads sitting around with
> quite a lot of large impending writes.

Doesn't sendfile (and others) help in that case?  Also RAM is cheap,
bandwidth isn't :)



-- 
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies

Re: Is async the answer

[Colm MacCarthaigh <co...@allcosts.net>]

On Fri, Jan 18, 2008 at 01:52:02PM -0500, Akins, Brian wrote:
> On 1/18/08 12:18 PM, "Colm MacCarthaigh" <co...@allcosts.net> wrote:
> > Hmmm, it depends what you mean by scale really. Async doesn't help a
> > daemon scale in terms of concurrency or throughput, if anything it might
> > even impede it, but it certainly can help improve latency and
> > responsivity greatly. On the whole, it's easy to see how it might make
> > the end user experience of a very busy server much more pleasant.
> 
> I also wonder is that has actually been tested or if it's just a "factoid"?

I've tested, and it met my expectations on Linux 2.6 on Itanium, but I
can't guarantee that the experiments were free from my own bias I guess. 

> >> Response time never increased in any measurable amount.
> > 
> > I suspect it might though if the scheduler became bound, async would
> > route the interupts more efficiently.
> 
> But, I wonder if the scheduler would become bound in a "reasonable" amount
> of traffic.

I think so, in some environments anyway. If you have a server tuned for
high throughput accross large bandwidth-delay product links then you
have the general problem of equal-priority threads sitting around with
quite a lot of large impending writes. Having them all in the polling
loop is inefficient, and async is going to reduce the latency a little,
though granted these days we may be talking about nanoseconds. And
I guess responsivity and high BDP don't go together anyway, due to the
speed of light.

> > The scalability wars should really be over,
> > everyone won - kernel's rule :-)
> 
> Which is why I hate to see a ton of work go into async core if it actually
> does very little to help performance (or if it hurts it) and makes writing
> modules harder.  It braindead simple nowadays to write well behaved high
> performance modules (well, mostly) bcs you rarely worry about threads,
> reads/writes, etc.  Full async programming is just as challenging as
> handling a ton of threads yourself.

I think if it interests people and they want to work on it, cool stuff,
but don't neccessarily expect any actual pay-off in terms of
performance. One of the great things about an open source project is
that sometimes what gets worked on isn't driven by considerations other
than what people feel like working on. 

I'd be less worried about the effect on modules, many module authors 
already can't be bothered to make their modules thread-safe, but 
prefork still exists (and scales quite well, on many platforms).

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

Re: Is async the answer

[Jim Jagielski <ji...@jaguNET.com>]

On Jan 18, 2008, at 2:16 PM, Justin Erenkrantz wrote:

> On Jan 18, 2008 10:52 AM, Akins, Brian <Br...@turner.com> wrote:
>> Which is why I hate to see a ton of work go into async core if it  
>> actually
>> does very little to help performance (or if it hurts it) and makes  
>> writing
>> modules harder.  It braindead simple nowadays to write well  
>> behaved high
>> performance modules (well, mostly) bcs you rarely worry about  
>> threads,
>> reads/writes, etc.  Full async programming is just as challenging as
>> handling a ton of threads yourself.
>
> Speaking for myself, I think writing and using buckets with serf is
> more straightforward than our complicated bucket brigade system with
> mixed push/pull paradigms.
>

+1... Although the whole concept of buckets and their brigades
has some cool advantages, they are also a semi-constant source
of issues...

Re: Is async the answer

["Akins, Brian" <Br...@turner.com>]

On 1/18/08 2:16 PM, "Justin Erenkrantz" <ju...@erenkrantz.com> wrote:

> Speaking for myself, I think writing and using buckets with serf is
> more straightforward than our complicated bucket brigade system with
> mixed push/pull paradigms.

It very well may be.

Async may be easy.  Except when my db connection blocks.. On stat calls..
Etc.

I am by no means defending the buckets!  Or anything for that matter... Just
some observations.  I just no longer buy into the idea that async is somehow
inherently superior.  It sounds good in theory, but in the "real world" I am
just not seeing it.

The whole reason I brought this up was to stimulate discussion.  I really
really would hate for us to spend many months porting everything over to
async to discover that it made no positive impact on performance. Worse, it
made extending httpd (or "D") much harder.



-- 
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies

Re: Is async the answer

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Jan 18, 2008 10:52 AM, Akins, Brian <Br...@turner.com> wrote:
> Which is why I hate to see a ton of work go into async core if it actually
> does very little to help performance (or if it hurts it) and makes writing
> modules harder.  It braindead simple nowadays to write well behaved high
> performance modules (well, mostly) bcs you rarely worry about threads,
> reads/writes, etc.  Full async programming is just as challenging as
> handling a ton of threads yourself.

Speaking for myself, I think writing and using buckets with serf is
more straightforward than our complicated bucket brigade system with
mixed push/pull paradigms.

YMMV.  -- justin