Posted 3 years ago #
Actually I found two versions of 2.7
One it's called "wordpress-2.7.zip" and it has 1.76 MB and 603 files, and the other one is called "wordpress-latest.zip, 1,83MB and 644 files.
The first one is faster, but not enough. The second one, is way slower.
It's so difficult for people who really know what changed from 2.6.5 to "debug" a little bit?
I made the modifications as found here: http://trac.wordpress.org/ticket/8590 (http.php file)
And now it's waaaaaaaaaaaaay waaaaaaaaay faster :D
Posted 3 years ago #
i tried this and it helps me, my upgraded install from 2.6.x to 2.7 is now fast as the old installation. here are my modifikations.
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.
http://www.gpunkt.at
Posted 3 years ago #
As suggested by DD32 in the discussion of ticket #8590, services that rely on external HTTP, such as pinging, are killed by this band aid solution. Meanwhile #8590 has been open a month and still has not been assigned to anyone.
Posted 3 years ago #
Not to be redundant, but I'm having a similar problem. Upgraded to 2.7 and after a few days, everything has gradually slowed down to the point where I have to refresh the page a few times in order to even get it loading (which in itself - takes a while).
I've tried disabling plugins and following the steps provided by @moses68 but no luck.
I've researched this extensively and many people are having the same issue. Here's my server info if it helps at all:
Apache version 2.0.63
PHP version 5.2.6
MySQL version 4.1.22-standard
Architecture i686
Operating system Linux
Kernel version 2.6.9-023stab044.11-enterprise
Thanks,
Posted 3 years ago #
I installed 2.7 a week ago. This was my first WordPress-installation, and I had high hopes. (BTW, I had to ask my web host to boost the php memory from 16 to 24 MB in order to get it installed.) Admin is indeed very slow: Sometimes it can take as "short" as 5-6 seconds to load a page, while sometimes it never loads at all.
But my homepage (i.e. the public pages) is also extremely slow. This is my main concern. It seems the "slowness" problem discussed here applies to the Admin pages, but I was wondering how many of you have problems with the public end as well?
Even though there is no immediate fix, it sometimes helps to know that I'm not alone :) I can only hope that people who know more about this kind of stuff than I, are able to pinpoint the problem and offer a solution.
Posted 3 years ago #
@yallaman - I'm having the same problem.
Alright, I talked with my provided and they upgraded my stuff to the following:
cPanel Version 11.24.4-CURRENT
cPanel Build 33098
Apache version 2.0.63
PHP version 5.2.8
MySQL version 4.1.22-standard
Architecture i686
Operating system Linux
Kernel version 2.6.9-023stab044.11-enterprise
cPanel Pro 1.0 (RC1)
And still no luck, pages are barely loading (admin and public).
Thanks,
Posted 3 years ago #
Disabling http-access, like described by moses68, helped me. WP seems to run as expected. Thank you.
http://wordpress.org/support/topic/224410/page/3?replies=67#post-947263
Posted 3 years ago #
Alright, I tried the http.php hack again and after a little while the performance seemed to have increased to normal.
However, is anyone aware of the consequences from disabling all external HTTP access?
Posted 3 years ago #
> However, is anyone aware of the consequences from disabling all external HTTP access?
"As suggested by DD32 in the discussion of ticket #8590, services that rely on external HTTP, such as pinging, are killed by this band aid solution. Meanwhile #8590 has been open a month and still has not been assigned to anyone. "
For example, the sitexml plugin can no longer ping google, etc. when your posts have changed with the band aid solution.
Posted 3 years ago #
Hi,
I had a similar problem with the Upgrade to 2.7 or a Fresh Install on 2.7 appearing to run "slow" - pages would not load at all it seemed.
Remembered a similar problem with my hosting provider from many moons ago and realised it might be a similar thing.
My hosting provider's (Supanames) firewall prevents PHP using fopen wrappers to http connections outside the firewall unless you specifically request domains that your site is allowed to connect to. Not sure if this is a problem with anyone else, but as soon as I hacked http.php it works fine.
My guess is something changed in the 2.7 code to use a different method of calling external URL's - when this is done on my hosting, it just hangs and never times out or anything.
Anyway, hope this helps some people even though it's a long way down the list.
And just to add my 2c - as WordPress is used on a huge number of servers, the server setup's may be a problem, but WordPress maybe needs to take this into account a bit more so list mod's stop throwing their toys out of the pram every time someone takes a poke at WordPress because they are frustrated that their apparently easy to upgrade / install piece of software does not work. Just because its OS does not mean it's not subject to quality standards. The base quality standard being "does it work for me"?
Later.
Ski
Posted 3 years ago #
@Minger
I am surprised, too that my bugreport seems not to be accepted as bug. But you could read in the first comments of the report - I was told that "slownessis not a bug" - and the bug report was closed very fast. I reopened it and DD32 gave some hints and the hack. I am quite disappointed as well.
Posted 3 years ago #
Further investigation into this problem has shown up fopen with URL wrappers to be causing the problem.
This only seems to occur with PHP 4 on my hosting package - if I switch to PHP 5 it all seems to work. With PHP 4 - the only transport I have available is fopen, which means that the system will bomb if I allow it to use this...
I can now use http.php, after commenting out the option for checking WP_Http_Fopen::test() in the file - around line 103 in the _getTransport function - I could hack the test a bit rather than this function, but you get the picture: If a transport is messing you around - comment it out, or comment them all out then uncomment 1 by 1 until you find the culprit.
Now I can still use http methods and don't have to "return" at the top of the request function. (PHP 5)
The WP_Http_Fopen::test() only tests for allow_url_fopen - which is valid, but on my hosting, there is no way of testing if a URL is blocked by the firewall. Not sure about the slowness of Curl, but this works fine. One thing I have noticed after adding debug into the request code is that the dashboard page makes 4 requests to the same URL so if 1 call is slow, then the others maybe slow too. I know that the dashboard is a modular thing, but hey couldn't WP cache the results of these requests or something so that the returned data could be reused...
1. I would recommend allowing users to select which transports to use in order to override the system - it's alright checking, but because of the issues with external library versions, etc. It might be nice to allow people to tweak the settings to suit them.
2. If you are not caching the URL requests offsite, please do, or make it a lot easier to turn them off...
Thanks
skila
I would recommend allowing users to select which transports to use in order to override the system - it's alright checking, but because of the issues with external library versions, etc. It might be nice to allow people to tweak the settings to suit them.
There is a way to do this, it's just not easy/obvious.
Examine this code:
function block_transport() { return false; }
add_filter('use_http_extension_transport', 'block_transport');
add_filter('use_curl_transport', 'block_transport');
add_filter('use_streams_transport', 'block_transport');
add_filter('use_fopen_transport', 'block_transport');
add_filter('use_fsockopen_transport', 'block_transport');That blocks all the http transports. If you know which transport you wish to use, to the exclusion of the others, then you can simply remove that line and voila, it's not blocked and will be used (if it is detected as available in the first place, of course). Just add this code to your theme's functions.php file, or to a plugin or something.
hey couldn't WP cache the results of these requests or something so that the returned data could be reused...
The various RSS feeds read by the dashboard are indeed cached, in the database, for up to 1 hour.
Posted 3 years ago #
Cool - thanks for the tip on the blocking...
"The various RSS feeds read by the dashboard are indeed cached, in the database, for up to 1 hour."
I am not sure if that is true for my system: when I put in debug in the WP_Http request function to see what is happening where I see the same URL being requested 4 times in the dashboard, surely if the results are cached in the database, then these request would not occur. Is caching turned on by default or not?
Thanks
skila
The http stuff doesn't do any caching at all. If you tell it to make an http request, then it makes an http request. The feed caching is higher level than that, it happens in the rss reader.
Sometimes you want it to cache, sometimes you don't. Caching is therefore outside the scope of the http api.
Also note that if it didn't get anything for the feed, then it won't be caching the feed and so will try to get it again.
Posted 3 years ago #
@tin68
Thanks for reopening the ticket. Seems like Viper007bond wanted more specificity, which is fair. The problem is seen, in my testing and @skila reports, with fresh installs too, so I changed the component on the ticket from "upgrade" to "http." Hopefully that will garner the ticket more respect.
@skila
I am seeing the problem with php5; I'm not using php4.
$ apache2 -M
reports
php5_module (shared)
Posted 3 years ago #
Hi,
I made upgrade WP2.6.5 to 2.7 and now I have problem with slow page loading - it takes 60 seconds. I installed WP Tuner plugin and I see problem with widgets_init load time:
Page Generation Performance:
marker: widgets_init time: 60,013.0ms (= 60sec)
I installed new blank version of WP2.7 and I have the same problem with load time of widgets_init.
Thanks for your help
Paul
Posted 3 years ago #
Just a note: Sometimes my (public) web page doesn't load at all (original post). In these cases, my browser reports the following:
"No suitable nodes are available to serve your request."
I'm not sure if this might be a clue ...
Posted 3 years ago #
For those experiencing a slow dashboard in 2.7, try deleting all your spam comments. This causes the "Recent Comments" box to load much more quickly.
Posted 3 years ago #
I'm experiencing this problem on a new WP2.7 install. The server also has a WP2.5 and a WP2.6.1 install, neither of which are affected.
Disabling the request() function in http.php with a return as described works around the problem with the mentioned loss of features.
There are two servers which are identical configurations, both produce the problem.
Debian GNU/Linux 4.0 (etch)
Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8+etch13 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_perl/2.0.2 Perl/v5.8.8
Linux web01 2.6.18-6-686 #1 SMP Fri Dec 12 16:48:28 UTC 2008 i686 GNU/Linux
curl 7.15.5-1etch1
Posted 3 years ago #
For the record, backporting and installing the latest libcurl3 (7.18.2-8) from Debian lenny does not resolve the problems with request(). This is the same upstream release of libcurl3 that is in Ubuntu Intrepid.
Posted 3 years ago #
If the reported and documented slowness of both the admin pages and the public pages made with WP 2.7 continues to be regarded as a server-only problem, then this matter will never be resolved.
I have a fresh install, no plugins, no spam comments etc. etc. Sometimes the site works ok, sometimes it hangs forever. Too bad, as I really liked the features of WP and was looking forward to using it on my website. Several colleagues of mine (with lots of experience with WP, Joomla etc.) had to downgrade to a previous version, as they found the slowness unacceptable. Still, I hope the problem will be resolved somehow :)
Posted 3 years ago #
One thing that might cause "slowness" on some requests is if your server is behind a NAT and you don't make sure that the server is able to resolve the sites dns to a ip it could actually connect to.
Since the server, behind the NAT, can't connect it self using the "internet ip" your DNS records points to, request to the server itself will fail which might result in rather long timeouts.
This will happen whenever WordPress decides to call wp-cron.php to do some task, and even though the read-timeout for the wp-cron.php connection seems to be very low (something like 0.01s), the fact that the "internet ip" can not be connected at all seems to cause rather long timeouts.
I'm sure there is other situations where this might be an issue too, but the wp-cron-connection was the first and only I encountered.
The easiest way to fix it (if you've full system access) is probably to throw in a line pointing your domain to 127.0.0.1 in your servers hosts-file.
Posted 3 years ago #
I'm new to WordPress so version 2.7 is the first version that I've ever installed. I noticed that WordPress was significantly slower compared to any other applications that get served off of my local development machine. My local development machine is:
Windows XP
Apache 2.2.4
PHP Version 5.2.3 (running as CGI/FastCGI)
MySQL 4 using INNODB Storage Engine
So I looked in Apache's error log and quickly noticed that for every page request from WordPress there were 4 of the following errors:
Error in my_thread_global_end(): 1 threads didn’t exit
To which I then started googling and came up with the following threads which offered up solutions that fixed the slowness of my WordPress 2.7 installation.
Solution 1:
Original Discussion Here
...I think its because wordpress does not know where your blog files are located. Go to your blog settings and edit the WordPress Address (URL) and change it to wherever your blog url is then hit the Save Changes button.
Solution 2:
Original Discussion Here
This error is actually a bug in the latter PHP/MySQL release, which is generated when the MySQL's InnoDB database storage engine's connection handlers while exiting properly did not decrement the server's thread count. It can be fixed easily by changing/switching the PHP Server API from CGI/FastCGI to ISAPI.Or if you want to use CGI/FastCGI PHP Server API, you can do the following to get this sorted out permanently:
1) Go to the directory where PHP is installed
2) Rename libmysql.dll to libmysql.bad
3) Download the PHP 5.2.1 binary from here and extract it to a temp folder
4) Copy the libmysql.dll from this folder to the PHP installation directory
5) Finally restart the web server to reflect the changes
So if the cause of your slowness is caused by a PHP and MySQL error on my_thread_global_end(), then hopefully these solutions should help bring your blog back up to tolerable speeds.
Posted 2 years ago #
I've been watching this topic for a couple of weeks, trying every solution that was suggested, but nothing has helped. I have a number of WordPress blogs running 2.7 and it sometimes takes between 10 and 30 seconds for them to load the main page.
I'm running on the grid server at MediaTemple.net, with Apache 2.0.54, PHP 5.2.6, MySQL 4.1.11, and libcurl 7.13.2 on Debian GNU/Linux 4.0 2.6.20.2-1.
I was hoping that 2.7.1 would fix it, but I just installed it and it still loads abominably slow.
Any ideas?
Posted 2 years ago #
guess what I'm having the same problem…
is there some official statement from wordpress regarding this problem by now?
Posted 2 years ago #
hmmm... curious too, watching this closely because i'm having a "slow" issue as well.
-peter
Posted 2 years ago #
Installing Disable WordPress Core Update and Disable WordPress Plugin Updates helped a lot, but it's still much slower then before the update to 2.7.
Posted 2 years ago #
Make sure the .htaccess file was installed with this :
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
It saved me...
Posted 2 years ago #
You can add me to the list of slow admin folks. The site loads fine, but whenever I save or update anything on the admin side, it sits "waiting for server" for about 60 seconds. Gears doesn't really help (though once the page gets past the "waiting for server" stage, it loads more quickly). It's not a plugin thing and happens both on a fresh install and an upgrade from 2.6. It happens in Safari, firefox 3, and firefox 2. I'll probably install wp-super-cache and wp-tuner, but I suspect they'll just confirm what other people have found.
I'm about to implement the php hack suggested to see if that helps, but wanted to ask: This hack disables the pinging, but are there any other important functions you lose? Also is there a way to manually ping the necessary servers on update (I know there is, I'm just not sure how to go about it)? I know it's not the most desirable solution to the problem, but it's driving me crazy to try to tweak a new website design and sit for a minute or so waiting to see if I need to adjust the layout again and again. Once I get out of the designing phase, I'll probably undo the hack since the page is mostly static.
Thanks,
Matt
This topic has been closed to new replies.
