I’d like to announce the first public release of Swiftcore Swiftiply, a
clustering proxy for web applications written in Ruby.
Swiftiply v. 0.5.0 (http://swiftiply.swiftcore.org)
Swiftiply is a backend agnostic clustering proxy for web applications
specifically designed to support HTTP traffic from web frameworks.
(http://siag.nu/pen/), Swiftiply is not intended as a general purpose
balancer for tcp protocols and unlike HAProxy (http://haproxy.1wt.eu/),
not a highly configurable general purpose proxy overflowing with
What it is, though, is a very fast, narrowly targetted clustering proxy.
In back to back comparisons of Swiftiply to HAProxy, Swiftiply reliably
outperforms HAProxy (tested using IOWA, Rails, Merb, and Ramaze backend
processes running Mongrel).
Swiftiply works differently from a traditional proxy. In Swiftiply, the
backend processes are clients of the Swiftiply server – they make
socket connections to Swiftiply. One of the major advantages to this
architecture is that it allows one to start or stop backend processes at
with no configuration of the proxy. The obvious disadvantage is that
not behavior that backends typically expect.
Because Mongrel is the preferred deployment method for most Ruby
Swiftiply includes a version of Mongrel (found in
that has been modified to work as a swiftiply client. This should be
transparent to any existing Mongrel handlers, allowing them all to with
In addition, as an offshoot of the swiftiplied_mongrel, there is a
version that is available. This other version is found in
swiftcore/evented_mongrel.rb; it is a version of Mongrel that has its
traffic handled by EventMachine, creating a Mongrel that runs in an
based mode instead of a threaded mode. For many applications, running
event based mode will give better throughput than running in a threaded
especially when there are concurrent requests coming in.
This is because the event based operation handles requests efficiently,
a first come, first served basis, without the overhead of threads. For
typical Rails application, this means that request handling may be
faster than the threaded Mongrel for single, non-concurrent requests.
there are concurrent requests, though, the differential increases
IOWA has built in support for running in evented and clustered modes.
Swiftiply provides a REPLACEMENT to mongrel_rails that, throught the
of an environment variable, can be told to run in either the evented
the swiftiplied mode.
To run a Rails app in evented mode, set the EVENT environment variable.
a unixlike system:
env EVENT=1 mongrel_rails
will do it.
To run in swiftiplied mode:
env SWIFTIPLY=1 mongrel_rails
Because Swiftiply backends connect to the Swiftiply server, they all
on the same port. This is important. Each of the backends runs against
same port. To make it easier to start multiple Rails backends, a helper
script, swiftiply_mongrel_rails, is provided. It is just a light
around mongrel_rails that will let one start N backends, with proper pid
files, and stop them.
The merb source (trunk only, at this point), has Swiftiply support that
just like the Rails support, built in.
A couple adapters for Ramaze are included, to allow Ramaze to run with
the evented or the swiftiplied mongrels. They are installed into
Swiftiply has been tested with Camping and Nitro, as well. Direct
them is not yet bundled, but will be in an upcoming release.
Swiftiply takes a single configuration file which defines for it where
should listen for incoming connections, whether it should daemonize
and then provides a map of incoming domain names and the address/port to
proxy that traffic to. That outgoing address/port is where the backends
that site will connect to.
Here’s an example: