FAQ

   1 = Frequently Asked Questions about \Rainbows!
   2
   3 === Why is \Rainbows! a separate project from Unicorn?
   4
   5 \Rainbows is for the odd, corner-case requests that Unicorn is poorly
   6 suited for.  More scalable concurrency models introduce additional
   7 complexity that Unicorn users and developers are uncomfortable with for
   8 the common cases.
   9
  10
  11 === What complexity?  Threads/events/actors are easy to work with!
  12
  13 Good for you.  Some of us depend on libraries incompatible with those
  14 models, or are just too lazy to deal with them for the majority of
  15 requests we service.
  16
  17
  18 === Isn't "rainbows" a branch of Unicorn?
  19
  20 That functionality is now in the Revactor model of \Rainbows!
  21
  22
  23 === What happened to the "gossamer" branch of Unicorn?
  24
  25 It became the ThreadPool model of \Rainbows!
  26
  27
  28 === Which concurrency model should I use?
  29
  30 It depends on your application, libraries, Ruby stack and use cases.
  31 That's why we support as many concurrency model as we can.  Each model
  32 has their own strengths and weaknesses in terms of maturity,
  33 ease-of-debugging, compatibility, performance, and memory usage.
  34
  35
  36 === Should I put \Rainbows! behind nginx to serve slow clients?
  37
  38 It is optional.  You can still use nginx to route certain requests to
  39 Unicorn and others to \Rainbows!  nginx will always outperform
  40 \Rainbows! in both pure reverse proxy applications and for serving
  41 static files,  but \Rainbows! is for hosting applications that are more
  42 easily-implemented in Ruby than C.
  43
  44
  45 === Should I use \Rainbows! to serve static files?
  46
  47 It depends on the size and amount of static files you're serving.  If
  48 you're serving a lot of static files (especially large ones), then by
  49 all means use nginx.  If not, then \Rainbows! is likely a "good enough"
  50 solution even if nginx will always outperform it in raw throughput.
  51
  52
  53 === How do I support SSL?
  54
  55 If you need a streaming "rack.input" to do upload processing within your
  56 Rack application, then {stunnel}[http://stunnel.org/] is required.
  57 Otherwise, nginx is a perfectly good reverse proxy.
  58
  59 Refer to the {Unicorn FAQ}[http://unicorn.bogomips.org/FAQ.html] on how
  60 to ensure redirects go to "https://" URLs.
  61
  62
  63 === Is there a "rainbows_rails" command like there is "unicorn_rails"?
  64
  65 Only if you write one and plan to support it.
  66
  67 "unicorn_rails" was written primarily to support older versions of
  68 Rails.  Since \Rainbows! is designed for newer Rails, it can just use
  69 a "config.ru" file like other Rack frameworks and applications.
  70
  71 For Rails 2.3.x and later, the following config.ru will work for you:
  72
  73   ENV["RAILS_ENV"] ||= ENV["RACK_ENV"]
  74   require "config/environment"
  75   use Rails::Rack::Static
  76   run ActionController::Dispatcher.new
  77
  78 For older versions of Rails, the following config.ru will work:
  79
  80   ENV["RAILS_ENV"] ||= ENV["RACK_ENV"]
  81   require 'config/boot'
  82   require 'config/environment'
  83   require 'unicorn/app/old_rails'
  84   require 'unicorn/app/old_rails/static' # not needed with Unicorn 0.95+
  85   use Unicorn::App::OldRails::Static
  86   run Unicorn::App::OldRails.new
  87
  88 One thing to watch out for is that RAILS_ENV will not be set in the
  89 environment for you, thus we set it to match RACK_ENV.