WP is a serious hog do to it not caching pages

resource use monitors
http://www.xaprb.com/blog/2006/07/02...nnodb-monitor/

http://hackmysql.com/mysqlreport



For context, this is running on a Windows Web Server 2008 virtual machine with a single core of a 2.13 GHz Xeon 3210 entirely dedicated to it.

This is an incredibly scary result; blog.stackoverflow.com is getting, at best, a moderate trickle of incoming traffic. It's barely linked anywhere! With that kind of CPU load level, this site would fall over instantaneously if it got remotely popular, or God forbid, anywhere near the front page of a social bookmarking website.

For a bare-bones blog which is doing approximately nothing, this is a completely unacceptable result. It's appalling.

As evidence of what a systemic problem this is, there's an entire cottage industry built around shoehorning better caching behavior into WordPress. Take your pick: WP-Cache, WP-Super-Cache, or Bad Behavior. The caching add-ins don't work very well under IIS because they assume they're running on a *NIX platform, but they can be coerced into working.

Does it work? Does it ever. Here's what CPU usage looks like with basic WP-Cache type functionality enabled:



I'm not alone; just do a web search on WordPress CPU usage or WordPress Digg Effect and you'll find page after page of horror stories, most (all?) of which are solved by the swift and judicious application of the WP-Cache plugins.

It's not like this a new issue. Personally, I think it's absolutely irresponsible that WP-Cache like functionality isn't already built into WordPress. I would not even consider deploying WordPress anywhere without it. And yet, according to a recent podcast, Matt Mullenweg dismisses it out of hand and hand-wavingly alludes to vague TechCrunch server reconfigurations.

A default WordPress install will query the database twenty times every time you refresh the page, even if not one single element on that page has changed. Doesn't that strike you as a bad idea? Maybe even, dare I say it, sloppy programming?

I understand that users may have umpteen thousand WordPress plugins installed, all of which demand to change on every page load. Yes, the easiest path, the path of least resistance, is to mindlessly query the database every time you're building a page. But I cannot accept that a default, bare-bones WordPress install hasn't the first clue how to cache and avoid expensive, redundant trips to the database.

It's frustrating, because caching is a completely solved problem in other programming communities. For example, the .NET framework has had page output caching and page fragment output caching baked into ASP.NET for years.

I sure am glad I started this blog in Movable Type way back in 2004. Their classic static rendering blog engine approach may be derided today, but I shudder to think of the number of times the Coding Horror webserver would have been completely incapacitated over the years by the naive -- no, that's too tame -- brainlessly stupid dynamic rendering approach WordPress uses.

What I just don't understand is why, after all these years, and all these documented problems, WordPress hasn't folded WP-Cache into the core. If you're ever planning to have traffic of any size on a WordPress blog, consider yourselves warned.

Update: Matt Mullenweg kindly responded to this post and offered his recommended MySQL configuration optimizations. I definitely agree that the Query Cache is extremely important to performance, and for some reason it defaulted to off (zero size) on my installation. You may also want to look into innotop and mysqlreport to ensure that all your MySQL caches are functioning at appropriate levels. Also, thanks to a few commenters for letting me know that one of this year's Google Summer of Code projects is integrating caching into the core WordPress code. It is badly needed.

http://www.codinghorror.com/blog/200...r-of-cpus.html


From: Matt Mullenweg
To: Jeff Atwood
Date: April 23, 2008
Subject: Making WordPress Sing

Here's what I'd recommend [for MySQL configuration], after the tmpdir stuff under [mysqld]: (Some of these are high, but you'll never reach them and based on your available memory not a big deal.)

skip-external-locking
skip-slave-start
skip-bdb
skip-innodb
skip-name-resolve

# Global mem settings
key_buffer = 24M

max_connections = 200

# Per client mem settings

sort_buffer_size = 4M
read_buffer_size = 4M
binlog_cache_size = 2M

max_allowed_packet = 12M
thread_stack = 128K

table_cache = 128
thread_cache = 256
thread_concurrency = 4

myisam_sort_buffer_size = 1M
tmp_table_size = 12M
max_heap_table_size = 12M

wait_timeout = 200
interactive_timeout = 300
max_connect_errors = 10000

query_cache_type = 1
query_cache_limit = 1M
query_cache_size = 16M

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer = 16M