Make WordPress Core

Opened 16 years ago

Closed 15 years ago

#8590 closed defect (bug) (fixed)

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

Reported by: tin68's profile tin68 Owned by: denis-de-bernardy's profile Denis-de-Bernardy
Milestone: 2.8 Priority: normal
Severity: major Version: 2.7
Component: HTTP API Keywords: has-patch tested commit
Focuses: Cc:


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.


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

Attachments (4)

list_transports.php (647 bytes) - added by ryan 16 years ago.
List Transports plugin
8590.diff (529 bytes) - added by Denis-de-Bernardy 15 years ago.
8590-hooks.diff (1.3 KB) - added by Denis-de-Bernardy 15 years ago.
8590.2.diff (1.4 KB) - added by Denis-de-Bernardy 15 years ago.

Download all attachments as: .zip

Change History (46)

#1 @Viper007Bond
16 years ago

  • Milestone 2.8 deleted
  • Resolution set to invalid
  • Status changed from new to closed

Please make a thread on the support forums:

#3 follow-up: @tin68
16 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

Why is this report "invalid"?

#4 @mrmist
16 years ago

  • Priority changed from high to normal
  • Severity changed from major to normal
  • Version set to 2.7

#5 in reply to: ↑ 3 @Viper007Bond
16 years ago

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.

#6 @tin68
16 years ago

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.


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
Server IP:Port
Server Document Root /home/httpd/vhosts/
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

#7 @DD32
16 years ago

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() ) {
      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.

#8 @tin68
16 years ago

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.

#9 @DD32
16 years ago

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)

#10 @tin68
16 years ago

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.

#11 @DD32
16 years ago

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..)

#12 @DD32
16 years ago

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

#13 @DD32
16 years ago

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;


		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.

#14 @tin68
16 years ago

In the dashboard I get the message:

Requesting 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 using WP_Http_Curl took 4.001sWP_Http_Curl has failed with error:Operation timed out with 0 out of -1 bytes received Requesting using WP_Http_Curl took 3.002sWP_Http_Curl has failed with error:Operation timed out with 0 out of -1 bytes received Requesting using WP_Http_Curl took 2.998sWP_Http_Curl has failed with error:Operation timed out with 0 out of -1 bytes received Requesting using WP_Http_Curl took 3.029sWP_Http_Curl has failed with error:Operation timed out with 0 out of -1 bytes received

#15 @DD32
16 years ago

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: 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.

#16 @tin68
16 years ago

New http.php didn't help

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

#17 @tin68
16 years ago

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

#18 @tin68
16 years ago


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.

#19 @DD32
16 years ago

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.

#20 @lloydbudd
16 years ago

  • Milestone set to 2.8
  • Summary changed from Very slow after upgrade to 2.7 to Very slow after upgrade to 2.7 seemingly related to http.php transport

All open tickets should have a milestone.

#21 @jacobsantos
16 years ago

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.

#22 @pampfelimetten
16 years ago

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

#23 @tin68
16 years ago

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.

#24 @tin68
16 years ago

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...

#25 @popac
16 years ago

Host info:
CURL Information | libcurl/7.19.0 OpenSSL/0.9.7a zlib/ 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.

16 years ago

List Transports plugin

#26 @ryan
16 years ago

Attached plugin lists available transports in the admin footer.

#27 @ryan
16 years ago

  • Milestone changed from 2.8 to 2.7.1

#28 @tin68
16 years ago

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

#29 @tin68
16 years ago

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.

#30 @jacobsantos
16 years ago

You can disable Curl if you want.

#31 @JeremyVisser
16 years ago

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

#32 @minger
16 years ago

  • Component changed from Upgrade to HTTP

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."

#33 @eagano
15 years ago

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

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 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 (

#34 @tin68
15 years ago

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.

#35 @Denis-de-Bernardy
15 years ago

  • Keywords has-patch added
  • Milestone changed from 2.7.2 to 2.8

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.

#36 @Denis-de-Bernardy
15 years ago

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.

#37 @Denis-de-Bernardy
15 years ago

  • Severity changed from normal to major

#38 @Denis-de-Bernardy
15 years ago

  • Keywords needs-testing commit added

commit keyword is for 8590.diff.

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

#39 @ryan
15 years ago

_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.

#40 @Denis-de-Bernardy
15 years ago

  • Keywords needs-patch added; has-patch needs-testing commit removed
  • Owner set to Denis-de-Bernardy
  • Status changed from reopened to new
  1. will update this by tomorrow.

#41 @Denis-de-Bernardy
15 years ago

  • Keywords has-patch tested commit added; needs-patch removed

there you go

#42 @ryan
15 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.