[wp-trac] [WordPress Trac] #18738: Improving cron spawning and other non-blocking HTTP requests

WordPress Trac wp-trac at lists.automattic.com
Wed Sep 21 17:03:50 UTC 2011


#18738: Improving cron spawning and other non-blocking HTTP requests
-------------------------+-----------------------------
 Reporter:  johnbillion  |      Owner:
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  HTTP         |    Version:
 Severity:  normal       |   Keywords:
-------------------------+-----------------------------
 The order of preference for transport methods in the HTTP API is cURL,
 streams, fsockopen. However cURL and streams cannot perform non-blocking
 requests, but fsockopen can. Therefore, fsockopen should be the highest
 priority transport method for non-blocking HTTP requests.

 Here's an example. I have a script at `http://ctftw.com/sleep.php` which
 sleeps for 5 seconds.
 {{{
 $start = microtime( true );
 wp_remote_get( 'http://ctftw.com/sleep.php', array(
         'blocking' => false
 ) );
 $end = microtime( true );
 var_dump( $end - $start );
 }}}
 When the cURL or streams transports are used, this request blocks the page
 for 5 seconds (the default request timeout is 5 seconds).

 Let's disable the cURL and streams transports (leaving only fsockopen) and
 try again:
 {{{
 add_filter( 'use_curl_transport',    '__return_false' );
 add_filter( 'use_streams_transport', '__return_false' );

 $start = microtime( true );
 wp_remote_get( 'http://ctftw.com/sleep.php', array(
         'blocking' => false
 ) );
 $end = microtime( true );
 var_dump( $end - $start );
 }}}
 This request does not block the page because fsockopen returns immediately
 after sending the request.

 == Cron Spawning ==

 This is a benefit to core because it improves the cron spawner (and can
 potentially fix #8923). The cron spawner uses a timeout of 0.01 seconds
 and a non-blocking request, but actually takes longer than 0.01 seconds.

 Example:
 {{{
 $cron_url = get_option( 'siteurl' ) . '/wp-cron.php?doing_wp_cron';
 $start = microtime( true );
 wp_remote_post( $cron_url, array(
         'timeout' => 0.01,
         'blocking' => false
 ) );
 $end = microtime( true );
 var_dump( $end - $start );
 }}}
 This request takes around 1.1 seconds on the three servers I've tested it
 on.

 Let's disable cURL and streams again (leaving only fsockopen) and see what
 we get:
 {{{
 add_filter( 'use_curl_transport',    '__return_false' );
 add_filter( 'use_streams_transport', '__return_false' );

 $cron_url = get_option( 'siteurl' ) . '/wp-cron.php?doing_wp_cron';
 $start = microtime( true );
 wp_remote_post( $cron_url, array(
         'timeout' => 0.01,
         'blocking' => false
 ) );
 $end = microtime( true );
 var_dump( $end - $start );
 }}}
 On each of my three servers I see a time of around 0.001 seconds.

 We can therefore improve the cron spawner by setting fsockopen as the
 preferred transport method for non-blocking HTTP requests.

 In an attempt to address #8923, we can change the cron request timeout to
 1 second. If fsockopen is used, the request is lightning fast at ~0.001
 seconds. If it's not available and the HTTP API falls back to cURL or
 streams then it takes ~1.1 second, which is the same time it takes
 currently. (Hopefully that makes sense.)

 Patch coming up for those who want to test it.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/18738>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list