# A Web Server Called *Ebb* Ebb aims to be a small and fast web server specifically for hosting web frameworks like Rails, Merb, and in the future Django. It is not meant to be a full featured web server like Lighttpd, Apache, or Nginx. Rather it should be used in multiplicity behind a [load balancer](http://brainspl.at/articles/2007/11/09/a-fair-proxy-balancer-for-nginx-and-mongrel) and a front-end server. It is not meant to serve static files in production. ## Design The design is similar to the [Evented Mongrel](http://swiftiply.swiftcore.org/mongrel.html) web server; except instead of using [EventMachine](http://rubyeventmachine.com/) to drive network interactions, the Ebb web server handles sockets directly in C and employs the use of the [libev](http://software.schmorp.de/pkg/libev.html) event loop. Connections are processed as follows: 1. libev loops and waits for incoming connections. 2. When Ebb receives a connection, it passes the request into the [mongrel state machine](http://mongrel.rubyforge.org/browser/tags/rel_1-0-1/ext/http11/http11_parser.rl) which securely parses the headers. 3. When the request is complete, Ebb passes the information to a user supplied callback. 4. The Ruby binding supplying this callback transforms the request into a [Rack](http://rack.rubyforge.org/) compatible `env` hash and passes it on a Rack adapter. Because Ebb is written mostly in C, other language bindings can be added to make it useful to Non-Ruby frameworks. For example, a Python WSGI interface is forthcoming. ## Download The Ruby binding is available as a Ruby Gem. It can be install by executing `gem install ebb` Ebb depends on having glib2 headers and libraries installed. (Easily available on any UNIX system.) Manual download can be done at the [RubyForge project page](http://rubyforge.org/frs/?group_id=5640). ## Why? Because by building the server in C one is able to side-step the limitations on speed of many scripting languages. Inefficiencies are okay for quick and beautiful code, but for production web servers that might handle thousands of requests a second, an attempt should be made to be as efficient as possible in processing connections. Following are some benchmarks. Please take these measurements with a grain of salt. Benchmarks like these are notorious for presenting an inaccurate or highly slanted view of how software performs. The code for these can be found in the `benchmark` directory. ![Response Size](http://s3.amazonaws.com/four.livejournal/20080227/response_size.png) This shows how the web servers perform with respect to throughput (using a simple Rack application). Concurrency is at 50 clients. ![Concurrency](http://s3.amazonaws.com/four.livejournal/20080227/concurrency.png) A simple concurrent clients benchmark serving a *hello world* page. ![Uploads](http://s3.amazonaws.com/four.livejournal/20080227/post_size.png) Ebb processes uploads before handing it over to the web application. This allows Ebb to continue to process other clients while the upload is in progress. The cliff at 40k here is because Ebb's internal request buffer is set at 40 kilobytes before it writes to file. ## Contributions Contributions (patches, criticism, advice) are very welcome! The source code is hosted at [repo.or.cz](http://repo.or.cz/w/ebb.git). It can be retrieved by executing `git clone http://repo.or.cz/r/ebb.git` I intend to keep the C code base very small, so do email me before writing any large additions. Here are some features that I would like to add: * Streaming responses! * HTTP 1.1 Expect/Continue (RFC 2616, sections 8.2.3 and 10.1.1) * A parser for multipart/form-data * Optimize and clean up upload handling * Option to listen on unix sockets instead of TCP * Python binding ## (The MIT) License Copyright © 2008 [Ry Dahl](http://tinyclouds.org) (ry at tiny clouds dot org)