Rainbows! Rack HTTP server user/dev discussion
 help / color / mirror / code / Atom feed
* Rainbows! at a glance summary document
@ 2009-11-27  1:55 Eric Wong
  0 siblings, 0 replies; only message in thread
From: Eric Wong @ 2009-11-27  1:55 UTC (permalink / raw)
  To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw

I just pushed this document out,

  http://rainbows.rubyforge.org/Summary.html

You may note that it includes two Fiber-based concurrency models
currently in rainbows.git which will be in the next release :)

The source is in HAML[1] for now here:

  http://git.bogomips.org/cgit/rainbows.git/tree/Documentation/comparison.haml

Plain text (from w3m -dump) version here for convenience when
replying/annotating.  Let me know if there's anything I missed or
described wrong/sub-optimally.

---------------------------------- 8< -------------------------------
Rainbows! at a glance

Confused by all the options we give you? So are we! Here’s some tables to help
keep your head straight. Remember, engineering is all about trade-offs.

core features and compatibility


    module     rack.input streaming Ruby 1.8 Ruby 1.9 Rubinius slow clients
Unicorn/Base   Yes                  Yes      Yes      Yes      No
Revactor       Yes                  No       Yes      No       Yes
ThreadPool     Yes                  Yes      Yes      Yes      OK
Rev            No                   Yes      Yes      No       Yes
ThreadSpawn    Yes                  Yes      Yes      Yes      OK
EventMachine   No                   Yes      Yes      No       Yes
RevThreadSpawn No                   Slow     Yes      No       Yes
FiberSpawn     Yes                  No       Yes      Yes      Yes
FiberPool      Yes                  No       Yes      Yes      Yes

  • waiting on Rubinius for better signal handling
  • rack.input streaming is what makes upload progress, BOSH, and Web Sockets
    possible
  • rack.input streaming is NOT compatible with current versions of nginx or
    any proxy that fully buffers request bodies before proxying. Keep in mind
    request body buffering in nginx is a good thing in all other cases where
    rack.input streaming is not needed.

application requirements


    module        slow I/O (backend, not       thread        single thread
                         client)               safety          reentrant
Unicorn/Base   avoid                        No           No
Revactor       Rev, Revactor, not Fiber::IO No           Yes
ThreadPool     thread-safe Ruby             Yes          No
Rev            Rev                          No           No
ThreadSpawn    thread-safe Ruby             Yes          No
EventMachine   EventMachine                 No           No
RevThreadSpawn thread-safe Ruby, Rev        Yes          No
FiberSpawn     Rainbows::Fiber::IO          No           Yes
FiberPool      Rainbows::Fiber::IO          No           Yes

  • Requirements for single thread reentrancy are loose in that there is no
    risk of race conditions and potentially mutually exclusive to
    thread-safety. In the case where a Fiber yields while holding a resource
    and another Fiber attempting to acquire it may raise an error or worse,
    deadlock the entire process.
  • Slow I/O means anything that can block/stall on sockets including 3rd-party
    APIs (OpenID providers included) or slow database queries. Properly run
    Memcached (within the same LAN) is fast and not a blocker. Slow I/O on
    POSIX filesystems only includes a few operations, namely on UNIX domain
    sockets and named pipes. Nearly all other operations on POSIX filesystems
    can be considered "fast", or at least uninterruptible.

middlewares and frameworks


    model      DevFdResponse AppPool Rack::Lock            async
Unicorn/Base   no-op         no-op   no-op      lots of RAM :P
Revactor       no-op         Yes     No!        Revactor itself
ThreadPool     no-op         Yes     Yes        standard Ruby
Rev            Yes           no-op   no-op      DevFdResponse
ThreadSpawn    no-op         Yes     Yes        standard Ruby
EventMachine   Yes           no-op   no-op      async_sinatra
RevThreadSpawn Yes           Yes     Dumb       standard Ruby
FiberSpawn     Yes           Yes     No!        Rainbows::Fiber{::IO,.sleep}
FiberPool      Yes           Yes     No!        Rainbows::Fiber{::IO,.sleep}

  • "No!" means it's fundamentally incompatible
  • Everything that's DevFdResponse-compatible can use it for passing async
    responses through
---------------------------------- 8< -------------------------------

[1] - not sure if there's a better/easier way of doing tables for HTML

-- 
Eric Wong
_______________________________________________
rainbows-talk mailing list
rainbows-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/rainbows-talk

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2009-11-27  1:55 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-27  1:55 Rainbows! at a glance summary document Eric Wong

Code repositories for project(s) associated with this inbox:

	../../../rainbows.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).