WordPress.org

Ready to get started?Download WordPress

Forums

After upgrade to 2.7 - very slow (148 posts)

  1. Samuel Wood (Otto)
    Tech Ninja
    Posted 5 years ago #

    First step to solving wp-cron related issues is to look in the database for the "cron" option, in the options table. What is the value associated with that option? In general, it should be empty. If it's getting filled up, then wp-cron is probably not executing properly, but you need to examine it to see what's trying to run but can't run.

  2. marc77
    Member
    Posted 5 years ago #

    Well, here is another one!

    I am from germany and the german wordpress Forum is full with this questions why all of the sudden the 2.7.1 wordpress is soooooooo slow. I work now on that problem for 1 Month. I really tried everything. I have a huge dedicated server. The server ist 100% not the problem. There is anything inside of the wordpress 2.7 and 2.7.1 what make that slowness. for me my admin is ok, but the main site need always arround 5 seconds..even when i have the wp_cache, super_cache, hyper_cache..gzip etc. on. i updated to php5 with new libcurl. i deactivated the plugin updates and the core updates. i installed it 5 times complete new. Well, i am really on my end. I found out, when i add that return; in the http.php its a bit better but after that the ping is not going out..i think nobody knows..but its true. i really hope that we find out this problem. Its really not a minor Problem..but most of these Mio WordPress User just wait for a next Version and hope with that its better. But my blog have alot of visitors each day and they all complain :(

    @otto: this is my cron:

    a:2:{i:1237980129;a:2:{s:17:"wp_update_plugins";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:3:{s:8:"schedule";s:10:"twicedaily";s:4:"args";a:0:{}s:8:"interval";i:43200;}}s:16:"wp_update_themes";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:3:{s:8:"schedule";s:10:"twicedaily";s:4:"args";a:0:{}s:8:"interval";i:43200;}}}s:7:"version";i:2;}

    when u need me for anything to do on my server, let me know..i have full access!

  3. psionmark
    Member
    Posted 5 years ago #

    @jmaxwilson - I managed to solve the wp-cron problem - by switching off WP Super Cache! wp-cron was getting hit more than 2,000 times per day. Switching it off has reduced that to less than 10! Looking back over the logs, I can see that the massive hits on wp-cron started when I installed WP Super Cache.

    I'm now using 1BlogCacher to see if that's any better.

    Although I've now sorted out wp-cron (I hope), there's still a severe problem with server load. Looking back through the logs, it appears to coincide with the upgrade to WP 2.7.1. Prior to that, I was just under my 1,000 GPU allowance on Media Temple. Since 2.7.1, I'm regularly using double that (so that's an additional $80 - $100 per month, on top of the $20 per month for the GS service). I'm getting the same number of visitors and I have the same plugins installed.

    I've done pretty much everything I can think of. Uninstalled as many plugins as I can, installed 1BlogCacher and DB Cache etc. The site loads fast now, but still the excessive server load persists.

    I'm only 8 hours into the day, have had 636 hits and 962 page views on the site and I'm already over my daily GPU allowance.

    If it's any help, Media Temple reports that my index.php has had 3,381 hits (defined as "number of hits to this path" and an IO read (defined as "the read load that these hits caused") of 553,000 in those 8 hours. Any idea why I'd be getting that many hits? I'm getting spidered quite a bit, but not a lot to take it up to that number.

    I'd really like some idea how to proceed. I'm reaching the stage where I really can't afford to run the site much longer :(

  4. psionmark
    Member
    Posted 5 years ago #

    Update: I've just checked my "requested pages" log for yesterday and it shows nearly 15,000 hits for /flightsimx.co.uk/index.php when I only had around 3,500 page views. Also, "Robots by Hits Drilldown" shows 21,886 hits for yesterday.

    Is this extremely high, or am I not understanding the numbers?

  5. psionmark
    Member
    Posted 5 years ago #

    Installing DB Cache caused wp-cron to be hit excessively again - over 200 times in an hour, using almost of that hours GPU allowance in itself. I've therefore now disabled that, too.

    I've left 1BlogCacher in place for now.

    It seems that any kind of caching (with the exception of 1BlogCacher so far as I can tell) kicks off a huge number of hits on wp-cron. If so, that somewhat defeats the object, doesn't it? We're installing all this caching stuff to speed things up and reduce server load, when in fact they seem to increase server load!

  6. drawab
    Member
    Posted 5 years ago #

    Im having the same problems on MediaTemple - and it could possibly be WP-Super-Cache

    I have been observing that Fully enabled Super Cache would simplt not work - so I resorted to enabling Half-on - well this month that also ended by leading me to GPU over charges -

    As per your suggestion I have disabled it entirely and im set ot watch its impact on the GPU usage fingers crossed

    my post a few days back

    http://wordpress.org/support/topic/246611

  7. Samuel Wood (Otto)
    Tech Ninja
    Posted 5 years ago #

    WP-Super-Cache uses the wp-cron system for its garbage collection, to delete older cached files. If you're using the full-on mode (instead of half-on) then you shouldn't see a lot of hits for these, since your visitors are usually getting served static files, and not hitting any PHP at all. Increasing the collection time on the WP-Super-Cache configuration screen will reduce the number of hits to the cron job.

    psionmark: I'd switch to another host, clearly Media Temple is having issues of some kind.

  8. bill.unger
    Member
    Posted 5 years ago #

    For whatever it is worth, I ripped out these lines from my .htaccess file and my site has returned to its 2.6 speeds:

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

  9. bill.unger
    Member
    Posted 5 years ago #

    Of course when I comment those lines out, I can't view any of my archived posts. <sigh> Interestingly enough, putting those lines back in slows my pages loads way down again. So there is definitely something going on there...

  10. psionmark
    Member
    Posted 5 years ago #

    @Otto42 - MT is my third host for this blog. The previous 2 both said WordPress was hammering their servers and that I'd need to look elsewhere. MT haven't asked me to move yet - why would they when they're raking in an extra $80 a month from me? If I move to another host, I'll most likely be told the same thing. The only common denominator here is WordPress. And, after all, it's not like I'm the only one with the problem here.

    I do find this more than a little frustrating. WordPress seems to always end up saying "find another host" and the hosts always seem to end up saying "find another blogging platform"! In any case, I've used Dreamhost and now Media Temple - both on your recommended list. If they're recommended, why are they not up to the job, as you seem to be suggesting? Or is it really not the host as I suspect?

    Look at the timeline here. I'd been using my blog on MT quite happily for a year. I was always under the 1,000 GPU, or maybe 50 or 60 over on a really busy month. I'm happy with that. WP 2.7.1 comes out, I upgrade and my GPU almost doubles. If the problem was with MT, people would be screaming about it. But they're not - they're screaming about WP 2.7.1. Moving hosts (again) won't solve the problem.

    I've been making a diary on the impact of removing plug-ins, watching how it affects GPU etc for the past 2 weeks. The only thing that made any real difference was that WP Super Cache caused a spike in GPU usage due to wp-cron. Having said that, it still only accounted for maybe 3 of the 60 GPU I was using per day. If I'm removing as much of the optional stuff as I can and the problem persists, then it seems to me the problem is with the core.

  11. Samuel Wood (Otto)
    Tech Ninja
    Posted 5 years ago #

    psionmark:

    a) They're not on *my* recommended list. I've heard very few good things about those hosts. I am not part of wordpress.org, I basically just moderate the spam on here (for free, mind you), and help out when I can. So don't go thinking that there's some keen master organization here or something, because there really is not.

    b) I have no idea what "GPU" is. You keep using that term, but it has no meaning to me. I've got dozens of sites on several hosts, and I've never heard of that term, nor have I had any speed issues on any of them.

    c) If 2.7 isn't working out, then roll back to 2.6. Or switch to another platform. Maybe WordPress just isn't right for you.

    But if you want to actually try and solve the problem, then I'll be glad to offer you advice and thoughts and ideas... but that's all I can offer you. I'm not really interested in anything other than talking technical details.

    You say you're getting all these hits to your site... From where? Have you looked at the actual logs? I mean, you're basically just giving numbers, but those aren't enough to debug a problem. Where are the hits coming from? If you only have 3500 page views, why is index.php being hit 15000 times? What's hitting it? (note that with WordPress, *all* hits for any page will be to index.php, as it handles rewriting internally.) What, exactly, is hitting the wp-cron.php file? What's the contents of the cron option's value in the database? These things are important to debug just what's going on. Turning stuff on and off at random isn't going to solve your problem or give anybody any useful information with which to fix it.

    If I'm removing as much of the optional stuff as I can and the problem persists, then it seems to me the problem is with the core.

    Wrong. That tells you that the problem is with your *server*, in some way. Why? Because the problem does not manifest with WordPress on other servers. See, if it was a core problem, then everybody would have it. Right? I mean, I can setup WordPress on my own boxes and it runs fast, without any speed issues and without hitting any processor problems. So, why is it happening on your box and not mine? That's the question. What is the difference on your hosting systems?

    Also note that the WordPress 2.7 codebase is running WordPress.com as well, which hosts a few million blogs, and has something like a billion hits a day (what with them also hosting major sites like ESPN and CNN and so forth). Admittedly, they have a much bigger setup, but still, if there's any speed issues, they find them pretty fast that way, as they push the latest WordPress code to that system something like 10 times a day.

  12. psionmark
    Member
    Posted 5 years ago #

    Otto42:

    Thanks for the detailed response. I apologise - I did think you were an "official" WordPress presence. I do appreciate that you're trying to help.

    Here's an explanation of a GPU from the MT site:

    "With (mt) Media Temple's GRID system your server site is no longer tied to an individual hardware server, rather it is spread across hundreds of server processors. The model gives your site ever expanding grid-cluster computing capability which allows you to scale and grow beyond the older shared server systems and even radically exceed dedicated server performance. The way this system is made possible is by keeping track of each customer's individual usage using a system we created, called GPU (which stands for Grid Performance Unit). Each (gs) Grid-Service hosting plan includes a large number of GPUs which have been carefully calculated to provide 99.7% of all customers with enough resources to never exceed the GPU allocation. For those clients operating large scale web sites experiencing daily or infrequent traffic surges, GPUs allow you to host your websites without worrying about reaching an arbitrary limit before getting shut down."

    This is what confuses me - why am I not in the 99.7%? I would be surprised if a fair number of that 99.7% weren't WordPress, so what's different about mine?

    I think you might be on to something re "what's hitting index.php". I've put:

    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} POST
    RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
    RewriteCond %{HTTP_REFERER} !.*flightsimx.co.uk.* [OR]
    RewriteCond %{HTTP_USER_AGENT} ^$
    RewriteRule (.*) http://%{REMOTE_ADDR}/$ [R=301,L]

    in my htaccess to try and stop what appeared to be a fair number of spam bots coming in. It does seem to be making some difference. I'll report back with results when it's been in place for a while.

    Sorry for hitting out at WordPress. It's just that everyone seems to blame everyone else. To be honest, I don't really care where the problem is, so long as I can fix it!

  13. bill.unger
    Member
    Posted 5 years ago #

    otto: any thoughts on why those changes to .htaccess might address the speed issues people have been reporting? I think if we could dig into that, it might lead somewhere good...

  14. Samuel Wood (Otto)
    Tech Ninja
    Posted 5 years ago #

    @psionmark:
    GPU - Ahh.. Grid hosting. Yeah, I don't use those. ;)

    Your htaccess rules - If those rules are intended to stop spam, then that could be part of your problem, because what that is really doing is sending them a redirect back to your main site, which could increase the load. Better approach would be to not redirect them, but to simply return a static page, or a forbidden or something. Redirecting them back causes an extra hit to the index.php. That could increase the processing load you're experiencing from spam bots, if they follow redirects (most will), because now they get a real page (meaning WordPress loads up) and they took some time from the initial request (which got stopped by .htaccess, but hey, load is load).

    Instead of those rules, try using the Cookies For Comments plugin. I found that it stopped a lot of comment spam very quickly without any significant load increase. It's not a perfect solution, but what is?

    Ideally, the best solution if you want to use rules like that is to serve them back a forbidden response and cut them off immediately. If you send them to any real page, then you'll get added load. Why serve a bot any real page? Just cut them off instead. That would be a "RewriteRule .* - [F,L]".

    @bill.unger: Well, the first thought is that by removing those (standard) rules, if you have non-default permalinks, then you break every hit to your site except for hits to the front page. That would certainly reduce load, but probably not in a desirable way.

  15. psionmark
    Member
    Posted 5 years ago #

    @Otto42:

    Thanks again for another detailed response. I tried the Grid Hosting as it was recommended by a lot of people for WordPress :)

    I shall try the Cookies for Comments plugin and see how that goes. Should I keep the RewriteRule (modified as you suggest) in place, or is that overkill if I also use the plugin?

    Now, something interesting has happened overnight! I did 2 things. One was block a lot of image hijacking that was taking place. Now, whilst this would reduce bandwidth (which wasn't a problem anyway), I think I'm right in saying it wouldn't reduce GPU/CPU usage - it's only serving a file.

    The other thing I did was write another email to Media Temple Support. I haven't heard back from them but, guess what, GPU usage has dropped to about a quarter of what it has been! I'm waiting to hear back from them as to what they've done, so will keep you posted.

  16. valentijnsessink
    Member
    Posted 5 years ago #

    I'm not sure if this is the right forum to reply on the "2.7.1 slow" postings (there are more of them), but this thread seems one of the longer ones, so I'll add my 2 cents here.
    My WordPress 2.7.1 was very slow after the upgrade; sometimes the front page did not show, but the admin pages were a problem almost all of the time.

    Then I suddenly realised, that my WordPress is behind a NAT'ed network with port forwarding; which also means that my blog cannot reach itself under it's hostname (i.e. you connect to myblog.example.com which has an external IP address; then port 80 gets forwarded to 192.168.1.5 where the server is; the server cannot reach myblog.example.com).

    I added a host name on the internal server in /etc/hosts and voila: the old speed was back:
    192.168.1.5 myblog.example.com

  17. samandasworld
    Member
    Posted 5 years ago #

    Valentijnsessink, I am very new to this and I can't figure out for the life of me where to change what you said above. I logged into my account at godaddy and went to my domains and saw on the domain that has the blog where I can add a host, but I don't see the etc/hosts that you talk about above. Can you tell me how to do what you did above because my site is so slow after I upgraded that it's almost pointless because people will leave before they wait 45 seconds for it to load :o( I have never had a issue with wordpress like this and it seems like what you said is a fix for it, but I just can't seem to figure out what it is that you did. If anyone else understand it and can explain I would appreciate it so much. Also when you say "myblog.example.com" what is that address? What is suppose to go into the example part?

  18. valentijnsessink
    Member
    Posted 5 years ago #

    If you have a hosting service like Godaddy (with public IP address), my fix will probably not help you. If, however, your hosting is behind a DSL line, chances are that you have so called "Network Address Translation" or NAT in place. *If* you have NAT, you should check that your server can find itself.

    Example. (These are examples! They won't help you without replacing the names and numbers with your own ones).

    Suppose your blog is called "my-personal-blog.example.com". Suppose the internal IP address of your server is 192.168.1.101.

    Then check, if your server can find "my-personal-blog.example.com" and check if your server translates it to 192.168.1.101.

    Now you seem to have a Godaddy account, and I'm pretty sure that you have a regular, public IP address (i.e. not starting with 192.168....). This means the above doesn't apply. You still could check if your server knows itself, i.e. if the server can resolve (i.e. find the DNS information for) "my-personal-blog.example.com" (replace with your own blog name). If your server is a Unix or Linux machine and you log in to the commandline, try host my-personal-blog.example.com (replace with your own blog name) and see if it is your server's IP address. If you log in to a web front-end, I wouldn't know how to check these things.

    Best regards, Valentijn

  19. Samuel Wood (Otto)
    Tech Ninja
    Posted 5 years ago #

    GoDaddy's hosting works fine with WordPress, and so any "fixes" like above won't help. Their servers can connect to themselves just fine.

    If you're having speed issues on GoDaddy, then it's probably just the fact that their servers are so overloaded and slow. There's no fix for this short of upgrading to a dedicated server or switching hosts.

  20. pcjoshuasmith
    Member
    Posted 5 years ago #

    All,

    I have encountered the same problem and switched my blog back to 2.6.5

    I am not a newbie and would consider myself proficient in software considering I work for a software company. I totally understand the support of software process so I have 2 suggestions in order to get this fixed.

    1) For the guys that are really proficient in PHP and WordPress, could you write out a guide on how to troubleshoot and debug this problem. This will allow some good qualified data to come back instead of just "it's broken".

    2) Nobody seems to understand that WordPress is free and that Otto42 is not incentivised to support or help us in any way, therefore, if people who have this problem were to "contribute" $5 each into Otts42's paypal account would he be willing to troubleshoot 3 install instances to find the root cause?

  21. Michael2009
    Member
    Posted 5 years ago #

    Hello,
    i have the same problem. With IE 6 is very slow, and with Mozilla or IE 7 its ok. The Theme was the reason. This was built with a program and this has have an problem. With update it is ok. Try with an other browser and look ist it ok or try a default Theme.
    Maybe this can help.
    best regards
    michael

  22. jmvdigital
    Member
    Posted 5 years ago #

    I'm having slow response times viewing and editing posts too. Just wanted to chime in.

  23. Paint Guy
    Member
    Posted 5 years ago #

    I am new to WordPress. Should I look at installing an older version or has this ver. 2.7 "slow" issue been fixed.

    Thanks

  24. yallaman
    Member
    Posted 5 years ago #

    @ Paint Guy:
    The slowness issue has not been fixed. As far as I know, it has not been acknowledged by the developers as a problem related to WordPress, so it might take a while for this to be sorted out ...

  25. bill.unger
    Member
    Posted 4 years ago #

    Was there ever a resolution to this issue?

  26. Mojtaba
    Member
    Posted 4 years ago #

    @psionmark - Did you find any solution?
    I have the same issue with my blog! :(
    What should I do in order to get lower GPU usage in MT???
    I know 1blogcacher can do that but it causes very problem such as Internal server error.

  27. scot184
    Member
    Posted 4 years ago #

    Try changing themes...there's a chance your chosen theme is an issue in the 2.7 versions and beyond.

    Also, download and activate Firebug for Firefox...it's a free add-on...then load your blog normally in Firefox, and use Firebug to check the load time and what exactly is taking the longest amount of time to load.

    Chances are it's files from your theme...Firebug will show you...if so, change your theme.

  28. Tim Nicholson
    Member
    Posted 4 years ago #

    Otto: Sorry for jumping on an older thread here, but this is interesting information. Specifically, you listed `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');`

    Do you know what default WP functions we would be blocking with each of the individual filters above? Eg, pingbacks, trackbacks, XML-RPC, etc? If some of us don't need some of those things, we could shut them off without issue, but I'd hate to shut down a protocol that is needed for something I consider important.

    Also, I don't believe it was mentioned here in this thread, but I found a tip on the WP Tuner site about physically removing unused plugins. http://blogs.icta.net/plugins/2009/08/24/wptuner-096-comments/#comment-642. It makes no sense to me how this could help, but I have seen marked improvement in my page loads since doing it. I looked at the wp-settings.php file it reads the list of active plugins from the database. It doesn't just loop through all the files in the plugin directory. So it really makes no sense, but it seems to work. Do you have any idea why something like that might improve performance?

Topic Closed

This topic has been closed to new replies.

About this Topic