DEPLOY FAQ HACKING LICENSE NEWS README SIGNALS Sandbox Static_Files Summary TUNING Test_Suite rainbows_1 vs_Unicorn
Rainbows ActorSpawn AppPool Base Configurator Coolio CoolioThreadPool CoolioThreadSpawn DevFdResponse Epoll EventMachine FiberPool FiberSpawn MaxBody NeverBlock Rev RevFiberSpawn RevThreadPool RevThreadSpawn Revactor Sendfile ServerToken StreamResponseEpoll ThreadPool ThreadSpawn ThreadTimeout WriterThreadPool WriterThreadSpawn XEpoll XEpollThreadPool XEpollThreadSpawn

Rainbows! is like unicorn, but Different...

While Rainbows! depends on unicorn for its process/socket management, HTTP parser and configuration language; Rainbows! is more ambitious.

Architectural Diagrams

unicorn uses a 1:1 mapping of processes to clients

unicorn master
\_ unicorn worker[0]
|  \_ client[0]
\_ unicorn worker[1]
|  \_ client[1]
\_ unicorn worker[2]
|  \_ client[2]
...
\_ unicorn worker[M]
   \_ client[M]

Rainbows! uses a M:N mapping of processes to clients

rainbows master
 \_ rainbows worker[0]
 |  \_ client[0,0]
 |  \_ client[0,1]
 |  \_ client[0,2]
 |  ...
 |  \_ client[0,N]
 \_ rainbows worker[1]
 |  \_ client[1,0]
 |  \_ client[1,1]
 |  \_ client[1,2]
 |  \_ client[1,3]
 |  ...
 |  \_ client[1,N]
 \_ rainbows worker[2]
 |  \_ client[2,0]
 |  \_ client[2,1]
 |  \_ client[2,2]
 |  ...
 |  \_ client[2,N]
 ...
 \_ rainbows worker[M]
    \_ client[M,0]
    \_ client[M,1]
    \_ client[M,2]
    ...
    \_ client[M,N]

In both cases, workers share common listen sockets with the master and pull connections off the listen queue only if the worker has resources available.

Differences from unicorn

Similarities with unicorn

While some similarities are obvious (we depend on and subclass off unicorn code), some things are not:


mail archives: https://bogomips.org/rainbows-public/
	nntp://news.public-inbox.org/inbox.comp.lang.ruby.rainbows 
	nntp://news.gmane.org/gmane.comp.lang.ruby.rainbows.general 
public: rainbows-public@bogomips.org / private: rainbows@bogomips.org