A high performance clustering proxy / web server for web applications.
Swiftiply v. 0.6.5 (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 (http://siag.nu/pen/), Swiftiply is not intended as a general purpose load balancer for tcp protocols and unlike HAProxy (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 cluster_port: 80 daemonize: true map: - incoming: - swiftcore.org - www.swiftcore.org outgoing: 127.0.0.1:30000 default: true - incoming: iowa.swiftcore.org outgoing: 127.0.0.1:30010 - incoming: analogger.swiftcore.org outgoing: 127.0.0.1:30020 - incoming: - swiftiply.com - www.swiftiply.com - swiftiply.swiftcore.org outgoing: 127.0.0.1:30030
from https://github.com/wyhaines/swiftiply
------------
Swiftiply 是一个用于 Web 应用的集群代理服务器，和其他集群代理不同的是，它要求后端应用来主动连接，也就是说后端应用是 Swiftiply 的客户端。这样做的好处是后端可维护一个持久化连接到代理服务器，避免 Socket 连接设立时的开销，另外一个就是后端进程可随意进行启动和停止而无需通知代理服务器。因此当需要对后端进行扩充时只需要启动进程即可。依赖于：EventMachine(https://github.com/eventmachine/eventmachine) 和 Mongrel(http://mongrel.rubyforge.org，Mongrel 是一个Ruby的web服务器，它已经是一个全功能、稳定、高效的web应用服务器，可以用它来支撑许多Ruby站点。可以使用它来替代 FastCGI 和 SCGI 来运行 Ruby 程序。）