Library module: Parallel non blocking http requester

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
mikeytown2's picture

The standard function for making a http requests in Drupal is drupal_http_request(). This works well for simple things. But if you want to send a request out & you don't care about the response back, this built in library isn't the best option; or if you want to do 10 requests at once the standard library isn't the best option either as you have to do each http request sequentially, one at a time.

I'm still working on finalizing this, but I've been able to crack the code in terms of using stream_select() for sending a lot of http requests out in parallel. This allows you to open hundreds of http streams at the same time. Instead of requesting each http stream sequentially, it will do it in parallel; requesting all http streams at the same time. I've benchmarked the code and using the new code for one http request is faster than using drupal_http_request. If doing 10 requests, it can be over 5x faster.

Another nice thing is if you don't care about the response then the new code can be very fast. You can "ping" a url in a non blocking way. The request goes out but then the connection is closed because we do not care about the reply back from the server. This is very helpful for doing tasks in the background. Benchmarking this, it takes about 1ms to ping 10 urls. You read that last part correctly. One millisecond to issue ten http requests on the wire and exit out of the function.

My following modules have something similar to what I'm describing above:
Advanced CSS/JS Aggregation
Boost
Imageinfo Cache
But I'm getting tired of having to maintain 3 different code bases, with each one requiring something different. I'm thinking about releasing my first library module; one that contains this code and makes it available to other modules. The code is based off of the D7 version of drupal_http_request but can be used in Drupal 6 if your using PHP 5.

If you wish to play with the code before I package it up in a module you can get the prototype code here: http://drupal.org/node/1138098#comment-4923822
Some of the new parameter names might change so I do not recommend baking this in to any custom code just yet. This will be a D6 + D7 module. The code is at a low enough level it doesn't matter what version of Drupal your using.

If someone can come up with a good name for this I would appreciate it.

Comments

Sounds great @mikeytown. How

dalin's picture

Sounds great @mikeytown. How about
HTTP Request
HTTP Ping
Fast HTTP

--


Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his

HTTPDQ

AaronELBorg's picture

HTTPDQ

HTTP Parallel Request Library

mikeytown2's picture

The HTTP Parallel Request Library is up and running. Thanks for the naming ideas, they helped me figure out what to call this thing.

This is great. I've been

ISPTraderChris's picture

This is great. I've been trying to figure out a way to regenerate my Varnish cache on expiry from within Drupal, but thought it would be too much of a burden on Cron -- this should do the trick!

one request

yakoub's picture

instead of initiating many none blocking http requests , why not aggregate all the request data into one multiple data structure http request ?

no http

yakoub's picture

if http protocol is not fast enough for you, then don't use http and make custom connection via tcp sockets

CURL Multi?

janusman's picture

What would be the difference between this and using curl_multi calls?

Good question

mikeytown2's picture

We are starting to discus it right now
http://drupal.org/node/622820#comment-4940408

I might pull in curl as well to make a library that will try different methods and degrade down to something simple if curl or stream_select is not available on the server.

I'll find out...

SqyD's picture

I've decided to implement the next version of Purge using this library. Current version has curl_multi code but currently doesn't have the non-blocking feature. I'll make it configurable so we'll be able to compair apples with apples. I hope this will also make it possible to hit the backend after the purge to warm the caches.

Would be cool to have this kind of stuff can be incorporated into core one day. See http://drupal.org/node/64866

curl

mikeytown2's picture

Do you want commit for httprl in-order to make it possible to switch between curl and stream_select?

This would be a good

catch's picture

This would be a good alternative to poor mans cron in Drupal 7 (currently just runs at the end of the request). It might also allow for a decent poor mans queue runner in Drupal 8.

High performance

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week