After upgrade to 2.7 – very slow

Thanks to splivblaster!!! His confirmation of the .htaccess file contents totally fixed the slowness I’ve been experiencing with 2.7.1. My host is MediaTemple. I’m running: PHP Version 5.2.6, MySQL 4.1.25

Added the text below to my .htaccess and the site (https://ellawest.com) is as snappy as it was with 2.6.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

My WP 2.7.1 already had that code in the.htaccess file.

I’ve even removed my Cache plug-in now and it seems to be running better. This is ridiculous. Any way to downgrade??

UPDATE TO MY COMMENT ABOVE:

After modifying my htaccess with the above entries, the admin tool was fast again, but I noticed that my main site was was actually slower and would almost hang on loading (especially after clearing my browser cache).

After further investigation (using tamper data in FireFox), the rewrite rule above was appending a forward slash to my image assets. This didn’t make sense as to why it was happening, and I even explicitly added another rule to ignore the images files, but a trailing slash was still appended.

This was causing my sites root index.php to be loaded for every image that was being called!

After no success modifying the htaccess to stop appending the trailing slash, I moved the file into the wp-admin directory.

After doing this, my admin tool continued to load quickly, and image assets loaded normally with no forward slash being appended.

Going to try this for awhile and if I see any other issues, I’ll post back here.

Hopefully this helps someone else.

I just don’t understand. There is an obvious bug with the new version. There is no other explanation as to why the previous version worked smooth while the update is slow.

Anyone know when 2.7.2 is coming out?…because I have tried more than a dozen different combinations of plug-ins, scripts and optimization with absolutely zero improvement.

I too have a very slow admin panel, installing Google Gears improved the speed dramatically, but that doesn’t help when I’m not at home and trying to approve comments or such from my phone or another computer, there has to be something wrong with the code that causes it to load so ridiculously slow that it causes my browser to timeout. Every other site and script I have ever run on my server works fine, with much bigger databases and far more visitors. Even the blog itself loads fine, there must specifically be something wrong with the admin panel itself that causes it to load so slowly. Even if my server was to blame, it would cause all sites/scripts to be slow, not just the admin panel. There is also no script conflicts, all sites are setup separately from each other and have their own completely separate MySQL databases.

If it is just the fact that the new Admin Panel is just really really slow due to all the random stuff they’ve thrown into it, there really needs to be some sort of lightweight alternative that people can use, even Google Gears doesn’t fix everything.

So I checked to see if curl was available on my server (“curl –version” at the prompt) and it is (7.18.0), but it wasn’t enable by default, so I edited php.ini to include the line:
extension=curl.so
(it was there, but commented out with a semicolon). Now my load times are similar to when I hacked the php to disable the curl. It’s still 30s for me, but that’s better than 120+s, which is what it was before.

yeah this is borderline ridiculous.
seems like so many people are having this issue yet i don’t see anyone from the wordpress side of things owning up to anything?

i hate to have to downgrade but i’m almost being forced to. i can’t wait 2 minutes for my admin dashboard to load.

and none of these “temp hacks” seem to work for me.

ARGHHH!

It’s me who started this thread and I am “happy” to see that I am not alone with this problem.

My temporar solution: WP-Super Cache and Google Gears. It’s not fast, but it’s usable.

Yup. 2.7 is slow. Of course, we will all be told that it’s our host’s problem, or that our code is crap, etc… but the fact is that many users are experiencing a lot of slowness with 2.7 after upping from 2.6, regardless of host, it seems, as I’ve seen a lot of host names put up here by everyone. modifying .htaccess, installing numerous speed plugins and more still isn’t enough – even a fresh, totally blank WP 2.7 install is slow, and I’ve tried this on three hosts now, all of which (I believe) are “suggested” by WP: godaddy, bluehost, and dreamhost. Slow in all instances.

So, either we’re all crazy (which we’ll be accused of), or indeed, something is not talking right. The latter is the case – no one’s being judgemental, WP guys, we love what you do – but we’re stating here and now that the extra java usage in the WP admin panel, as well as how WP seems to be handling php and other issues, is causing some serious slowdown.

Here’s the main problem: Saying that it’s “slow” is not helpful. What is slow? Details, people. “Slow” is a symptom, not a cause. We can’t fix symptoms.

FWIW, 2.7.1 is not visibly any slower to me than any previous version on any of the sites I’ve updated. So I can’t reproduce your problem without somebody telling me more information. What is slow? What exactly is the problem on your particular machine that makes 2.7 slower than 2.6 was? In at least one case in this thread, most of the problem seemed to be a server with some strange configuration of curl. Have you tried that? Have you tried anything other than complaining about it?

See, chiming in with a problem is useless unless you can give a reason for the problem as well, because all it does is add a useless “me too” to the thread. Not very helpful to the people writing the code.

BTW: It’s not any slower on GoDaddy than it was previously, because I have several sites on there where it runs just fine. It helps if you set them to use the PHP 5 configuration, BTW, their PHP 4 config is somewhat broken in certain respects. And their shared hosting is dog-slow to begin with, the dedicated hosting is much spiffier and quick.

hey otto-

i’ve changed ABSOLUTELY nothing aside from going from 2.7 to 2.71 on my own server. (my server runs win2003 server and WAMP)

and the admin section completely slowed down to a crawl.
like i said i did nothing else. i didn’t install any other plugins, change any files or anything.

so how can i explain that it works like this now?

i then proceeded to remove all my plugins and it didn’t help at all in the admin section.

the main site works fine, but the admin is almost unusable.

so what do i do?

so what do i do?

Well, first, I’d say to figure out what the problem is, and then tell us that. Once we know the problem, then we can create a fix.

I can’t diagnose your server, because I’m not the one using your server. Telling me that it got slower from 2.7 to 2.7.1 doesn’t really help any. That’s a symptom. Not a cause.

Ok, since the last time I wrote I have been trying to narrow down the problem. It is still really slow, and not just in the admin section, my blog homepage sometimes takes 30 – 40 seconds to load. I did some timing on the sql queries being executed by WordPress 2.7 and the database is not the problem all the queries run extremely fast.

Like I said in my last post, I have tried all of the suggestions in thread, including those related to curl and enabling and disabling various transports with no change.

I’m still trying to identify the specific section of the code that is causing this, but here is one clue that I discovered while reviewing my site statistics:

The wp-chron.php appears to be the most requested file on my site. I’m continuing to investigate it.

Does your site have the ability to resolve its own name, or make an http request back to itself? That’s not a new issue for many people, and is well known.

Servers must have working DNS and be able to resolve themselves as well as being able to make http connections to that address for wp-cron to function properly. Some servers have had this sort of thing intentionally disabled, in a misguided (and fundamentally incorrect) attempt at “security”.