rainbows.git  about / heads / tags
Unicorn for sleepy apps and slow clients
blob e04ef567db375861e23cfdb42acf9518c5fa9cf7 1636 bytes (raw)
$ git show v0.4.0:DEPLOY	# shows this blob on the CLI

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
= Deploying \Rainbows!

== nginx proxying to \Rainbows! or Unicorn

For high-traffic applications, routing slow actions to \Rainbows! with
nginx is recommended as nginx can serve static files faster and nginx
can forward fast actions to Unicorn.

          static files
            |
      nginx |--> slow actions --> Rainbows!
            |
            `--> fast actions --> Unicorn

Be sure to set <tt>proxy_buffering off</tt> in nginx for "slow actions"
if you have Comet applications (but not for Unicorn).

== \Rainbows! only

For the daring (or low-traffic sites), you should consider deploying
\Rainbows! in a standalone configuration.  This will be more highly
recommended as \Rainbows! stabilizes, especially if static file
performance improves (or you don't need them).

You will need to do this to support things like BOSH or do real-time
processing of the request body as it is being uploaded.

In this case, haproxy or any similar (non-request-body-buffering) load
balancer should be used to balance requests between different machines.

== Denial-of-Service Concerns

Since \Rainbows! is designed to talk to slow clients with long-held
connections, it may be subject to brute force denial-of-service attacks.
In Unicorn and Mongrel, we've already enabled the "httpready" accept
filter for FreeBSD and the TCP_DEFER_ACCEPT option in Linux; but it is
still possible to build clients that work around and fool these
mechanisms.

\Rainbows! itself does not feature any explicit protection against brute
force denial-of-service attacks.  We believe this is best handled by
dedicated firewalls provided by the operating system.

git clone https://yhbt.net/rainbows.git