Very slow after upgrade to 2.7 seemingly related to http.php transport

[tin68]

I upgraded WP 2.6.5 to 2.7 - everything seemed to work well - plugins as well.

But loading pages is now very slow - to load the first page takes more than 5 up to 8 seconds. Before with version 2.6.5 it was about 1 second.

I installed on the same server a fresh new WP 2.7 - without any plugins, Kubrik default theme and the default first message (Hello World).

To load the first page takes more than 4 seconds.

Server-Info:

PHP Version 5.1.6
Apache/2.0.46 (Red Hat)
MySQL Client API version 4.1.18

[Viper007Bond]

Please make a thread on the support forums: ​http://wordpress.org/support/

[MichaelH]

Cross referencing:

​http://wordpress.org/support/topic/224595

​http://wordpress.org/support/topic/224410

[tin68]

Why is this report "invalid"?

[Viper007Bond]

Replying to tin68:

Why is this report "invalid"?

Because slowness in itself isn't a bug. Whatever's causing the slowness may be, but that may or may not be WordPress' fault (for example, an improper server configuration has been known to cause this as well). That's why I suggested the forums. Once it's determined (via the support forums) what's causing the slowness and if it is WordPress at fault, then by all means a ticket is in order. For now though, there's nothing to go on.

[tin68]

The situation is now "perfect" - or with other words: blocked.

You say that there must something wrong with the server. Ok I talked to my provider and he says that there must something wrong with Wordpress.

Super!

BTW. Server Information

OS Linux
Server Apache/2.0.46 (Red Hat)
PHP v5.1.6
MYSQL v4.1.18
GD bundled (2.0.28 compatible)
Server Hostname www.blogkom.net
Server IP:Port 80.74.149.31:80
Server Document Root /home/httpd/vhosts/blogkom.net/httpdocs
Server Load 10:47:53 up 3 days, 17:02, 0 users, load average: 0.86, 0.81, 0.66 0.86
Server Date/Time 15. Dezember 2008 @ 11:47
Database Data Disk Usage 14.1 MiB
Database Index Disk Usage 1.6 MiB
MYSQL Maximum Packet Size 1,024.0 KiB
MYSQL Maximum No. Connection 700
PHP Short Tag On
PHP Safe Mode Off
PHP Magic Quotes GPC On
PHP Memory Limit 64.0 MiB
PHP Max Upload Size 25.0 MiB
PHP Max Post Size 8.0 MiB
PHP Max Script Execute Time 30s

[DD32]

tin68: Are you getting plugin update notices at all? I'm just wondering if it could be related to external HTTP requests. It will be a conflict between WordPress and your hosting environment, It could be a bug in WordPress, or it could be a oddity in the way your host has PHP set up, Its a bit hard to tell which without testing.

Try disabling all external HTTP access:

1. /wp-includes/http.php
2. this on about line 210:

   function request( $url, $args = array() ) {
     global $wp_version;
   

3. Change it to:

   function request( $url, $args = array() ) {
     return;
     global $wp_version;
   

4. Save the file and upload to your host, Open the admin again and see how things fair, Report back on if its helped or not.

[tin68]

We are on the way to find it - great!

Loading time of the first page of Wordpress 2.7 with several plugins enabled: 2.6 seconds - quit faster than before!

Loading time of the first page of Wordpress 2.7 without any plugins and default theme - 1.2 second.

[DD32]

tin68: I assume that was after you disabled the requests? How long was it taking before?

By disabling the HTTP requests you loose Cron(which means no pinging of sites, and various other items), Plugin updates/install/core updates/upgrade, etc, so theres a few things that hang off it.

Ryan posted up a plugin at some stage which listed the transports in use for the HTTP API, If someone see's this comment, can they post a link up to it? I cant find it right now (And dont feel like re-inventing the wheel)

[tin68]

Before your suggested change to http.php the loading time was 5 to 7 seconds.

What are the requirements for the server that the default http.php runs without this big delay? BTW I installed an other WP 2.7 (without any plugins and default theme) on an other server without these delay.

[DD32]

What are the requirements for the server that the default http.php runs without this big delay?

There's a range of options, It was designed to run on most server configurations, and has a lot of issues to work around.

Ok, Lets try to work out whats causing it then.

Remove the 'return;' line from the previous item, and add this:

echo "Requesting $url using " . implode(', ', $transports);

just before this: (around line 260)

$response = array( 'headers' => array(), 'body' => '', 'response' => array('code', 'message') );
foreach( (array) $transports as $transport ) {

That should narrow which request is causing the slowness, and which transport is being used (well, At least the prefered item to use), You might also want to change:

    if( !is_wp_error($response) )
                return $response;
	        }

(around line 265)
to read:

    if( !is_wp_error($response) )
	                return $response;
echo "$transport failed with error:" . $response->get_error_message();
	        }

To see if the default transport is failing for you, and WordPress isnt realising (Which could cause delays.. but hopefully not too long..)

[DD32]

wait, sorry, those code examples were wrong.. Let me actually test it this time..

[DD32]

Ok, Change the codeblock:

		$response = array( 'headers' => array(), 'body' => '', 'response' => array('code', 'message') );
		foreach( (array) $transports as $transport ) {
			$response = $transport->request($url, $r);

			if( !is_wp_error($response) )
				return $response;
		}

to:

		if(is_admin()) echo " Requesting $url using " . implode(', ', $c = array_map('get_class', $transports));
		$response = array( 'headers' => array(), 'body' => '', 'response' => array('code', 'message') );
		foreach( (array) $transports as $transport ) {
			$timer_http = timer_start();
			$response = $transport->request($url, $r);
			if(is_admin()) echo ' took ' . timer_stop(0) . 's';
			if( !is_wp_error($response) )
				return $response;
			if(is_admin()) echo get_class($transport) . ' has failed with error:' . $response->get_error_message();
		}

the if(is_admin()) is just there so as not to show it on the public side of the blog.

[tin68]

In the dashboard I get the message:

Requesting ​http://api.wordpress.org/core/version-check/1.3/?version=2.7&php=5.1.6&locale=de_DE&mysql=4.1.18&local_package= using WP_Http_Curl took 4.001sWP_Http_Curl has failed with error:Operation timed out with 0 out of -1 bytes received

In the plugin news window on dashboard I get:

Requesting ​http://api.wordpress.org/core/version-check/1.3/?version=2.7&php=5.1.6&locale=de_DE&mysql=4.1.18&local_package= using WP_Http_Curl took 4.001sWP_Http_Curl has failed with error:Operation timed out with 0 out of -1 bytes received Requesting ​http://wordpress.org/extend/plugins/rss/browse/popular/ using WP_Http_Curl took 3.002sWP_Http_Curl has failed with error:Operation timed out with 0 out of -1 bytes received Requesting ​http://wordpress.org/extend/plugins/rss/browse/new/ using WP_Http_Curl took 2.998sWP_Http_Curl has failed with error:Operation timed out with 0 out of -1 bytes received Requesting ​http://wordpress.org/extend/plugins/rss/browse/updated/ using WP_Http_Curl took 3.029sWP_Http_Curl has failed with error:Operation timed out with 0 out of -1 bytes received

[DD32]

Hm.. I dont think its likely, But try the latest version of the http.php file, it includes a change for hosts which disable Curl in odd ways: ​http://trac.wordpress.org/export/10204/branches/2.7/wp-includes/http.php I dont think thats your problem, but its worth checking since you're using the Curl transport.

If the new file doesnt help, try disabling curl

About line 1060 you'll find:

	function test() {
		if ( function_exists('curl_init') && function_exists('curl_exec') )
			return true;

		return false;
	}

change it to:

	function test() {
		return false;
		if ( function_exists('curl_init') && function_exists('curl_exec') )
			return true;

		return false;
	}

That'll cause it not to use Curl, and instead, it'll use the next available transport.

[tin68]

New http.php didn't help

Hmm - what is the difference between the two code lines?

[tin68]

Oops, sorry - false question... ;-)

[tin68]

Result:

New http.php with your patch - WP 2.7 with plugins - loading time first page: Core files 1.6 - but then it takes long to load other elements eg. pictures, external links - in total 12 seconds.

WP 2.7 new installation, without any plugins, default theme - loading time first page: 1.6s

BTW. With this patch the other problem went away - I can update plugins now automatically - before this ended with an error message.

[DD32]

Well, Seems curl could be unusable on your host, Not sure why, realistically, if Curl failed, you'd expect the others to fail too. But that just isnt the case. Perhaps you could contact your host and ask if Curl is enabled, Mention that once you changed WordPress from using Curl, to using fopen() the performance issues went away.

The only way to resolve this ticket will be to workout why curl doesnt work on your host, But i'm not expecting [the host] to give a reason for it not working, You might be one of the people who needs to install a plugin to disable the Curl transport in order for WP to work as intended.

I opened #8622 to deal with fallover to other transports if one fails, and that would fix the non-working requests for you, but could also increase the delays on loading.

[lloydbudd]

All open tickets should have a milestone.

[jacobsantos]

Part of the reason the filters are in place is to allow for removing transports in the unlikely (at the time) event that the user doesn't want to use that transport or it fails.

[pampfelimetten]

same problem here, inserting the return in http.php works for me.
Server Info:
Current WordPress version 2.7
Server operating system Linux
Current version of PHP PHP 5.2.0-8+etch13
Current version of MySQL MySQL 5.0.32-Debian_7etch8-log
Webserver software Apache/2.2.3 (Debian) DAV/2 PHP/5.2.0-8+etch13 mod_ssl/2.2.3 OpenSSL/0.9.8c

[tin68]

As far as I see in the phpinfo curl is enabled - but it seems to be a very old version:

libcurl/7.10.6 OpenSSL/0.9.7a ipv6 zlib/1.1.4

I sent a message to my provider about found problems with curl - but I didn't got an answer yet.

[tin68]

I asked the provider if he could update this very old version - the only answer I got: This version is a patched version to handle a lot of file descriptors... I don't know but perhaps the curl problems we have are coming from this patch...?

Well, I am quite disappointed about my provider - seems that he is not very interested to help...

[popac]

Host info:
CURL Information | libcurl/7.19.0 OpenSSL/0.9.7a zlib/1.2.1.2 libidn/0.5.6

---

I think that problem isn't in http.php...
I try all from this tread but posting is verrrrryyy slow...ultra slow. WP Super Cache for example not a problem...tested.

When I want to edit some post, updating is fast, like in 2.6.5.

Maybe problem is autosave ? Don't like this option and in my installation is disabled.

Still waiting for solution.

[ryan]

List Transports plugin

[ryan]

Attached plugin lists available transports in the admin footer.

[tin68]

Sorry about my silly question: In which folder list_transports.php has to be uploaded?

[tin68]

Sorry - found it - of course "plugins".

My information about my very special server now with this plugin:

Available transports: Curl Streams Fopen Fsockopen

Still quite strange - but Curl seems not to work correctly.

[jacobsantos]

You can disable Curl if you want.

[JeremyVisser]

tin68 -- can I emphasise what Viper said before: this is exactly the discussion you should be having on the forums, not the bug tracker.

[minger]

The slowness of release 2.7 is seen with fresh installations, not only with upgrades. "Component" should thus not be Upgrade. As http.php is implicated, component should be "HTTP."

[eagano]

I had this same problem on Debian. While curl was installed on the system, the PHP cURL module was not.

Debian:
apt-get install php5-curl
/etc/init.d/apache2 restart

This solved my performance problems. Without the PHP cURL libraries it must have been falling back on something much slower, likely fsock.

From my phpinfo() after the PHP cURL install:
curl
cURL support enabled
cURL Information libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5

I am guessing that there is a similar RPM for RedHat based distros (

[tin68]

If WP is running on a hosted server where you don't have root access and the provider doesn't accept to update libcurl - no chance.

[Denis-de-Bernardy]

to me, this has more to do with a workflow error than anything else.

when the response fails, WP should store a valid response that signals no updates, including the version_checked, and try again later. as things currently are, it tries again on every page load because of _maybe_update_core().

Patch attached.

[Denis-de-Bernardy]

second patch needs testing. it moves the call to _maybe_update_core to shutdown, rather than init, on non-admin pages, so that this doesn't interfere with front-end page loads.

[Denis-de-Bernardy]

commit keyword is for 8590.diff.

8590-hooks.diff is presumably harmless, but could use a few tests.

[ryan]

_maybe_update_core() should probably be moved to admin_init and have a cron entry scheduled. That will remove all cases where we try to check for updates on a front page load.

[Denis-de-Bernardy]

11. will update this by tomorrow.

[Denis-de-Bernardy]

there you go

[ryan]

(In [11209]) Don't do core version check from front page loads. Props Denis-de-Bernardy. fixes #8590