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
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
HTTPDQ
HTTP Parallel Request Library
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
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
instead of initiating many none blocking http requests , why not aggregate all the request data into one multiple data structure http request ?
no http
if http protocol is not fast enough for you, then don't use http and make custom connection via tcp sockets
CURL Multi?
What would be the difference between this and using curl_multi calls?
Good question
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...
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
Do you want commit for httprl in-order to make it possible to switch between curl and stream_select?
This would be a good
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.