From normalperson at yhbt.net Fri Jun 4 04:55:09 2010 From: normalperson at yhbt.net (Eric Wong) Date: Fri, 4 Jun 2010 08:55:09 +0000 Subject: [ANN] Rainbows! 0.94.0 - one eight ate my homework! Message-ID: <20100604085509.GA31122@dcvr.yhbt.net> Rainbows! is an HTTP server for sleepy Rack applications. It is based on Unicorn, but designed to handle applications that expect long request/response times and/or slow clients. For Rack applications not heavily bound by slow external network dependencies, consider Unicorn instead as it simpler and easier to debug. However, if you find Unicorn too mainstream these days, you can get your indie cred right here by using Rainbows! today. * http://rainbows.rubyforge.org/ * rainbows-talk at rubyforge.org * git://git.bogomips.org/rainbows.git Changes: This release fixes corrupted large response bodies for Ruby 1.8 users with the WriterThreadSpawn and WriterThreadPool models introduced in 0.93.0. This bug did not affect Ruby 1.9 users nor the users of any older concurrency models. There is also a strange new Rainbows::Sendfile middleware. It is used to negate the effect of Rack::Contrib::Sendfile, if that makes sense. See the RDoc or http://rainbows.rubyforge.org/Rainbows/Sendfile.html for all the gory details. Finally, the RDoc for our test suite is on the website: http://rainbows.rubyforge.org/Test_Suite.html I wrote this document back when the project started but completely forgot to tell RDoc about it. Personally, this test suite is one of my favorite parts of the project. -- Eric Wong From normalperson at yhbt.net Mon Jun 7 15:05:09 2010 From: normalperson at yhbt.net (Eric Wong) Date: Mon, 7 Jun 2010 12:05:09 -0700 Subject: a note about Zbatery... Message-ID: <20100607190509.GA13420@dcvr.yhbt.net> Hi all, I know Zbatery doesn't nearly get as much attention as it deserves (mainly because it can quietly use new features from Rainbows! without needing much release synchronization/announcement). I should say I've been using it heavily for various internal projects and test suites with great success. It's great for test suites because it starts up faster and (fails more loudly/quickly) than Rainbows! That said, I'll be publically releasing a full Rack application soonish[1] that uses Zbatery in its test suite. Rainbows! is (probably) better for heavy production use, especially on medium SMP (2-16 cores)[2] boxes where multiple worker processes can amortize GC costs. Since Zbatery is 99%-reliant on Rainbows! code, I think I'll keep all discussion of it on this mailing list if it's alright with everyone. * http://zbatery.bogomip.org/ # (no that's not a typo :) * git://git.bogomips.org/zbatery [1] - I'm saying this now so somebody can poke me in a month when I realize I've forgotten about it again :) [2] - If anybody is able and willing to share more information about deployments on larger SMP (or even NUMA) systems, let us know! I doubt huge SMP/NUMA boxes are practical for HTTP applications at this point due to bus limitations, but wouldn't mind being proven wrong. -- Eric Wong From normalperson at yhbt.net Tue Jun 15 20:56:53 2010 From: normalperson at yhbt.net (Eric Wong) Date: Tue, 15 Jun 2010 17:56:53 -0700 Subject: impromptu Rainbows!/Zbatery user survey Message-ID: <20100616005653.GA29720@dcvr.yhbt.net> Hi all, Since Rainbows! can be configured so many different ways, I'm wondering about how (or even if :) people use it in production. * Which concurrency model(s) do you use? * Which version(s) of Ruby do you use? * How much peak traffic do you get? (Off-hours traffic is entirely uninteresting) I'll understand if you're not allowed to share all (or any) of that information. If you can only share it privately, you can email me directly, too, I won't tell anyone. Behind the scenes, I've privately helped some folks deploy a few production apps using ThreadSpawn (REE 2010.01), FiberSpawn (1.9.1-p378), and EventMachine (REE 2010.01). I can't say more than that due to confidentiality issues, but I suspect WEBrick would've been more than adequate for those applications :) Even with the massive concurrency available from a single process, I generally use 2-4 worker processes per core since it both spreads GC pause time around and shortens GC time (there's less garbage in a smaller process). I'm writing a Rack application for my home network which will be disk-intensive, so I'll probably deploy using ThreadSpawn with Zbatery under 1.9 to take advantage of IO.copy_stream and splice[1]. [1] http://bogomips.org/ruby_io_splice -- Eric Wong From jftucker at gmail.com Wed Jun 16 12:37:28 2010 From: jftucker at gmail.com (James Tucker) Date: Wed, 16 Jun 2010 13:37:28 -0300 Subject: impromptu Rainbows!/Zbatery user survey In-Reply-To: <20100616005653.GA29720@dcvr.yhbt.net> References: <20100616005653.GA29720@dcvr.yhbt.net> Message-ID: <182DF963-CE7E-41AA-A111-93DB1C6F09C2@gmail.com> On 15 Jun 2010, at 21:56, Eric Wong wrote: > under 1.9 to take advantage of IO.copy_stream and splice[1]. > > [1] http://bogomips.org/ruby_io_splice That's sweet :) From normalperson at yhbt.net Wed Jun 16 15:08:35 2010 From: normalperson at yhbt.net (Eric Wong) Date: Wed, 16 Jun 2010 12:08:35 -0700 Subject: impromptu Rainbows!/Zbatery user survey In-Reply-To: <20100616005653.GA29720@dcvr.yhbt.net> References: <20100616005653.GA29720@dcvr.yhbt.net> Message-ID: <20100616190835.GA20621@dcvr.yhbt.net> Eric Wong wrote: > Hi all, > > Since Rainbows! can be configured so many different ways, I'm > wondering about how (or even if :) people use it in production. One more question: * What proxies, if any, run in front? Either to distribute load between machines, handle failover for a dead machine, to serve static files, etc... > Behind the scenes, I've privately helped some folks deploy a few > production apps using ThreadSpawn (REE 2010.01), FiberSpawn > (1.9.1-p378), and EventMachine (REE 2010.01). I can't say more than > that due to confidentiality issues, but I suspect WEBrick would've been > more than adequate for those applications :) _None_ of these are proxied behind nginx. They only need a load balancer to distribute load between multiple machines and to handle failover if a box goes down. They either use haproxy or a similar, but overpriced black-box[1]. They either do pass-through (Layer 4, TCP-only) or only buffer (and possibly rewrite) HTTP headers (Layer 7). I forget which apps used which, but Rainbows! works great in all of those configurations. [1] not my decision to use it, of course :) -- Eric Wong From jftucker at gmail.com Thu Jun 17 15:46:35 2010 From: jftucker at gmail.com (James Tucker) Date: Thu, 17 Jun 2010 16:46:35 -0300 Subject: impromptu Rainbows!/Zbatery user survey In-Reply-To: <20100616190835.GA20621@dcvr.yhbt.net> References: <20100616005653.GA29720@dcvr.yhbt.net> <20100616190835.GA20621@dcvr.yhbt.net> Message-ID: <75572EBC-8A70-46F4-BCE3-3CDA30E20F63@gmail.com> On 16 Jun 2010, at 16:08, Eric Wong wrote: > Eric Wong wrote: >> Hi all, >> >> Since Rainbows! can be configured so many different ways, I'm >> wondering about how (or even if :) people use it in production. > > One more question: > > * What proxies, if any, run in front? Either to distribute > load between machines, handle failover for a dead machine, to serve > static files, etc... I do know of a bunch of folks using async Thin in production for relatively high concurrency levels (1-4k open connections) serving through nginx. I personally can't verify the numbers, as the boxes are behind doors to which I don't have keys. I don't know if this info is useful to you. >> Behind the scenes, I've privately helped some folks deploy a few >> production apps using ThreadSpawn (REE 2010.01), FiberSpawn >> (1.9.1-p378), and EventMachine (REE 2010.01). I can't say more than >> that due to confidentiality issues, but I suspect WEBrick would've been >> more than adequate for those applications :) > > _None_ of these are proxied behind nginx. They only need a load > balancer to distribute load between multiple machines and to handle > failover if a box goes down. > > They either use haproxy or a similar, but overpriced black-box[1]. They > either do pass-through (Layer 4, TCP-only) or only buffer (and possibly > rewrite) HTTP headers (Layer 7). I forget which apps used which, but > Rainbows! works great in all of those configurations. > > [1] not my decision to use it, of course :) > > -- > Eric Wong > _______________________________________________ > Rainbows! mailing list - rainbows-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/rainbows-talk > Do not quote signatures (like this one) or top post when replying From normalperson at yhbt.net Fri Jun 18 15:05:29 2010 From: normalperson at yhbt.net (Eric Wong) Date: Fri, 18 Jun 2010 19:05:29 +0000 Subject: bumping Rainbows! version requirements? Message-ID: <20100618190529.GA17273@dcvr.yhbt.net> Hi all, Given our lack of current users, maintaining backwards compatibility with old things isn't something I want to spend too much time on. * Any objections to dropping Ruby 1.8.6 support? I believe most folks are on 1.8.7, and 1.9.2 adoption should go up with Rails 3. * Any objections to requiring Rack 1.1.0 or later? Some Rails 2.3.x versions were pinned to Rack 1.0.x, but for the most part 1.1.0 and 1.2.1 are backwards-compatible. Rails 2.2.x and earlier (using Unicorn::App::OldRails) is actually more compatible with newer Rack versions than all but the latest Rails 2.3.x versions. This is only for Rainbows!/Zbatery and will NOT affect Unicorn. -- Eric Wong From normalperson at yhbt.net Fri Jun 25 22:39:17 2010 From: normalperson at yhbt.net (Eric Wong) Date: Fri, 25 Jun 2010 19:39:17 -0700 Subject: Ruby 1.9 bug with Linux + large static files on 32-bit Message-ID: <20100626023917.GA2144@dcvr.yhbt.net> Hi all, Since Rainbows! 0.92.0, static file serving performance was improved under Linux (and possibly Solaris) under 1.9 by using IO.copy_stream. Unfortunately, I've noticed large files (>4G) can get truncated. (2-4G files just end up falling back to a read+write loop in C). There's a trivial patch for the issue here: http://redmine.ruby-lang.org/issues/show/3484 -- Eric Wong