

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
21 messages in org.apache.httpd.devRe: Is async the answer| From | Sent On | Attachments |
|---|---|---|
| Akins, Brian | Jan 18, 2008 10:51 am | |
| Justin Erenkrantz | Jan 18, 2008 11:16 am | |
| Colm MacCarthaigh | Jan 18, 2008 11:20 am | |
| Akins, Brian | Jan 18, 2008 11:26 am | |
| Akins, Brian | Jan 18, 2008 11:30 am | |
| Colm MacCarthaigh | Jan 18, 2008 12:07 pm | |
| Akins, Brian | Jan 18, 2008 1:16 pm | |
| Colm MacCarthaigh | Jan 18, 2008 1:28 pm | |
| Ruediger Pluem | Jan 18, 2008 2:30 pm | |
| Justin Erenkrantz | Jan 18, 2008 4:33 pm | |
| Niklas Edmundsson | Jan 19, 2008 3:53 am | |
| Graham Leggett | Jan 19, 2008 4:45 am | |
| Davi Arnaut | Jan 19, 2008 6:57 am | |
| Jim Jagielski | Jan 19, 2008 7:04 am | |
| Graham Leggett | Jan 19, 2008 8:01 am | |
| Henrik Nordström | Jan 19, 2008 1:14 pm | |
| Henrik Nordström | Jan 19, 2008 1:19 pm | |
| Davi Arnaut | Jan 19, 2008 3:29 pm | |
| Graham Leggett | Jan 20, 2008 7:44 am | |
| Akins, Brian | Jan 22, 2008 10:03 am | |
| Akins, Brian | Jan 22, 2008 10:07 am |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: Is async the answer | Actions... |
|---|---|---|
| From: | Colm MacCarthaigh (co...@allcosts.net) | |
| Date: | Jan 18, 2008 11:20:00 am | |
| List: | org.apache.httpd.dev | |
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+pg...@stdlib.net







