Asynchronous PHP processing

[Matt]

This question may be a bit on the technical side:

I have a script located on a remote server that is responsible for logging access to pages in real time. On my FQ site, my pages have PHP code embedded that sends the url, ip, etc. This, of course, adds the overhead of making a connection to a remote server on each page load, which may mean up to a second or two added to total page load times. However, this is not simply an additional second or two added AS the page downloads, rather 1-2 sec. delay BEFORE the page starts to download.

This has got me wondering a few things
1. Does tag placement matter (i.e. if I place the php tags at the end of the page, will the page transfer AS the php code is being executed, or or does the php code have to be fully executed before any of the page is transferred)?
2. Is it possible to make 'asynchronous' calls (i.e. start executing the PHP code even as the page is transferred)? In my case I don't need to wait around for the remote server to respond as the HTML code is irrespective of the remote server response.

Thanks for your input- Matt

[Rich]

I would assume that since the Apache web server would not know that the PHP code does not produce html output, that the page would not be sent to the browser until the code had been executed.

But, why take such a huge performance hit when it isn't necessary? The access logs already contain quite a bit of information. Even if they don't have what you want to track or if you don't want to use the access logs, why not write the log file locally and then use a nightly cron job to transfer the log file the the other server?

If the access log already contains the info you need, you can just transfer that to the other server daily for processing.

[PaulKroll]

Rich is dead-on here: from what you've described, you're spending a LOT of server time on something that's already being done for you.

Course, it's not like server PROCESSOR time, since most of that is your script waiting for the other machine, not rendering 3d images or anything. But it's still holding a connection for much longer than a "normal" page hit for your script.

Anyway, just to be complete, you may well be able to do what you're looking to do with the PHP Output Control Functions. But no promises.

[Matt]

If the access log already contains the info you need, you can just transfer that to the other server daily for processing.

Unless I would like to process this information in "real-time." The goal is to get an "up-to-the-minute" traffic analysis.

why not write the log file locally and then use a nightly cron job to transfer the log file the the other server?

This is indeed something that I considered. It is likely that I will end up writing the log file locally and transferring it to the remote server when it is needed (like when the user is analyzing traffic).

But it's still holding a connection for much longer than a "normal" page hit for your script.

True

Anyway, just to be complete, you may well be able to do what you're looking to do with the PHP Output Control Functions. But no promises.

These functions sound useful... though not necessarily in this particular application. By buffering everything server-side until everthing is processed, it seems that the delay wouldn't be less and possibly even more. THANKS for the link though. Certainly might come in handy for other projects.

Thanks for the input. It certainly would be nice to be able to specify that PHP execute the code as a separate "thread" and not hang around for a response, like when doing an INSERT DELAYED into a MySQL DB. -Matt

[Matt]

Update: I came across http_post and replaced the fopen/ include call I had been using with calls to the http_post functions. This seems to offer better performance. For anyone wishing to POST values using PHP, http_post seems to do the trick. -Matt

[skolnick]

Although it won't help with FQ sites (I don't think) syslog (the Unix logging utility) supports logging to remote machines. If you had your own machine you could set it up to log remotely, and do whatever you want with the data on the remote machine without additional processing load on the web server.

If you have to move log information from FQ servers somewhere else, you could reduce the impact on serving pages using a Perl script that forks. Call the script using the actual page to serve as additional path information (e.g. http://www.webspacecreations/cgi-bin/logger.pl/path-to-page.html). In the Perl script fork immediately. In the parent process read the html page in from disk and pass it to the web server to pass to the user. In the child process, send the data (over a socket, through e-mail, FTP, http post, etc) to the remote machine.

This way you can build new pages without having to paste in logging code to each one.

[Matt]

Dave,
I recall discussions of Perl vs. PHP overhead that have occurred here in the forums and I don't think that I want to invoke an external Perl call for each page load. The http_post method mentioned previously seems to make a noticeable improvement in terms of delays/ page load times and I can simply include() this code. There is a syslog PHP function, although I don't see how it would be used to log page hits remotely (couldn't find good references). -Matt

[skolnick]

I'm not a PHP maven, but I would bet that the PHP syslog function implements an interface that lets you send messages to syslog for it to log, so you don't have to build your own logging function.

The cool thing--as a sysadmin, not a webmaster--is setting up syslog to log remotely. For example, I would imagine that Terra et al have all the individual web servers sending their log information to a single back-end machine to reduce the number of machines they have to log into to keep an eye on things (in fact I wouldn't be surprised if there are scripts that parse the data and make nice browser-based interfaces that change color as things change).

My point was more philosophical. If you had your own machine (a co-lo or dedicated server) you could configure the system syslog to log to your external machine instead of locally. In short I said "here is a cool solution that won't actually work for you because you don't own the machine." Sorry about that. <grin>