1 = \Rainbows! is like Unicorn, but Different...
3 While \Rainbows! depends on Unicorn for its process/socket management,
4 HTTP parser and configuration language; \Rainbows! is more ambitious.
6 == Differences from Unicorn
8 * log rotation is handled immediately in \Rainbows! whereas Unicorn has
9 the luxury of delaying it until the current request is finished
10 processing to prevent log entries for one request to be split across
13 * load balancing between workers is imperfect, certain worker processes
14 may be servicing more requests than others so it is important to not
15 set +worker_connections+ too high. Unicorn worker processes can never
16 be servicing more than one request at once.
18 * speculative, non-blocking accept() is not used, this is to help
19 load balance between multiple worker processes.
21 * HTTP pipelining and keepalive may be used for GET and HEAD requests.
23 * Less heavily-tested and inherently more complex.
26 == Similarities with Unicorn
28 While some similarities are obvious (we depend on and subclass of
29 Unicorn code), some things are not:
31 * Does not attempt to accept() connections when pre-configured limits
32 are hit (+worker_connections+). This will first help balance load
33 to different worker processes, and if your listen() +:backlog+ is
34 overflowing: to other machines in your cluster.
36 * Accepts the same {signals}[http://unicorn.bogomips.org/SIGNALS.html]
37 for process management, so you can share scripts to manage them (and
40 * supports per-process listeners, allowing an external load balancer
41 like haproxy or nginx to be used to balance between multiple
44 * Exposes a streaming "rack.input" to the Rack application that reads
45 data off the socket as the application reads it (while retaining
46 rewindable semantics as required by Rack). This allows Rack-compliant
47 apps/middleware to implement things such as real-time upload progress