Bench marking non-blocking HTTPRL vs drupal_http_request

This video talks a little about what HTTPRL is and how you can implement it in your Drupal site.  If you are using Drupal 7.22 and above, you’ll be able to implement it with a checkbox, though you’ll see the most benefit at a code level if you dig into the API.  I did some A / B testing on a use-case I have in the CIS distribution.  CIS is a Drupal distribution I’m working on that has the ability to spawn new Drupal sites in other multisites, and then knows enough about them to communicate back and forth via RestWS authenticated user binds.  To read more about CIS and its RESTful communications, see the links at the bottom of the article.

The short of it

  • Benchmark 3 different ways of requesting the same thing
  • Run 3 different crons by requesting the cron.php file of 3 Drupal sites

In the context of the CIS distribution, related Drupal sites that make up a course have their cron run when a record in CIS related to the courses is updated (for example, a new syllabus is uploaded).  To ensure all parts of the course (contained in different Drupal sites) are synchronized, cron is run which clears potentially cached versions of the syllabus.

Method 1: Drupal’s core drupal_http_request

  • 15.121 seconds

  • This is the default method in Drupal which is pretty poor to be quite honest.  It’s a very generic call that lacks optimization; which is why I wrote my own wrapper for it to serve cached editions.  If you are doing serious connections just with this call, I’d recommend using anything else!

Method 2: Non-blocking HTTPRL

  • 0.1658 seconds, less then 2 tenths of a second!!

  • Unbelievable, we have our winner!  I hope this demonstrates just how costly it is to issue a request and listen for a response back.  Especially since in the case of a cron hit it has to wait for cron (a costly job) to be executed on the link you are pointing to and then wait for the message to come back.

Method 3: HTTPL’s rewriting of drupal_http_request’s

  • 12.425 seconds

  • This provides a better performance bump then doing nothing at all but based on further testing is only marginally better.  I’d still recommend this over nothing if you have things that run drupal_http_request’s currently.

The Winner: Non-blocking HTTPRL

By a LANDSLIDE non-blocking HTTPRL method of request is the winner.  This is expected but if you didn’t know this method existed, you do now so happy optimized developing!

Related postings