Most of the tuning notes apply to Rainbows! as well. Rainbows! is not particularly optimized at the moment and is designed for applications that spend large amounts of the time waiting on network activity. Thus memory usage and memory bandwidth for keeping connections open are often limiting factors as well.
As of October 2009, absolutely ZERO work has been done for performance validation and tuning. Furthermore, Rainbows! is NOT expected to do well on traditional benchmarks. Remember that Rainbows! is only designed for applications that sleep and/or trickle network traffic. In the future, may do well in traditional benchmarks as a side effect, but that will never be the primary goal of the project.
worker_connections too high. It is often better
to start denying requests and only serve the clients you can than to be
completely bogged down and be unusable for everybody.
worker_processes if you have resources (RAM/DB
connections) available. Additional worker processes can better utilize
SMP, are more robust against crashes and are more likely to be fairly
scheduled by the kernel.
If your workers do not seem to be releasing memory to the OS after traffic spikes, consider the mall library which allows access to the mallopt(3) function from Ruby. As of October 2009 tcmalloc (the default allocator for Ruby Enterprise Edition) does not release memory back to the kernel, the best it can do is use madvise(2) in an effort to swap out unused pages.
If you intend to use nginx as a reverse-proxy in front of Rainbows! to handle Comet applications, make sure you disable proxy response buffering in nginx:
This can be disabled on a per-backend basis in nginx, so under no circumstances should you disable response buffering to Unicorn backends, only to Rainbows! backends.
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: email@example.com / private: firstname.lastname@example.org