View Single Post
  #5  
Old 15th December 2011, 12:40
talkingnews talkingnews is offline
Member
 
Join Date: Jan 2011
Posts: 67
Thanks: 15
Thanked 6 Times in 6 Posts
Default

I found the answer! Scroll down, but first, some answers...

Quote:
Originally Posted by till View Post
Changing tables to innodb causes mysql to use more ram so that the performance can decrease on low memory systems.
With Innodb being the standard for the current mysql, I thought I'd do some digging around here. Looking at speed/memory comparisons from 2008/2009, that might have been the case, but now, most tests put innodb as around 25% faster. So while it might use a little more memory, that memory is used for less time.

Quote:
Originally Posted by till View Post
You compare apples with pies here. Not every mysql query is the same and the raw database size is only one of several parameters that affects mysql performance. If a query is slow or fast depends on a lot of things like joins, if it has good indexes set and if the temp table has to be created on the harddisk etc
.

Well, I think we can deal with the DB side of things quite quickly - here's the output from wordpress in debug mode:

[0] => SELECT wp_posts.* FROM wp_posts WHERE 1=1 AND wp_posts.ID = 4 AND wp_posts.post_type = 'page' ORDER BY wp_posts.post_date DESC
[1] => 0.032161951065063
[2] => require, wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->get_posts, W3_Db->query

[0] => SELECT p.* FROM wp_posts AS p WHERE p.post_date < '2011-09-14 09:45:51' AND p.post_type = 'page' AND p.post_status = 'publish' ORDER BY p.post_date DESC LIMIT 1
[1] => 0.0060410499572754
[2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_head, do_action, call_user_func_array, adjacent_posts_rel_link_wp_head, adjacent_posts_rel_link, get_adjacent_post_rel_link, get_adjacent_post, W3_Db->query

[0] => SELECT p.* FROM wp_posts AS p WHERE p.post_date > '2011-09-14 09:45:51' AND p.post_type = 'page' AND p.post_status = 'publish' ORDER BY p.post_date ASC LIMIT 1
[1] => 0.00027585029602051
[2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_head, do_action, call_user_func_array, adjacent_posts_rel_link_wp_head, adjacent_posts_rel_link, get_adjacent_post_rel_link, get_adjacent_post, W3_Db->query

[0] => SELECT comment_approved, COUNT( * ) AS num_comments FROM wp_comments GROUP BY comment_approved
[1] => 0.00011110305786133
[2] => require, require_once, include, get_footer, locate_template, load_template, require_once, wp_footer, do_action, call_user_func_array, wp_admin_bar_render, do_action_ref_array, call_user_func_array, wp_admin_bar_comments_menu, wp_count_comments, W3_Db->query

So that doesn't even total 0.1 seconds for the db query part of things.

Quote:
Originally Posted by till View Post
One other thing that you might want to check is if the nameservers in /etc/resolv.conf are rechable and responding fast.
DNS is totally turned off, and handled by either Cloudflare, Amazon Route53 or ZoneEdit. The server doesn't run sendmail, smpt, pop3, dns... it just runs mysql, nginx, php5-fpm and ftp (oh, and a couple of basics like rkhunter!) but I only need websites, not other things. The front end runs fine, it was only the back end of WP that was slow. How would DNS affect this?

So, in fact, it was none of those things....

Two days of my life and a helluva lot of learning about things like xdebug, I can safely say you CANNOT now run WordPress on a VPS with less than 512Mb RAM. Which is a shame, because the 256Mb VPS had always been perfectly good before.

Previously, it had been OK. You remember in my original post, I noted the line about "ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value"?

Well, I also noted that I didn't see any memory spiking in the command line utility "top". But clearly, that doesn't refresh fast enough. With a bit of help from the VPS host who has graphical tools, we were seeing bursts of 228Mb usage when the ADMIN side of WP 3.3 was trying to load. But the front end? Well, as I said before, that zipped along and barely even registered on their graph.

I also mentioned that I tried limiting memory use in both php.ini and the wordpress config. Well, I stepped down through 256 to 128 to 64 to 32, although from 128Mb, it would only serve blank pages.

EDIT: Turns out this is confirmed by another blogger:
http://www.dev4press.com/2011/blog/b...vs-3-2-vs-3-3/
Quote:
I can’t end this benchmark on a positive note as I did back in July for WordPress 3.2. I can understand that WordPress is evolving and that new features can need more resources. But, in WordPress 3.2 six months ago, features and changes were followed by considerable optimization, and that resulted in faster WordPress. This time, we got no significant new features or improvements, apart from cosmetic ones (and some of them are questionable at best) and some changes that affected only some features (uploader and editor), and yet new WordPress is gone back a full year in terms of performance, and it is comparable to WP 3.1 or even WP 3.0 in some cases.
I've temporarily moved to a 512Mb RAM VPS while I decide what to do, and, of course, WP is fine again. But it's not an affordable long-term solution. So will either have to try and revert, or look at another CMS. Which is a shame, after 5 years of happy WordPressing.

Final note to pre-empt the inevitable "but you can get 1Gb RAM VPS very cheap these days" comment, yes, you can. And I've been badly burnt that way. Amazon EC2 looks incredibly tempting - but you try not being able to stop, recover, relaunch or save a backup or even a snapshot from a failed instance for the 6 days it takes support to reply. And as for HostEurope/Webfusion, hell will freeze over and I'll start listening to Justin Bieber before I even wish them on my worst enemy.

So I'm happy that I can just pick up the phone and immediately speak to someone, in London, in English.

Last edited by talkingnews; 15th December 2011 at 12:51.
Reply With Quote