On 8/3/06, Zed Shaw <[EMAIL PROTECTED]> wrote: > On Thu, 2006-08-03 at 09:40 -0500, James Ludlow wrote: > > On 8/3/06, Zed Shaw <[EMAIL PROTECTED]> wrote: > <snip> > > Setting the performance issue aside for a moment, if I have a long > > download (i.e. streaming video), I'm going to tie up a mongrel process > > for one user for a relatively long time. This isn't a crisis, because > > I can just spawn more, and I'm more constrained by the bandwidth at > > the switch than by memory or CPU time. > > > I think you're misunderstanding the purpose of install ruby-sendfile. > Even *without* sendfile installed Mongrel won't block on sending a file. > It'll still chug away on multiple concurrent files without stopping > anything else. There's a limit of course, but it's not locked like with > Rails.
You are correct about my misunderstanding. I was mistaken about how mongrel would handle this. Why didn't I just check it out to begin with? Laziness apparently. Plus, sendfile "seemed" to be working great. > What sendfile does is this: > > http://www.die.net/doc/linux/man/man2/sendfile.2.html > > It gives ruby the sendfile API. Problem with the sendfile API is that's > it's implemented wildly differently on all the OS and even different > versions of the OS. On some it blocks. On others it can throw > EINTERRUPT. On still others it doesn't even do zero-copy. > > This is the main reason it causes instability in Mongrel. Cool, thanks. > No, what actually happened is Coda Hale put sendfile in a list of gems > to install. Previously most folks weren't installing it. Now that > they're following those docs they were just installing it arbitrarily > without understanding what it did. Yeah, those were the instructions that I used. It really is a nice piece of documentation, despite the current problems being found. > Anyway, let me know how it works. OK -- James _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
