# ANN: Swiftiply 0.5.0 **URL:** \ **Category:** Ruby\ **Created:** [May 12, 2007, 6:41am UTC](https://www.ruby-forum.com/t/ann-swiftiply-0-5-0/103975 "2007-05-12T06:41:59Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [May 12, 2007, 6:41am UTC](https://www.ruby-forum.com/t/ann-swiftiply-0-5-0/103975/1 "2007-05-12T06:41:59Z")
I’d like to announce the first public release of Swiftcore Swiftiply, a clustering proxy for web applications written in Ruby. Kirk H. * * * Swiftiply v. 0.5.0 ([http://swiftiply.swiftcore.org](http://swiftiply.swiftcore.org)) Swiftiply is a backend agnostic clustering proxy for web applications that is specifically designed to support HTTP traffic from web frameworks. Unlike Pen ([Pen](http://siag.nu/pen/)), Swiftiply is not intended as a general purpose load balancer for tcp protocols and unlike HAProxy ([http://haproxy.1wt.eu/](http://haproxy.1wt.eu/)), it is not a highly configurable general purpose proxy overflowing with features. 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 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. Because Mongrel is the preferred deployment method for most Ruby frameworks, Swiftiply includes a version of Mongrel (found in swiftcore/swiftiplied\_mongrel.rb) that has been modified to work as a swiftiply client. This should be transparent to any existing Mongrel handlers, allowing them all to with Swiftiply. In addition, as an offshoot of the swiftiplied\_mongrel, there is a second version that is available. This other version is found in swiftcore/evented\_mongrel.rb; it is a version of Mongrel that has its network traffic handled by EventMachine, creating a Mongrel that runs in an event based mode instead of a threaded mode. For many applications, running in an event based mode will give better throughput than running in a threaded mode, especially when there are concurrent requests coming in. This is because the event based operation handles requests efficiently, on a first come, first served basis, without the overhead of threads. For the typical Rails application, this means that request handling may be slightly faster than the threaded Mongrel for single, non-concurrent requests. When there are concurrent requests, though, the differential increases quickly. FRAMEWORK SUPPORT Swiftcore IOWA IOWA has built in support for running in evented and clustered modes. Rails Swiftiply provides a _REPLACEMENT_ to mongrel\_rails that, throught the use of an environment variable, can be told to run in either the evented mode or the swiftiplied mode. To run a Rails app in evented mode, set the EVENT environment variable. On 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 connect on the same port. This is important. Each of the backends runs against the same port. To make it easier to start multiple Rails backends, a helper script, swiftiply\_mongrel\_rails, is provided. It is just a light wrapper around mongrel\_rails that will let one start N backends, with proper pid files, and stop them. Merb The merb source (trunk only, at this point), has Swiftiply support that works just like the Rails support, built in. Ramaze A couple adapters for Ramaze are included, to allow Ramaze to run with either the evented or the swiftiplied mongrels. They are installed into ramaze/adapter/evented\_mongrel.rb ramaze/adapter/swiftiplied\_mongrel.rb Other Frameworks Swiftiply has been tested with Camping and Nitro, as well. Direct support for them is not yet bundled, but will be in an upcoming release. CONFIGURATION Swiftiply takes a single configuration file which defines for it where it should listen for incoming connections, whether it should daemonize itself, 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 for that site will connect to. Here’s an example: cluster\_address: [swiftcore.org](http://swiftcore.org) cluster\_port: 80 daemonize: true map: - incoming: - [swiftcore.org](http://swiftcore.org) - [www.swiftcore.org](http://www.swiftcore.org) outgoing: 127.0.0.1:30000 default: true - incoming: [iowa.swiftcore.org](http://iowa.swiftcore.org) outgoing: 127.0.0.1:30010 - incoming: [analogger.swiftcore.org](http://analogger.swiftcore.org) outgoing: 127.0.0.1:30020 - incoming: - [swiftiply.com](http://swiftiply.com) - [www.swiftiply.com](http://www.swiftiply.com) - [swiftiply.swiftcore.org](http://swiftiply.swiftcore.org) outgoing: 127.0.0.1:30030 ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [May 12, 2007, 4:43pm UTC](https://www.ruby-forum.com/t/ann-swiftiply-0-5-0/103975/2 "2007-05-12T16:43:44Z")
On 5/12/07, removed\_email\_address@domain.invalid [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > I’d like to announce the first public release of Swiftcore Swiftiply, a > clustering proxy for web applications written in Ruby. This looks promising, but I don’t seem to see a way to use mongrel\_cluster instead of just plain mongrel[\_rails] Currently I use pen in front of a mongrel cluster. I’d love to see an easy way to host multiple back-end clusters for multiple apps under different virtual hosts or root url’s. This looks like it nicely handles the multiple apps case but, unless I miss it, not multiple instances per app. – Rick DeNatale My blog on Ruby [http://talklikeaduck.denhaven2.com/](http://talklikeaduck.denhaven2.com/) ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [May 12, 2007, 5:32pm UTC](https://www.ruby-forum.com/t/ann-swiftiply-0-5-0/103975/3 "2007-05-12T17:32:57Z")
On Sat, 12 May 2007, Rick DeNatale wrote: > miss it, not multiple instances per app. > By multiple instances per app, I assume that you mean multiple backend > processes, right? That’s the whole point. They all connect to the SAME address/port, because the instances are clients of swiftiply instead of being standalone servers. So, for example, if you have the following config section: map: - incoming: [planner.walrusinc.com](http://planner.walrusinc.com) outgoing: [frontend.walrusinc.com:11111](http://frontend.walrusinc.com:11111) - incoming: [blog.walrusinc.com](http://blog.walrusinc.com) outgoing: [frontend.walrusinc.com:11112](http://frontend.walrusinc.com:11112) Then Swiftiply proxies requests for [planner.walrusinc.com](http://planner.walrusinc.com) to the backends connected to [frontend.walrusinc.com:11111](http://frontend.walrusinc.com:11111), and [blog.walrusinc.com](http://blog.walrusinc.com) to the backends connected to [frontend.walrusinc.com:11112](http://frontend.walrusinc.com:11112). Because the backends are clients of Swiftiply, you have have however many of them that you need all connected to the same point. So [blog.walrusinc.com](http://blog.walrusinc.com) is running with 2 backends, but walrusinc’s thoughts become popular, so they spin up a second machine with a couple more backends on it. All of the backends connect to [frontend.walrusinc.com:11112](http://frontend.walrusinc.com:11112). swiftiply\_mongrel\_rails will start N mongrel\_rails processes, all on the same address/port, with a pid file for each (since the default pid file is named by port with mongrel\_rails, that won’t work when all of the processes are connected to the same port). However, I am sure that better integration with mongrel\_cluster is needed. More complete support for all Ruby frameworks is my primary goal for the next release. Kirk H. ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [May 12, 2007, 6:56pm UTC](https://www.ruby-forum.com/t/ann-swiftiply-0-5-0/103975/4 "2007-05-12T18:56:05Z")
On 5/12/07, removed\_email\_address@domain.invalid [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > servers. > connected to [frontend.walrusinc.com:11111](http://frontend.walrusinc.com:11111), and [blog.walrusinc.com](http://blog.walrusinc.com) to the > same address/port, with a pid file for each (since the default pid file is > named by port with mongrel\_rails, that won’t work when all of the > processes are connected to the same port). Okay, I missed that, so swiftipy\_mongrel\_rails is really a substitute for mongrel\_cluster. I guess that you can also put this behind say Apache by setting the cluster\_port to something other than 80 and using mod\_proxy. > However, I am sure that better integration with mongrel\_cluster is needed. > More complete support for all Ruby frameworks is my primary goal for the > next release. I guess that one concern is tracking changes to the base mongrel. Another would be how this interacts with deployment tools like Capistrano and Deprec. – Rick DeNatale My blog on Ruby [http://talklikeaduck.denhaven2.com/](http://talklikeaduck.denhaven2.com/) ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [May 12, 2007, 11:11pm UTC](https://www.ruby-forum.com/t/ann-swiftiply-0-5-0/103975/5 "2007-05-12T23:11:27Z")
On Sun, 13 May 2007, Rick DeNatale wrote: > Okay, I missed that, so swiftipy\_mongrel\_rails is really a substitute > for mongrel\_cluster. Maybe? It was contributed by Ezra Z. and really just represents a starting place for figuring out the best way to support Rails users. > I guess that you can also put this behind say Apache by setting the > cluster\_port to something other than 80 and using mod\_proxy. Yep. In the documentation I used port 80 because one of the ways that I am using this with IOWA is without any other web server in front of it. > I guess that one concern is tracking changes to the base mongrel. (_nod_) The changes are all intended to be transparent to a mongrel handler, so the handlers don’t know nor care whether they are running in a threaded mongrel, in an evented mongrel, or in a swiftiplied mongrel. It just dawned on me that I did not do this in the gem I released last night, but I inteded to insert Mongrel 1.0.1 as a dependency, and will then keep the codebase current to the latest stable Mongrel release as time moves forward. > Another would be how this interacts with deployment tools like > Capistrano and Deprec. I wouldn’t think there is anything special needed for interaction with a deployment tool. Can you expand on your concern there? Thanks Kirk H.