net/http is slow. (and so are libraries that depend on it, like open-uri)

Performance Disclaimer: this ought to matter in your app, measurably, before you do anything about it. If you profile and ruby-prof is showing a bunch of classes like BufferedRead and Timeout at the top of the list, your app qualifies. And in addition if you know that your app is dependent on data transfer over http (let's say you're interacting with a Solr server, and you're storing sizable documents in Solr), you should be aware of the problem.

Otherwise net/http or open-uri might be just fine for you.

The problems with net/http, and benchmarks of ruby http client lbraries are nicely written about in An analysis of Ruby 1.8.x HTTP client performance.

Some good alternatives:

• curb (libcurl wrapper)
• rfuzz
• httpclient / http-access2

Our findings matched the article referenced above - the alternatives have pros and cons but each was at least 10x faster than net/http for transfers of 50-300k response bodies.

The fastest solution we found was curb, reusing the Curl::Easy object:

require "curb"

curl = Curl::Easy.new

2.times do
    curl.url = "http://www.pivotaltracker.com"
    curl.perform
    puts curl.body_str
end

Interesting Things

• ActiveRecord::Base.connection.select_all reads all records into an array, which is not good if you have a very large result set. Use a combination of ActiveRecord::Base.connection.execute with .each, or .each_hash if you want the same column<=>value mappings you get with select_all, only streamed.

• There was some confusion about BlueCloth:

  • There's a gem and a plugin available, and it appears that you need to use both
  • It seems like the only live BlueCloth development (i.e. where patches should be sumbitted) is here: http://github.com/github/bluecloth/tree/master

• A recent MySql trigger experience:

  • In summary, think twice before using them when you have a viable application code alternative
  • They're not cloned from the dev to test database
  • The hosting provider this project is using requires that we submit a change request each time we want to add/change/delete triggers. The problem with that is your trigger changes aren't in sync with your code deployments.
  • It wasn't hard to write the application code

• During a discussion about humanize, a couple other nifty transforms were mentioned:

  • parameterize: You have a string, and you want to strip out characters that aren't url-friendly. (follow the link for good example/discussion)
  • auto_link a Rails helper that takes text and links up all urls and email addresses.