Eventmachine talk - Aug 2007 - EventMachine based HTTP server

Hi all,

I''ve been busy lately writing an HTTP server based on EventMachine. I
already had a multi-threaded server called ServerSide, which was
somewhat limited scalability-wise. So I decided to do an experiment
and see how it would work with EventMachine. The result looks very
promising in terms of performance, showing very little degradation
with increasing concurrency.

You can try it for yourself:

  svn co http://serverside.googlecode.com/svn/branches/em/ serverside
  cd serverside
  sudo rake install

Once you have the gem installed you can use the serverside command
line utility to serve static directories:

  serverside serve .

There are probably some bugs and rough edges, but the server is more
or less feature-complete. It does support HTTP 1.1 persistent
connections and HTTP pipelining.

Here''s a simple example to show how to serve dynamic content:

  require ''rubygems''
  require ''serverside''

  server = ServerSide::HTTP::Server.new do
    def handle
      case @uri
      when ''/'':
        send_representation(200, ''text/html'',
''<p>Hello world!</p>'')
      when ''/time'':
        send_representation(200, ''text/html'',
"<p>The time is
#{Time.now}</p>")
      when ''/inspect'':
        send_representation(200, ''text/html'',
"<p>#{inspect}</p>")
      end
    end
  end

  server.start(''0.0.0.0'', 8000)

There''s also support for cookies, HTTP caching, file uploading, HTTP
streaming, and a mechanism for handling and returning error responses
(try running the above example and referencing some random unhandled
URI.)

I''d love to get feedback and suggestions on how to improve it. If
everything goes OK I''ll merge it into the trunk and put out a 0.4
release next week.

best
Sharon

On 8/5/07, Sharon Rosner <ciconia at gmail.com>
wrote:
>
> Hi all,
>
> I''ve been busy lately writing an HTTP server based on
EventMachine. I
> already had a multi-threaded server called ServerSide, which was
> somewhat limited scalability-wise. So I decided to do an experiment
> and see how it would work with EventMachine. The result looks very
> promising in terms of performance, showing very little degradation
> with increasing concurrency.


Were you able to use EM''s epoll feature?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070805/339a060d/attachment.html

> Were you able to use EM''s epoll feature?
How do you do that?

sharon

On 8/5/07, Sharon Rosner <ciconia at gmail.com>
wrote:
> > Were you able to use EM''s epoll feature?
>
> How do you do that?
EventMachine.epoll
EventMachine.set_descriptor_table_size(some_big_number)

It''s pretty simple.  :)

Performance is not bad for the simplest handlers.  Looks like it''s a
smidge faster than an equivalent handler with Mongrel, using my
evented_mongrel patch.

6000/second versus 5200/second with threaded Mongrel running around
3000/second on the same "Hello!" handler.

I''ve been working on an EM based app container for Ruby web apps.
Basically, like Mongrel, but designed from the start with EM and
Swiftiply in mind.  The vast majority of the project is already
written, as pieces and parts from other projects that just need to be
miced together and baked a little bit, but I will take a closer look
at your em based serverside implementation to see if there might be
viable areas for collaboration.


Kirk Haines

On Aug 5, 4:33 pm, Sharon Rosner <cico... at gmail.com>
wrote:
> > Were you able to use EM''s epoll feature?
>
> How do you do that?
>
> sharon
>

Pretty close to the easiest thing in the world. Read the EPOLL
document that is now included with the EM distro.

It''s now in there. I didn''t touch the descriptor table size,
just
added a call to EventMachine.epoll. The performance improves
significantly, about 10-15%, especially for high concurrency.
> 6000/second versus 5200/second with threaded Mongrel running around
> 3000/second on the same "Hello!" handler.
Is this with or without epoll? Anyway good to know it''s twice as fast
as plain mongrel.

sharon