3

I have a login script that passes data to another script for processing. The processing is unrelated to the login script but it does a bit of data checking and logging for internal analysis.

I am using cURL to pass this data, but cURL is waiting for the response. I do not want to wait for the response because it's causing the user to have to wait before the analysis is complete before they can log in.

I am aware that the request could fail, but I am not overly concerned.

I basically want it to work like a multi threaded application where cURL is being used to fork a process. Is there any way to do this?

My code is below:

// Log user in

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,'http://site.com/userdata.php?e=' . $email);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$html = curl_exec($ch);
curl_close($ch);

// Redirect user to their home page

Thats all it does. But at the moment it has to wait for the cURL request to get a response.

Is there any way to make a get request and not wait for the response?

Jamie Redmond
  • 731
  • 2
  • 12
  • 14
  • 1
    Do you need to use curl for this? Is `userdata.php` running on the same server? If it is, wouldn't it be a better option to call a background PHP process on the PHP command line instead? – Pekka Jan 02 '11 at 17:26
  • 1
    My hosting provider does not allow exec() – Jamie Redmond Jan 02 '11 at 17:27

4 Answers4

4

You don't need curl for this. Just open a socket and fire off a manual HTTP request and then close the socket. This is also useful because you can use a custom user agent so as not to skew your logging.

See this answer for an example.

Obviously, it's not "true" async/forking, but it should be quick enough.

Community
  • 1
  • 1
Matt
  • 43,482
  • 6
  • 101
  • 102
2

I like Matt's idea the best, however to speed up your request you could a) just make a head request (CURLOPT_NOBODY) which is significantly faster (no response body) or b) just set down the requesttime limit really low, however i guess you should test if the abortion of the request is really faster to only HEADing

Samuel Herzog
  • 3,561
  • 1
  • 22
  • 21
0

Another possibility: Since there's apparently no need to do the analysis immediately, why do it immediately? If your provider allows cron jobs, just have the script that curl calls store the passed data quickly in a database or file, and have a cron job execute the processing script once a minute or hour or day. Or, if you can't do that, set up your own local machine to regularly run a script that invokes the remote one which processes the stored data.

GZipp
  • 5,386
  • 1
  • 22
  • 18
0

It strikes me that what you're describing is a queue. You want to kick off a bunch of offline processing jobs and process them independently of user interaction. There are plenty of systems for doing that, though I'd particularly recommend beanstalkd using pheanstalk in PHP. It's far more reliable and controllable (e.g. managing retries in case of failures) than a cron job, and it's also very easy to distribute processing across multiple servers.

The equivalent of your calling a URL and ignoring the response is creating a new job in a 'tube'. It solves your particular problem because it will return more or less instantly and there is no response body to speak of.

At the processing end you don't need exec - run a CLI script in an infinite loop that requests jobs from the queue and processes them.

You could also look at ZeroMQ.

Overall this is not dissimilar to what GZipp suggests, it's just using a system that's designed specifically for this mode of operation.

If you have a restrictive ISP that won't let you run other software, it may be time to find a new ISP - Amazon AWS will give you a free EC2 micro instance for a year.

Synchro
  • 35,538
  • 15
  • 81
  • 104