headers
Eric Wong | 4 Jun 2010 10:55

[ANN] Rainbows! 0.94.0 - one eight ate my homework!

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@...
* 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Wong | 7 Jun 2010 21:05

a note about Zbatery...

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Wong | 16 Jun 2010 02:56

impromptu Rainbows!/Zbatery user survey

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].
(Continue reading)

Permalink | Reply | 3 comments |
headers
James Tucker | 16 Jun 2010 18:37
Picon
Gravatar

Re: impromptu Rainbows!/Zbatery user survey


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 :)

_______________________________________________
Rainbows! mailing list - rainbows-talk@...
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying
Permalink | Reply | 0 comments |
headers
Eric Wong | 16 Jun 2010 21:08

Re: impromptu Rainbows!/Zbatery user survey

Eric Wong <normalperson@...> 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 :)

--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Tucker | 17 Jun 2010 21:46
Picon
Gravatar

Re: impromptu Rainbows!/Zbatery user survey


On 16 Jun 2010, at 16:08, Eric Wong wrote:

> Eric Wong <normalperson@...> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Wong | 18 Jun 2010 21:05

bumping Rainbows! version requirements?

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
_______________________________________________
Rainbows! mailing list - rainbows-talk@...
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying
Permalink | Reply | 0 comments |
headers
Eric Wong | 26 Jun 2010 04:39

Ruby 1.9 bug with Linux + large static files on 32-bit

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
_______________________________________________
Rainbows! mailing list - rainbows-talk@...
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying
Permalink | Reply | 0 comments |

Gmane