Swiftiply prefers to run in a mode that maintains persistent connections to the backend application processes. Since most Ruby web frameworks don't natively support this, but do support operation with Mongrel, Swiftiply is bundled with a patched version of Mongrel 1.0.1 that will maintain a persistent connection. It should be drop-in compatible with the stock Mongrel 1.0.1, running all of the handlers that Mongrel 1.0.1 will run. To date, this has been tested with the IOWA, Rails, Camping, Merb, and Ramaze (which uses Rack).
As an offshoot of that version of Mongrel, Swiftiply also comes with a second version of Mongrel that has been patched to run in an event driven way, with EventMachine, instead of in a threaded mode. It should be drop-in compatible with existing Mongrel handlers, as well (and has also been tested with IOWA, Rails, Camping, Merb, and Ramaze). For many applications, this will provide better request handling throughput, especially when there are concurrent requests.
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. Take a look at the benchmarks to get a feel for the difference.
Both versions of Mongrel are implemented as a patch against Mongrel 1.0.1. To use either one, just require the relevant library. For swiftiplied_mongrel, this would be
while for evented_mongrel, this would be