Rainbows! Rack HTTP server user/dev discussion
 help / color / mirror / code / Atom feed
From: Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org>
To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
Subject: Rainbows! at a glance summary document
Date: Thu, 26 Nov 2009 17:55:08 -0800	[thread overview]
Message-ID: <20091127015508.GA20733@dcvr.yhbt.net> (raw)

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

                 reply	other threads:[~2009-11-27  1:55 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://yhbt.net/rainbows/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091127015508.GA20733@dcvr.yhbt.net \
    --to=normalperson-rmlxzr9ms24@public.gmane.org \
    --cc=rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhbt.net/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).