Paul Dix Explains Nothing

Ruby Http Client Library Performance

Update: I notice that a lot of people land on this page from a search for Ruby HTTP Client. Since writing this post I created what I think is the best http client around for Ruby. It's called Typhoeus and it's super fast and has its own bindings to libcurl.

I'm currently working on a soon to be released feed (atom & rss) library called Feedzirra. One of my criteria for this library is that it should be able to pull multiple feeds as quickly as possible. This feature is one that I find all current Ruby feed libraries lacking in. All of the libraries I've checked out use Net::Http, which has been proven to be slow. So I decided to look at using different http clients, with a focus on ones that could finish multiple requests quickly.

I ran a benchmark test against my own site (just http://www.pauldix.net) using the following libraries:

• Net::Http
• RFuzz
• taf2-curb (a github version of the curb gem that supports the libcurl multi interface)
• EventMachine (specifically, HttpClient2)
• curl-multi (another ruby library that provides an interface to the libcurl multi api)

Here is the output from runs getting once, 10, and 100 times (benchmark code here if you're interested.)

Getting http://www.pauldix.net 1 time:
  user system total real
 taf2-curb 0.010000 0.010000 0.020000 ( 0.687772)
 nethttp 0.000000 0.000000 0.000000 ( 0.627915)
 rfuzz 0.000000 0.000000 0.000000 ( 0.601139)
eventmachine 0.000000 0.000000 0.000000 ( 0.688079)
 curl-multi 0.000000 0.000000 0.000000 ( 0.596781)

Getting http://www.pauldix.net 10 times:
 taf2-curb 0.020000 0.050000 0.070000 ( 0.779883)
 nethttp 0.070000 0.050000 0.120000 ( 6.462604)
 rfuzz 0.010000 0.010000 0.020000 ( 7.973339)
eventmachine 0.010000 0.020000 0.030000 ( 1.046070)
 curl-multi 0.020000 0.040000 0.060000 ( 0.869918)

Getting http://www.pauldix.net 100 times:
 taf2-curb 0.610000 1.850000 2.460000 ( 8.791512)
 nethttp 0.720000 0.530000 1.250000 ( 69.995164)
 rfuzz 0.100000 0.140000 0.240000 ( 67.059852)
eventmachine 0.140000 0.390000 0.530000 ( 7.506380)
 curl-multi 0.740000 1.430000 2.170000 ( 12.315727)

There are plenty of problems with this kind of test. There's variability in speed over the net. Doing a GET on my site doesn't represent the many situations we can run into (like slow responses, slow transfer, or a large page). However, it seems pretty obvious from these tests that EventMachine and the two libraries that use libcurl-multi are the clear winners based on the metric of real time taken, which is the only one we care about.

Now the only thing left to decide on was library features. On this, taf2-curb was the clear winner. With EventMachine, I had problems getting it to pull down anything from FeedBurner and I couldn't get it to handle redirects. With curl-multi, it wasn't obvious how I could handle redirects or set header data. The taf2-curb library supported all the features I needed and let me set any header data I wanted. I'd highly recommend it if you have to do any http client stuff in Ruby.

Making a Ruby C library even faster

Last week I released the first version of a SAX based XML parsing library called SAX-Machine. It uses Nokogiri, which uses libxml, so it's pretty fast. However, I felt that it could be even faster. The only question was how to make a ruby library that is already using c underneath perform better. Since I've never written a Ruby C extension and it's been a few years since I've touched C, I decided it would be a good educational experience to give it a try.

First, let's look into how Nokogiri and SAX-Machine perform a parse. The syntax for SAX-Machine builds up a set of class variables (actually, instance variables on a class object) that describe what you're interested in parsing. So when you see something like this:

It calls the 'element' and 'elements' methods inserted by the SAXMachine module that build up ruby objects that describe what XML tags we're interested in for the Entry class. That's all pretty straight forward and not really the source of any slowdown in the parsing process. These calls only happen once, when you first load the class.

Things get interesting when you run a parse. So you run Entry.parse(some_xml). That makes the call to Nokogiri, which in turn makes a call to libxml. Libxml then parses over the stream (or string) and makes calls to C methods (in Nokogiri) on certain events. For our purposes, the most interesting are start_element, end_element, and characters_func. The C code in Nokogiri for these is basic. It simply converts those C variables into Ruby ones and then makes calls to whatever instance of Nokogiri::XML:SAX::Document (a Ruby object) is associated with this parse. This is where SAXMachine comes back in. It has handlers for these events that match up the tags with the previously defined SAXMachine objects attached to the Entry class. It ignores the events that don't match a tag (however, it still needs to determine if the tag should be ignored).

The only possible place I saw to speed things up was to push more of SAX event handling down into the C code. Unfortunately, the only way to do this was to abandon Nokogiri and write my own code to interface with libxml. I used the xml_sax_parser.c from Nokogiri as a base and added to it. I changed it so the SAXMachine definitions of what was interesting would be stored in C. I then changed the SAX handling code to capture the events in C and determine if a tag was of interest there before sending it off to the Ruby objects. The end result is that calls are only made to Ruby when there is an actual event of interest. Thus, I avoid doing any comparisons in Ruby and those classes are simply wrappers that call out to the correct value setters.

Here are the results of a quick speed comparison against the Nokogiri SAXMachine, parsing my atom feed using code from my last post.

    user  system total  real
sax c  0.060000 0.000000 0.060000 ( 0.069990)
sax nokogiri 0.500000 0.010000 0.510000 ( 0.520278)

The SAX C is 7.4 times faster than SAX Nokogiri. Now, that doesn't seem like a whole lot, but I think it's quite good considering it was against a library that was already half in C. It's even more punctuated when you look at the comparison of these two against rfeedparser.

    user  system total  real
sax c   0.060000 0.000000 0.060000 ( 0.069990)
sax nokogiri 0.500000 0.010000 0.510000 ( 0.520278)
rfeedparser 13.770000 1.730000 15.500000 ( 15.690309)

The SAX C version is 224 times faster than rfeedparser! The 7 times multiple from the Nokogiri version of SAXMachine really makes a difference. Unfortunately, I really only wrote this code as a test. It's not even close to something I would use for real. It has memory leaks, isn't thread safe, is completely unreadable, and has hidden bugs that I know about. You can take a look at it in all its misery on the c-rafactor branch of SAXMachine on github. Even though the code is awful, I think it's interesting that there can be this much variability in performance on Ruby libraries that are using C.

I could actually turn this into a legitimate working version, but it would take more work than I think it's worth at this point. Also, I'm not excited about the idea of dealing with C issues in SAXMachine. I would be more excited for it if I could get this type of SAX parsing thing into Nokogiri (in addition to the one that is there now). For now, I'll move on to using the Nokogiri version of SAXMachine to create a feed parsing library.

SAX Machine - SAX Parsing made easy

For a while now I've been wanting to create a ruby library for feed (Atom, RSS) parsing. I know there are already some out there, but for one reason or another each of them falls short for my needs. The first part of this effort requires me to decide how I want to go about parsing the feeds. One of the primary goals is speed. I want this thing to be fast. So I decided to look into SAX parsing. Further, I wanted to use Nokogiri because I'm going to be doing a few other things with the posts like pulling out links and tags, and sanitizing entries.

SAX parsing is an event based parsing model. It fires events during parsing for things like start_tag, end_tag, start_document, end_document, and characters. Nokogiri contains a very light weight wrapper around libxml's SAX parsing. Using this I started creating a basic declarative syntax for registering parsing events and mapping them into objects and values. The end result is SAX Machine, a declarative SAX parser for parsing xml into ruby objects.

Some of the syntax was inspired by John Nunemaker's Happy Mapper. However, the behavior is a bit different. There are probably many more features I am going to add in as I use it to create my feed parsing library, but the basic stuff is there right now.

Here's an example that uses SAX Machine to parse a FeedBurner atom feed into ruby objects.

So in a few short lines of code this parses feedburner feeds exactly how I want them. It's also pretty fast. Here's a benchmark against rfeedparser running against the atom feed from this blog 100 times.

feedzirra 1.430000 0.020000 1.450000 ( 1.472081)
rfeedparser 15.780000 0.580000 16.360000 ( 16.768889)

It's about 11 times faster in this test. I have to do more tests before I feel comfortable with that figure, but it's a promising start. More importantly this will enable me to make a feed parser that's flexible, extensible, and readable.

SAX Machine is available as a gem as long as you have github added as a gem source. Just do gem install pauldix-sax-machine to get the party started (UPDATE: for some reason it's not built yet. looking into it. UPDATE 2: it's built and ready to go. thanks to nakajima). Also, special thanks to Bryan Helmkamp for helping me turn my initial spike into a decently tested and refactored version (even if it did slow my benchmark down by a factor of 4).