[wp-hackers] Future Posting Fix Request

[Robert Deaton]

On 7/25/06, Computer Guru <computerguru at neosmart.net> wrote:
> Back to the topic at hand:
>
> (Damn, I hate CGI!!)
There is nothing wrong with CGI or FastCGI, it is my preferred SAPI of use.

> Nothing is unfixable, and there is always a solution.. but in this case, I guess it's possible the solution needs to come from the guys at Apache :'(

Unfortunately we can't wait for them.

> I don't understand why a user has to be there to bear the brunt of a ping-wait.. but here's another idea (yes, I'm determined)
>
> According to previous emails, what currently happens is the server GETs the page in question, and _it_ waits for the ping. That's the way it is on ISAPI php or non-CGI on Linux. But this doesn't work on CGI since servers can't wait or something like that...

No, the previous e-mails did not say that. Before you confuse yourself
more, let me paste some code.

  67  function spawn_cron() {
  68      if ( array_shift( array_keys( get_option( 'cron' ) ) ) > time() )
  69          return;
  70
  71      $cron_url = get_settings( 'siteurl' ) . '/wp-cron.php';
  72      $parts = parse_url( $cron_url );
  73
  74      $argyle = @ fsockopen( $parts['host'],
$_SERVER['SERVER_PORT'], $errno, $errstr, 0.01 );
  75      if ( $argyle )
  76          fputs( $argyle,
  77                "GET {$parts['path']}?check=" . md5(DB_PASS .
'187425') . " HTTP/1.0\r\n"
  78              . "Host: {$_SERVER['HTTP_HOST']}\r\n\r\n"
  79          );
  80  }

The important stuff here is lines 74-78, which open a socket with a
very short timeout to request the WP-cron file. In retrospect, the
timeout could possibly be increased just a hair, and it might help the
cron spawn more reliably under heavy loads, but anyways, the idea
behind this is the server requests the file and then the socket times
out, so that the user who is viewing the page that fired the cron
request doesn't have to wait. In the mean time, the wp-cron.php which
is requested does the heavy lifting, completely in the background.


> I don't understand this: you say the problem is that in a PHP-as-CGI setup, PHP files can't grab files off the local server and wait for the ping to go through.

Its PHP as CGI under apache. Every other environment I've tested has
worked well, including my personal favourite, PHP as FastCGI under
lighttpd.

> Fine. Do we have to do it via PHP? If we're doing it server-side, we can require that CGI users have perl or python or _something else_ installed, and spawn that instead... can't we?

No.

> After all, CGI is terrible anyway.
Don't base decisions just on this thread, the CGI/FastCGI PHP SAPI is
arguably the fastest and most secure way to run PHP there is.


> Or if you want to do it server-side but don't want users to wait, can't we use AJAX to do this sort of thing? If you use an image tag, technically
> 1) It's invalid HTML
> 2) The page won't finish loading until that's done.

This is why we also can't use an iframe or anything else, we're
putting unsuspecting users up for a potentially huge wait.

> But if you send the request to the ping RPC server via a standard AJAX data technique, wouldn't that completely solve the perceived wait time issue?

No. First, AJAX can't request to remote servers, so we still must
bounce through the local server and have it send the RPC pings on our
behalf. Secondly, while asynchroneous, you still get the illusion that
the page is not done loading, an undesirable sideeffect.


Also, it should be clarified that this problem is not to fix pings
alone. The cron facilities can be used by plugins to do anything they
want to do, especially if it is something CPU intensive that may take
a while. I personally have a mini-plugin that uses the cron facilities
to generate static statistics of what's happened over a week's time
period, and add that to static statistics of the overall time period,
and even minimal statistics reporting like this can cause some
undesirable waits that having the cron run in the background fixes.

-- 
--Robert Deaton