ryah

ebb version 0.3

Tue, 19 Aug 2008 08:02:28 GMT

This release includes a rather large refactoring of the internals. In particular, the core of Ebb was extracted and expanded into a separate C library called libebb.

New features in Ebb 0.3 are

support for chunked requests (transparent)
support for chunked responses (set the header "Transfer-Encoding: chunked")

support for HTTPS. Use by supplying two extra parameters to the options hash

  Ebb::start_server(SimpleApp.new, 
                     :port => 4001,
                     :ssl_cert => "/home/ryan/projects/ebb/benchmark/ca-cert.pem",
                     :ssl_key => "/home/ryan/projects/ebb/benchmark/ca-key.pem"
                    )

to use HTTPS you must have GnuTLS installed. This is optional.

support for pipelined requests
no longer dependent on glib

Download at the RubyForge project page or by running

gem install ebb

update 0.3.1 fix small bug with chunked responses
update 0.3.2 add hack to work with Merb (who doesn't send Content-Length headers even though she should).

flow v0.0.1

Sat, 09 Aug 2008 21:35:06 GMT

An evented web server for YARV (Ruby 1.9)

Features:

rack interface
persistant and pipelined requests
streaming uploads, each request is in a fiber and will magically yield if you try to read from the request body but the data hasn't arrived yet. (like for large uploads.) to you env['rack.input'] blocks but in reality it never blocks. Uploads are not buffered.
responses can also be streamed. see async_example.rb for an example of the interface. (this interface is subject to change!)
the event loop is exposed, combining your own event loop watchers with async responses allows you to do access external sockets without blocking (database, memcached, other web servers).
supports chunked requests and responses. chunked requests are transparent - it just happens. chunked responses are done when the response header. 'Transfer-Encoding' => 'chunked' is set (case-sensitive)

requires rev

uses the parser from libebb which is based on Mongrel's parser. it does not use the server code from libebb, though (that's the difference between ebb and flow).

You can download it by running

gem install flow

You can start it with:

Flow.start_server(ev_loop, rack_app, :port => 5000)
ev_loop.run

the git repo is here

The next release will support MRI (perhaps without supporting streaming uploads or by using poor man's fibers). I'm still developing Ebb - i hope to have a new release soon.

flow

Wed, 06 Aug 2008 19:42:47 GMT

i wrote another web server today. it only works on yarv and it requires rev but it's mostly written in ruby (instead of c).

http://github.com/ry/flow/tree/master

it uses fibers and not threads. (maybe i'll add deferred requets later)
it should handle chunked uploads (and ~~soon~~ chunked responses)
it does pipelined requests too, i think
but not ssl.

it works like this

    def on_read(data)
      @parser.execute(data)
    rescue Ebb::RequestParser::Error
      close
    end

update i made a gem release

ebb rewrite

Mon, 04 Aug 2008 09:52:42 GMT

I'm nearing a release of Ebb 0.3. Ebb is a Ruby language (YARV or MRI) web server. The new version is includes a large rewrite of the internals to use my new library libebb. This brings several new features. For example, support for HTTPS (if you have GnuTLS installed), pipelined requests, chunked requests. This is mostly due to the new parser in libebb which eases the implementation of such features.

If you'd like to try it out - the following commands might get you started:

git clone git://github.com/ry/ebb.git
cd ebb
rake compile
ruby benchmark/application.rb

If you find some bugs I'd love to hear about it :)
Hopefully by the end of the week things will stabilize enough to make a GEM release.

ssl on libebb

Sun, 27 Jul 2008 13:32:53 GMT

I added support for HTTPS to libebb using gnutls. Usage should be transparent to the user, just replace ebb_server_init with ebb_secure_server_init. libebb provides a default memory-based SSL session cache; this can be overridden by the user.

ebb 0.2.1

Tue, 08 Jul 2008 15:24:20 GMT

I released ebb-ruby 0.2.1. It has some contributed bug fixes.

ebb is a ruby web server library.

download it here

request

Wed, 23 Apr 2008 06:17:32 GMT

Dear Python People,

I have a half-working binding of Ebb to Python through the WSGI interface. I would like someone who can code Python-C bindings and has some experience with WSGI to check it out - perhaps fix some things - and try to get Django (or whatever y'all use) running. Is anyone interested? I'd be happy to give you detailed code explanations.

ry

ebb v0.2

Sat, 19 Apr 2008 16:22:19 GMT

i released ebb-ruby version 0.2
- can listen on arbitrary fd and unix domain sockets
- supports tcp keep-alive
- introduces App#deferred?
- bug fixes and clean code clean up

Sat, 12 Apr 2008 17:10:48 GMT

Slides from my RuPy talk about Ebb
http://s3.amazonaws.com/four.livejournal/20080412/rupy.pdf

spawn_thread?

Mon, 07 Apr 2008 02:08:44 GMT

I added a new feature to Ebb-Ruby. If the application responds to the method spawn_thread?, Ebb will pass that method the request environment before dispatching. If spawn_thread? returns true, the request will be handled asynchronously, otherwise synchronously.

Previously Ebb had the option to spawn a thread for every request or no request. This allows finer control.

The implementation is simply

if app.respond_to?(:spawn_thread?) and !app.spawn_thread?(client.env)
  process(app, client)
else
  Thread.new(client) { |c| process(app, c) }
end

For example, suppose you have one action POST /upload which will respond slowly because it does image resizes. You can write your application code to spawn those requests into a thread so the Ebb can continue to handle other requests while ImageMagick chugs. The rest of your application is snappy, say, and hence would not need the overhead of spawning a thread for each request.

I'm trying to release 0.2 in the next few days - it will include this feature.

slides

Sun, 30 Mar 2008 19:07:23 GMT

Here are the slides from my talk at euruko about ebb
http://s3.amazonaws.com/four.livejournal/20080330/euruko.pdf

keep-alive

Mon, 24 Mar 2008 00:41:14 GMT

I just commited some code to support keep-alive. it's really surprising how much this speeds up things:

(mongrel does not support keep-alive) pushing 8000 req/sec from ruby apps - hilarious

The next bit of trickery is to support Expect/Continue (RFC 2616, sections 8.2.3 and 10.1.1). Once that is complete and the uploading is cleaned up a bit, I think Ebb will be a proper working web server.

Ebb 0.1.0

Tue, 18 Mar 2008 12:36:23 GMT

Ebb 0.1.0 is done.

There are many changes and bug fixes since the last release:

Can now stream responses
Supports threaded requests now. Previously it could only process requests in a sequential manor. If a certain request took very long to process (say 10 seconds) the entire Ebb instance would hang. Now Ebb can spawn a new thread for each request to avoid this problem. (Rails cannot handle threaded requests, so it is disabled for ebb_rails however Merb users will enjoy this feature.)
Better memory usage. Previously Ebb was allocating all of it's memory statically at start up. Now it allocates on demand.
API changes - most notably the Ebb::Server class has been removed. The server is started with Ebb.start_server() now.

I've started a mailing list for questions and patches and moved the official repository to GitHub.

If you try it out please send me an email about your experiences :)

threaded ebb

Tue, 11 Mar 2008 21:57:11 GMT

I've become obsessed with getting Ebb to handle threads better and I think it's doing much better now. The main benchmark that I measure against is an application which sleeps every 10 requests for a given amount of time. This is a very realistic situation, I think; you would not want your server performance to crumble because of a single slow resource. Mongrel, which handles each request in its own thread, does this the best. But now Ebb can handle this too while only taking a modest hit at the throughput. Here is the benchmark showing all other servers being pummeled by the odd slow request.

(ebb_sequential is the exact same code base but without threading the requests. It can be enabled with the -S option to ebb_rails.)

To demonstrate that ebb_threaded still performs well with fast applications here are my standard graphs:

As you can see the sequential ebb is faster and perhaps might work better on websites where the application responds quickly to each request. Some sort of hybrid configuration would be easy to hack onto Ebb so that you could use threaded processing for certain URLs and sequential for others. The key bit looks like this

    while @running
      FFI::server_process_connections()
      while client = FFI::waiting_clients.shift
        if threaded_processing
          Thread.new(client) { |c| c.process(app) }
        else
          client.process(app)
        end
      end
    end

You'd just have to first evaluate client.env['PATH_INFO'] to see if you want threaded processing or sequential.

I'll play around with this code for a few more days before I release it in a gem. It's quite possible there is something incredibly buggy and/or wrong.

ev loop - ruby interface

Sun, 09 Mar 2008 21:28:31 GMT

I've made several attempts at rewriting the core interface between libev event loop and Ruby. The current implementation is the fastest:

    trap('INT')  { @running = false }
    FFI::server_listen_on_port(port)
    puts "Ebb listening at http://0.0.0.0:#{port}/"
    @running = true
    while FFI::server_process_connections() and @running
      if client = FFI::waiting_clients.shift
        process_client(app, client)
      end
    end

The key here is FFI::server_process_connections() which accesses the libev event loop, checks to see if there are any pending events, if so processes them - after all pending requests are finished it returns. If there are not any pending events the call blocks. The blocking is good because it prevents that while loop from running unrestrained. I have a timeout on libev which executes an event after 0.1 seconds just to get the function to return from it's blocked state occasionally.

Ruby's thread scheduler will not act while a C FFI function is being called. This setup is a bit precarious for multithreaded applications - they only get processing time when that loop runs.

It would be better if I could separate libev's loop from Ruby a bit more. I tried that today by putting ev_loop() in it's own pthread separated from the Ruby VM. The question then is, how does the Ruby side sit and wait for new connections? libev callbacks into the RubyVM cannot be executed from the outside like this. The solution I settled on was using a pipe with a nonblocking write side and a blocking read side. Thus the Ruby loop can gracefully block until new connections come in, but still free up the scheduler to handle other threads. This is how it looks

    notify_fd = FFI::server_listen_on_port(port)
    notifier = IO.new(notify_fd)
    puts "Ebb listening at http://0.0.0.0:#{port}/"
    
    while notifier.read(1)
      if client = FFI::server_next_client()
        process_client(app, client)
      end
    end

I like this a lot because it offers a clear interface. Unfortunately it just isn't very fast! Here it is compared to Ebb 0.0.4 and Thin:

Revert back or profile and hope for an obvious fix? Any suggestions?

v0.0.3

Tue, 04 Mar 2008 08:48:52 GMT

Ebb 0.0.3 is up on rubyforge.

x-posted here

python

Sat, 01 Mar 2008 11:05:40 GMT

I'm very happy to hear about Py_BEGIN_ALLOW_THREADS, which if I understand it correctly will allow Python threads to coexist with Ebb's event loop—something that is of continual concern in Ruby. (Ruby 1.9 has a new function called rb_thread_blocking_region which does the same.) Testing Ebb against the many WSGI servers will be fun. I'm especially interested in how it compares to mod_wsgi.

ebb version 0.0.1 is released

Thu, 28 Feb 2008 11:55:59 GMT

http://ebb.rubyforge.org/

(i hope for a flood of bug reports!)

Benchmarks from a real computer

Wed, 27 Feb 2008 17:06:34 GMT

I'm getting very near the first release. I'm a bit nervous!

I had a chance to run the benchmarks on a non-shitty computer (unlike mine) and found something surprising, the performance difference between Mongrel and Evented Mongrel almost disappears. I'm highly suspicious of this (are my benchmark scripts actually running Evented Mongrel on both?)

Nevertheless, the results are fun to see

i rewrote the dispatcher for ebb and now it's awesome!

Wed, 13 Feb 2008 02:00:11 GMT

I rewrote the dispatcher for Ebb after I learned about rb_thread_schedule() and was able to allow each request to thread off inside of Ruby while still maintaining high throughput. That is, I solved the problem with concurrent connections. (maybe. i hope. it is 3am, after all.)

The first benchmark simulates a slow response handled by a Rails application. The evented servers do not get around this blockade and end up hanging. Ebb is now able to side step this a continue to serve. Every 10th request the Ruby application sleeps for 2 seconds.

Here is the response size chart that I've been posting a lot. There is a slow down from previous versions but it's worth the speed hit if Ebb no longer blocks.

(Both benchmarks are run with Ruby 1.8.6. I wonder how this all handles in 1.9?)

I will be speaking at RuPy 2008 about Ebb. I have to hurry up and get started on the Python side of things now.

update

i reverted this code. it might come back later but i was seeing bad performance. see the branch pthread_for_libev_loop. with the revert - ebb will perform as evented mongrel in the face of slow apps - i.e. very shitty.

Not Everything Is Good In Evented Land

Sun, 10 Feb 2008 23:19:55 GMT

I want to expose a weakness in Ebb. As with all evented servers (Thin and Evented Mongrel included) Ebb cannot process requests while handling one. That means, once Ebb passes the request off to Ruby it simply waits until Ruby returns an answer - and can do nothing else. If Ruby returns a response in under a second, I see very good performance from Ebb (see benchmarks from last week). However once the responses get a little slow (emulated by putting a sleep(wait_time) into Ruby) the server falls apart.

Oh, but Ebb isn't meant to be run by itself naked and helpless in front of a storm of traffic. There should be many of them to circumvent the fact that Ruby/Rails do not handle concurrent code well. So we put them behind a load balancer, and better yet, a fair load balancer which will not send requests to an upstream server that does not respond. That is, while one Ebb is hung up on some crappy Rails code, the load balancer will divert requests to others.

But still, the results are not so good. I setup a small application which will wait for x seconds every 10th request. Then I setup 4 Ebbs behind nginx/0.6.25 with the fair proxy patch and hit them with ab for different values of x.

  ebb (c=50,wait=1)  34.75 req/sec (174 completed)
  ebb (c=50,wait=2)  15.53 req/sec (90 completed)
  ebb (c=50,wait=3)  8.29 req/sec (48 completed)
  ebb (c=50,wait=5)  2.0 req/sec (10 completed)
  ebb (c=50,wait=7)  1.43 req/sec (10 completed)
  ebb (c=50,wait=10)  1.8 req/sec (18 completed)

Then I did the same but with traditional threaded Mongrel

  mongrel (c=50,wait=1)  62.74 req/sec (320 completed)
  mongrel (c=50,wait=2)  29.86 req/sec (180 completed)
  mongrel (c=50,wait=3)  17.63 req/sec (106 completed)
  mongrel (c=50,wait=5)  2.8 req/sec (14 completed)
  mongrel (c=50,wait=7)  4.28 req/sec (30 completed)
  mongrel (c=50,wait=10)  2.99 req/sec (30 completed)

:-/

Perhaps this could be address with some sort of hybrid solution? (Record the response time of URLs and start threads for the ones that are continually lagging?)

ebb supports rails

Sun, 10 Feb 2008 15:39:18 GMT

I added an executable to easily run rails applications with Ebb.

You should download Ebb: git clone git://repo.or.cz/ebb.git
and install the gem: rake package && sudo gem i pkg/ebb-0.0.1.gem -- --with-ev-dir=/usr/local

(or where ever your libev is installed. Also make sure you have glib-config in your path.)

cd into your rails project and run: ebb_rails start

Large POST support

Fri, 08 Feb 2008 23:23:04 GMT

I added support for file uploads.

It's not a spectacular graph. I have a bigger buffer. Once we start writing to file, I'm slightly worse than the other servers. Hopefully this can be improved.

I think this is the last major feature to add - now I can work at just making things better and smaller.

Sunday Night Hacking

Sun, 03 Feb 2008 18:46:33 GMT

Wow! I changed around some memory management and suddenly Ebb is much faster

I'm worried that these statistics are too good to be true (Perhaps Ebb is dropping connections or so?) but I can't see any evidence of that in my tests.

Ebb's memory usage is also insanely better. During this benchmark I see this:
Ebb ~ 4 MB
Mongrel ~ 19 MB
Thin ~ 23 MB
Evented Mongrel ~ 24 MB

I started code for request bodies now - once that is done it will be usable as a real server (modulo some smaller features). Maybe there can be a first release next week?

github

Thu, 31 Jan 2008 00:28:13 GMT

I will be pushing Ebb also to GitHub now (in addition to the functional but less pretty repo.or.cz). Supposedly GitHub does subversion mirroring automatically, but I haven't figured out how that works yet. If nothing else the commit pages are easier to read.