Rainbows...

[Eric Wong <normalperson@yhbt.net>]

Some of you may have noticed the "rainbows" branch of the git
repository.  I may be changing that however and making a small group of
gems (or even one gem) that can get loaded at runtime and monkey patch
parts of Unicorn.

Rainbows will primarily be to support things Unicorn sucks at:

  1. apps that rely on out-of-datacenter network connections
     (CAPTCHA services, OpenID, real-time feed aggregation, etc...)

  2. Comet / long-polling / reverse HTTP

Since the majority of Unicorn use cases (or even requests within an
application) do not need these things, I'm hesitant to make Unicorn
itself more complicated and more difficult to support for the majority
of apps.  Instead, I'm leaning towards putting that burden on Rainbows
for the applications that absolutely need it.

For 1), the apps I've seen that rely on out-of-datacenter network
connections don't use them for the large majority (>= 95%) of HTTP
requests, so the overall application with a few poorly-performing
application endpoints were fine and predictable even with basic Unicorn.

Of course, some folks I know want to make a proxy with Unicorn and
thats why I starting working on it.

As far as concurrency models go, forked workers sharing listener sockets
will continue to be used to better exploit CPU/memory concurrency[1].
However, each worker process will also support Threads or Actors so
there'll be a more flexible M:N mapping of processes:clients instead of
the 1:1 mapping Unicorn uses.

Rev and EventMachine are being considered, too, but mapping those
programming models to TeeInput will be more work...

[1] Even on Ruby implementations without a big global lock for threads,
    forked workers that don't have to share large amounts of memory
    on big SMP boxes, so they'll experience less memory/cache contention
    and should experience better performance as a result.

-- 
Eric Wong