On Sun, 24 Jan 2010 12:23:46 +0100, Bardur Arantsson <[email protected]> wrote: > Michael Snoyman wrote: > > [--snip--] > > Next, I have made the ResponseBodyClass typeclass specifically with the goal > > of allowing optimizations for lazy bytestrings and sending files. The former > > seems far-fetched; the latter provides the ability to use a sendfile system > > call instead of copying the file data into memory. However, in the presence > > of gzip encoding, how useful is this optimization? > [--snip--] > > I'm hoping that the "Web" bit in your project title doesn't literally > mean that WAI is meant to be restricted to solely serving content to > browsers. With that caveat in mind: > > For non-WWW HTTP servers it can be extremely useful to have sendfile. An > example is my Haskell UPnP Media Server (hums) application. It's sending > huge files (AVIs, MP4s, etc.) over the network and since these files are > already compressed as much as they're ever going to be, gzip would be > useless. The CPU load of my hums server went from 2-5% to 0% when > streaming files just from switching from a Haskell I/O based solution to > proper sendfile. > > Lack of proper support for sendfile() was indeed one of the reasons that > I chose to roll my own HTTP server for hums. I should note that this was > quite a while ago and I haven't really gone back to reevaluate that > choice -- there's too many HTTP stacks to choose from right now and I > don't have the time to properly evaluate them all.
Good reason indeed. > For this type of server, response *streaming* is also extremely > important for those cases where you cannot use sendfile, so I'd hate to > see a standard WAI interface preclude that. (No, lazy I/O is NOT an > option -- the HTTP clients in a typical UPnP media client behave so > badly that you'll run out of file descriptors in no time. Trust me, I've > tried.) Is the experiment easily re-doable? I would like to try using safe-lazy-io instead. -- Nicolas Pouillard http://nicolaspouillard.fr _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
