On 1/18/08 3:07 PM, "Colm MacCarthaigh" <[EMAIL PROTECTED]> wrote: > That's not even a consideration, > async is really for dynamic content, proxies, and other non-sendfile > content.
For dynamic stuff, "X-sendfile" works well. (Just really starting to play with that, liking it so far). The proxy that the LiveJournal folks wrote, I think, copies all the data from the origin server into a file and then uses sendfile to send to the client... Also, we have driven apache as a proxy as far as we have squid... Paul Q and I have been kicking around the idea that even if we go to a completely async core, etc. that modules could mark some hooks as "blocking" and they would run basically how they do today. (One day, Paul, I'll actually think about this more...) Having a request tied to one thread for its lifetime does make some things easier. If the underlying IO is asynchronous and its faster/scalable/fun, then, all the better. I just am not a big fan of the "callback" method that squid uses (or used last time I looked at it). Yes, its doable, but just seems "not quite right" to me. That's just my opinion. I'd like to be able to say, "hey httpd, write this stuff to the client" and it just happen wonderfully fast :) Currently, worker is doing a great job for us. Maybe async would be fine as well, especially if the serf buckets are as easy to use as Justin says. I just don't want us to say "we must be async" with no real reason other than "we must." -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
