Pings affect admin load times

[skeltoac]

My testing showed that JS is delayed until all iframes are loaded. This can take several seconds when there is even a small number of pings to execute. No header manipulation was successful at reducing the load time.

Here's a patch. It removes the iframe and runs execute-pings.php asynchronously by calling fsockopen with a timeout of 0.01. This is done by a function spawn_pinger that is called within wp_insert_post() and only when post_status=='publish' and pings are on.

An added benefit is that spawn_pinger will be called for all post saves and edits, including bookmarklet, sidebar and xmlrpc. Previously, any posts published or edited via these methods would not be pinged until someone with the authority to edit those posts logged in and used the admin screens.

It also fixes a bug: an attempt to repeat a trackback would cause that url to remain in to_ping indefinitely. It also trims to_ping after each update to eliminate unused spaces.

[matt]

​http://www.mikeindustries.com/blog/archive/2004/09/sifr2-kick-the-tires

Perhaps instead of onload we should have a script block called in the footer action. (This is for TinyMCE too.)

I'm not crazy about the fsockopen call, I still think we should be able to do this async in JS. Wouldn't we need a stream_set_timeout() anyway in the PHP? We've run into bugs before with how gzip and buffers interact and that holding up loads.

[skeltoac]

The fsockopen call mimics the one in the IXR_Client object used for pingbacks, as well as the one in our own trackback() function. So if the fsockopen call in spawn_pinger() doesn't work on a server, pingbacks and trackbacks are already broken on that server. It does not introduce any new dependencies.

The timeout is set to 0.01 seconds in the fsockopen call so it doesn't wait. I tested this with 30 pings at a time and had 100% of the pings arrive at their destinations. My admin page routinely completed loading before the third ping arrived from the spawned process.

It might be trivial, but it might be good to add an fclose() after the fput().

Involving the user agent in the process is unnecessary. Also, if you depend on JS to do spawn the ping processor, I think you have to list JS among the requirements.

Regarding optimizing the JS, we already have and use addLoadEvent(). We could use that to register functions to be fired by a sort of hook in the footer. I'll open a new ticket for that.

[ryan]

(In [3317]) New asyncronous ping method. fixes #2048

[(none)]

Milestone 2.0 deleted