Searching...
Event Driven Mongrel and Swiftiply Proxy
Posted by ezmobius Sat, 12 May 2007 08:49:00 GMT
Kirk Haines of the IOWA project has finally released his swiftiply package. I’m really excited about this project. The project has a few parts. There is a monkey patch to Mongrel that rips out ruby’s threading and Socket classes and replaces them with an eventmachine event loop. I have been testing this evented mongrel extensively for the past few weeks and it is notably faster and higher throughput then normal multi threaded mongrel.
It’s a drop in compatible with rails and merb and should work with any custom mongrel handlers you have. Once you install the swiftiply package you can start mongrel_rails with the new evented mongrel like this:
$ EVENT=1 mongrel_rails start
I am getting a huge speedup in merb from evented mongrel. And rails apps run very stable and do not start to slow down and bloat under high concurrent load like threaded mongrel does.
This is big news people. This thing makes shit faster and more stable under load
Now that it the easy way to get started with evented mongrel and buy yourself some performance. But the swiftiply proxy is also very very cool.
Swiftiply works differently from a traditional proxy. In Swiftiply, the backend processes are clients of the Swiftiply server—they make persistent socket connections to Swiftiply. One of the major advantages to this architecture is that it allows one to start or stop backend processes at will, with no configuration of the proxy. The obvious disadvantage is that this is not behavior that backends typically expect.
Luckily there is a swiftiplied version of mongrel in this package as well. I’ll make another post about how to use swiftiply later.
A week or so ago I was able to speed merb up from 299req/sec fro hello world to 620req/sec. Well dropping in evented mongrel gets merb’s hello world to a blazing 987req/sec!! no bull, see this pastie:
So go grab swiftiply and play around a bit. I am using this in production for more then a week now with no adverse affects and the app that runs it has much better response times and memory usage then it did before.
