I wonder what the CPU usage is for my oh-so-humble blog. I suspect it's not too bad though, as (1) I have on the order of 10 hits a month, and (2) they're not charging me anything, so how much could it be costing them? ;-)

The main problem isn't WordPress. The main problem is that you're using Windows.

Switch to Linux and fly!

@Seize
Why, does Linux make those 20 database calls faster?

It's MAGIC!

I highly recommend you switch to Drupal! ;)

Running PHP under Windows is plain old stupid, but i agree: Wordpress is quality-wise a monster. It is the perfect example where features (namely the plugin-system) are way more important than performance and correctness if you only look at market-acceptance.

Interesting stuff! I am curious as to why you have chosen to use IIS instead of the more commonly-used Linux + Apache setup for most blogs. Could you elaborate on that decision?

Er, isn't Bad Behavior an anti-spam plugin?

It's worth noting that PHP has plenty of support for output buffering which can be fairly elegantly turned into a caching solution with a trivial amount of effort (less so on a massively complex dynamic site, but a blog's homepage is as straightforward as they come in most respects). It's just that…WordPress doesn't do it.

My personal experience of WordPress is that while the UI is polished (indeed, WordPress’s admin interface is pretty exemplary for open source web-based software), a peek under the hood reveals a somewhat different picture. Perhaps that's purely a matter of coding style (I detest mixing of code and output inline–as per “classic” PHP or ASP), perhaps not. I was put off before digging any deeper, to be honest.

> Running PHP under Windows is plain old stupid,

You'd be surprised, I think, to find out that Windows Server 2008 is an excellent PHP platform. This is a new development.

http://developers.slashdot.org/article.pl?sid=08/03/04/1452232

I recall glancing over the google summer of code projects recently, wordpress said that a built in cache was something they want to work on.

Integrating caching into the core wordpress code is being worked on in this year's summer of code

http://code.google.com/soc/2008/wordpress/appinfo.html?csaid=7E1A38664ABC103C

For my "blog" I went with a very simple solution, a 20 line shell script.
I had no interest in figuring out how to install and maintain wordpress et. al.
It performs very well :)

http://www.pixelbeat.org/docs/web/about/

In case anyone is interested in trying to test his new setup....http://digg.com/programming/Let_s_Bring_Down_CodingHorror_Author_Jeff_AtWood_s_New_Blog

I was just discussing the WP Cache plugin with a coworker for its conceivable benefits of improving page load times for visitors, but now I'll be installing it to protect my poor CPU, thanks Jeff!

Make your own.

Whats so intense about blogging software? Its a database with some simple forms and web pages...

This is probably my naivete from only ever looking at a few blogs and never running one though... even so, I would be surprised to find out that there is any requirement beyond some simple database tables to store the text and a simple web page which requests and displays the data... there are a number of quick and easy caching methods... especially given that whatever web development language will do all of the hard work for you...

I've written a simple forum using PHP and MySQL before... its a similar problem as far as I can see, although I only implemented caching for the most expensive bits as I didn't have a big problem with it. But I am probably lacking good testing from large numbers of users...

I using my XSLT blog system to generate static html files, including a stylesheet to generate photo albums.

http://markraddatz.org/fooweb/

I recently got kicked from a shared hosting server for having a "mildly" popular wordpress blog. Not because of traffic, but because of cpu usage.

I wasn't even aware that wordpress was using up so much resources. I didn't get any warnings from my hosting provider or hints. Now that I switched to a virtual server, I stand before another problem. Memory usage is too high. I've seen a single serving of a wordpress page taking up to 30mb of ram using memory_get_usage. which means, 20 concurrent users might peak my allowed memory usage pretty fast and encouraging virtuozzo to kill my apache process. Using a caching plugin didn't really help.

Teaches me to go for a dedicated server from the beginning.

You dedication to Windows ecosystem cripples you. I think starting a new portal with new web server is a perfect opportunity to get into Linux. I suggest to set up the same blog system on Linux and compare CPU usage and speed. That might be an interesting article.

Nevermind the fact that the newest version of WordPress is pretty much an absolute frigging mess, right down to the new hideous aqua admin UI (which does have a color option to set it back to 'classic mode'... which only changes _part_ of the admin UI). It came out of the box with a broken file uploader for a whole lot of people because of its required dependence on a Flash component.

Seeing this bit of news here today does not surprise me in the least. Unfortunately I'm fairly heavily invested in it, using it to run a number of websites (except for the one I'm linking to my name, which is on Tumblr).

I assume you have seem this:
http://www.hanselman.com/blog/ScreencastHowToIIS7AndPHPWithFastCGI.aspx
?

It includes a part about caching built into IIS.

If you haven't already, you may want to look into <a href="http://php.net/apc">apc</a>, an opcode cache for PHP. In a load test environment, I've seen it increase the number of transactions (full page renders, with support files), by 40%. In production, its had similar benefit for CPU utilization (dropping CPU usage by 40 to 50%). This however is on Linux servers; YMMV on Windows.

<strong>That was my gentlemanly advice, what follows is my knee jerk, anecdotal reaction:</strong>

I'm sure PHP on Windows is a viable solution, but my previous experience with attempting to port high traffic PHP applications to from Linux to WIndows is: why waste your time when there is are several other known, stable platform available at no cost (namely *BSD and Linux). My guess is that you're primary concern with Stack Overflow is not going to be profiling PHP code, or debugging WP plugins that don't work because they assumed a different operating environment.

As for Zend saying Windows is "PHP Ready", their own installer for previous versions of PHP/IIS did not work properly. Its not that PHP/IIS didn't work, its that the team providing the package couldn't even set it up correctly, even their provided documentation did not work as expected. In previous iterations of PHP/IIS it was mostly shared community knowledge and experience that made reliable setup an option. According to the article, (which I assume is the same as <a href="http://devzone.zend.com/article/3233-Windows-Server-2008-Now-PHP-Ready">this one</a>, the slashdot link was down), certification consists of 100 (!) tests. That's not exactly an inspiring number, especially when it covers "compatibility, security, reliability, and availability..., while ensuring the software performs in a 64-bit environment". Its also a press release, which to me, means absolutely nothing, and has no technical footing.

Feel free to ignore the proceeding to paragraphs, but seriously look at APC. Its a brilliant addition to any PHP environment.

This has nothing to do with running it on Windows. That WordPress is a hog is something I frequently see acknowledged by developer-users from any platform (yes, Linux included).

Jeff, I'll echo the suggestion that you roll your own, though. It really IS a pretty simple thing to build, particularly if you aren't after all of the plug-in magic. I'm sure that with your C# mojo, you could build something to fit the bill.

As many others will tell you, stop using Windows, and for god's sake stop using IIS.

Yes, it's much better than it used to be. It used to be cripplingly slow, and insanely insecure. Now it's just slow, overweight, and inefficient at using memory. And since I doubt you've got IIS using thread pools for PHP, you're probably reloading the whole damn binary for each dispatch.

The obsession with full-on x86 virtualization doesn't help anything either. It's only really necessary for dealing with the fact that it's stupid to share a multi-user Windows server with people you don't trust, not that you'd want to anyway because of architectural deficiencies anyway.

Unless you're in a really high-end virtualization environment, your VM's disk speed is also crippling it, and it doesn't help that the Windows VFS layer is pretty shitty about using free memory for caching when it's there.

It's because they hate your freedom.

"I recently got kicked from a shared hosting server for having a "mildly" popular wordpress blog. Not because of traffic, but because of cpu usage."

My hosting company called it abuse of the Apache server, but they were unable to give my any (a) limits, or (b) means to monitor against said limits. Turns out they were having huge MySQL issues, and resolved them by driving away customers that had blogs.

WP-Cache improved page load times remarkably, but I eventually switched to a load balanced hosting company. Smooth sailing.

What's the database back-end? Some database engines do better query caching that others, making those 20 trips not such a big deal.

If you think WordPress is polished software then you probably haven't read much of the actual code, tried to write plugins, or themes. It's just another giant messy PHP hack.

The advantage of WP of course is that it works well, and it has more plugins and themes and features and users than the others.

no html in the comments, so here's a link to apc:
<a href="http://php.net/apc">http://php.net/apc</a>

and here's the press release i mentioed:
<a href="http://devzone.zend.com/article/3233-Windows-Server-2008-Now-PHP-Ready">http://devzone.zend.com/article/3233-Windows-Server-2008-Now-PHP-Ready</a>

Dear Jeff,

Do you know for sure it is the not the database or database abstration layer? Wordpress could be doing heavy use of the database. May be with MYSQL works great but has a performance penalty for SQL Server. Maybe OleDb instead of ODBC can be a great difference or the other way arround.

I am sure that there must be a reason as Wordpress is such a widespread aplication in cheap hostings. Surely, being a clever one you will be able to discover it soon. Please tell us.

Agreed with other commenters above. While WordPress is a pretty complete application, and it has a fairly polished UI, it reads like a hack.

Hopefully this post will help to persuade WordPress developers to deal with the issue.

Try Bloget. (http://blueonionsoftware.com/bloget.aspx). It's so light and fast it will make your head spin (well maybe not, but you get the idea).

First off let me state that I use both Windows and Linux and I am comfortable with either - lest you guys start accusing me of fanboyism on either front. That being said what makes y'all believe that 20 database calls per page view is a good idea for any OS? Thats not a Windows/*NIX problem, thats crappy coding in Wordpress no matter how you slice it. Thats using more CPU and memory no matter what OS you are on. Jeff's article is about Wordpress and it's failures to implement common-sense practices around page caching and performance, not what OS better runs that hog.

Oh. Windows, IIS, FastCGI, PHP.
Match made in heaven, indeed.

I have been running Wordpress for a few years now, and about a year ago I installed WP-Cache, then eventually upgraded to WP-Super-Cache and I am very glad I did. I made it onto the front page of Digg a little while ago and the server didn't even blink. CPU usage stayed very low and was able to easily handle all the traffic. I'm running PHP5 on IIS6 with Microsoft's FastCGI (from the IIS.NET site). It has been a rock solid setup, and very lightweight on the CPU.

And going along with everyone elses suggestions... Graffiti CMS?

It seems nice and lightweight and the same sort of experience, but on ASP.NET.

Jeff,

I am hardcore .Net developer, but on my blog I use Wordpress, because that is what seemed like the best of breed at the time, and I wanted to broaden my horizons about OpenSource. I had a press release about giving the domain Drupal.Com to Dries, and we got hit by Digg and I am happy to say the site stayed up. However, I did have the cache plugins.
I agree that this should be core - have you looked at Drupal? I it is more complex to setup, but more powerful than Wordpress, which is built just for blogging

Hi Jeff,

Have you looked at turning on dynamic caching in IIS 7.0?
Taking the load of the static content, scripts, styles, and images off of the FastCGI interface?
And setting the expires header to one week?

I was in a similar situation as you were with IIS 6.0 and FastCGI and all reduced the load of the server to next to nothing.

Hi Jeff,

I have to ask, what did you do about permission settings for wp-cache? By this I mean it's almost asking for a chmod 777 (for the *nix world) on the wp-content folder, which I find extremely scary...

I read it as Fake Plasticrock. (say it like plasti-crock)

And yeah, if the website hits the database 20 times a request, that's bad regardless of the OS. You're still HITTING THE DATABASE 20 TIMES!

It's seriously time to refactor Wordpress. I use it a lot, it's lovely to use and deploy for all kinds of projects, but under the hood it is a POS.

Classic PHP amateur hour. And I love PHP by the way, and I love to cite Wordpress as one of PHP's success stories, but the code is awful.

The problem is, besides the huge task of refactoring itself, it's impossible to change WP into something well structured without breaking *all* plugins and templates, and it's this ecosystem of add-ons that is major part of WP's success in the first place.

I'm afraid that no matter how successful today, WordPress is a dead end.

**
You said: 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.
**

You're confusing applications and frameworks. The above statement is the equivalent of asking MS Word to handle talking to your disks instead of the operating system.

PHP is the language here, and yes, it has caching solutions aplenty.

I totally agree with this article. I did a test a few months back of Drupal and Wordpress. I used Drupal 6 and WP 2.3.3 for the test and the same base data set (content, categories, authors and comments) for each. I also enabled the core caching for each system (in WP that was the file based object cache, which is now out of the core), and found Drupal was delivering more than 4 times the requests per second.

Now that Wordpress has the new UI, hopefully the developers will spend time in core optimization. It seems that a lot is lost by focusing on keeping more plugins backwards compatible, but you get to a point when you must cut the losses and have the plugin developers update their code.

I will admit that I am a fan of Wordpress and Linux, but I do also use Windows for some services at work. I'll try to not be biased.

I concede that you having a problem with WP not caching at all would be a problem, but it seems that you are complaining that you have to install a plugin?

Not being a default feature being is not so horrible (i.e. plugin installs are easy), but what is "absolutely irresponsible" is the idea that you used google (or perhaps msn.com?) as a reputable source. Saying Look how many hits I get when typing this in, is a sad new step for the thoroughness I once loved about you blog.

I think it should also be noted that MT is only FOSS at its most basic level. Jeff, if you say wanted to start an online community (add supported) with MT (stack overflow?), and have more than 20 users, it seems that you could be running into a initial fee of over $1000, and around $300 for upgrades.
http://www.movabletype.com/download/purchase.html

Just last week you wrote an entire article to how dual-core+ machines are a Developers right, so having a Quad-core for a server goes without saying, but why didn't you put a 64bit OS on that processor. (Or was that just a failure to mention?)

You also say that it is a virtual machine, dedicated solely to running this. If it is a virtual machine it isn't solely doing anything. You should consider how much CPU bandwidth is being dedicated to running you machine virtually (and other services).

In other words the CPU graph is also monitoring itself, so before you make the claim that it is WP (or any other service) try and isolate the process statistics. A before and after at an arbitrary time isn't indicative of what process is used and how much, but that the system is under a load at point A, and not the same load at point B, regardless of the plugin/cache state.

Textpattern (http://www.textpattern.com) anyone? highly configurable, free, and has a good plug-in community too :)

What's funny is the Wordpress pundits go on and on about how it's an advantage to serve up dynamic pages and how blogs that serve up cached pages are lame. Obviously most of them have not enterprise level websites.

>You'd be surprised, I think, to find out that Windows Server 2008 is an excellent PHP platform. This is a new development.

Not really new -- Windows has been an excellent PHP platform for quite a long time. Previously it roared with the ISAPI runtime, and now it is roaring with FastCGI. Zend and Microsoft have been working on various sales pitches for some time.

And really, all of the Apache/Linux vs Windows comments completely miss the point -- the difference between the two OS' is almost invisibly small relative to the gross inefficiency of Wordpress in a default install.

I like all the arm-chair experts suggesting the slowness of WordPress would be remedied by switching operating systems...all based upon one anecdote and a picture of Task Manager.

"brainlessly stupid"
Flamy flamy....

Ba-a-a-a-d Wordpress. I hope your post pushes someone that has anything to say in WP.

Are you planning on deploying some ASP or ASP.NET app on the server? If not, at best you're wasting your money, at worst both wasting money and harming performance. I recommend a BSD-Apache-MySQL-PHP setup, or Debian if you prefer Linux.

I didn't see this mentioned - but PHP itself needs to be cached - you can get 10x performance with a "bytecode" cache.

Every dynamic language is CPU intensive.

@JohnW

With Jeff getting 37,000 unique hits a day, I think you're going to need to do more than a Digg article to do a stress test, I believe 37,000 a day is a nice test just in itself.

But what do I know, I've never been a creator of a site with more than 10-20 unique visitors a day anyways, so whatever. :)

After upgrading www.kellytadams.com to MovableType 4.1, I've been very impressed. The AJAX editing, the support of Markdown, and the rendered output makes it run fast with minimal CPU load. Although I haven't been able to get dynamic rendering to work to compare (problems with host and PHP safe_mode); for someone who adds a new entry maybe twice a month, it works fabulously. The template inheritance and widgets made customization a snap. Judicious use of in-line callbacks (like a call to the Picasa API) can make the pages seem dynamic, but spread the load to the clients. PHP baaad, mmmkay?

@Jeff - "For example, the .NET framework has had page output caching and page fragment output caching baked into ASP.NET for years."

But you have to turn the caching on; it's not on by default.

I'm not sure I see the difference, really... If the wp-cache was distributed by WordPress, people would still need to turn it on (and wouldn't) ... until they saw a problem, that is.

Our Drupal site has a minimum of 200 database requests on each page and some have more than 500. As I see it, that's the price of using a general purpose system. I could have developed the site from scratch and it would have been much more efficient but it would have taken four times as long. However, Drupal's built in caching does a great job (unless you're logged in). And don't forget that MySQL's cache should be effective on a blog that doesn't change much.

@Jesse: True, Caching isn't turned on by default in ASP.NET, but without caching, you aren't getting CPU results like you would in WordPress without caching.

With respect to your comments about why caching is not part of the WordPress base install, one wonders (well, I do anyway) how wordpress.com is configured. They must have at least a few sites there that get hammered pretty viciously. I vaguely remember the team saying they had learned a lot from building out the site and that those insights would be folded back into the redistributable software. Did that ever happen?

I've set up tons of WordPress installs and this hasn't been my experience so I have to assume it has something to do with your system.

"Our Drupal site has a minimum of 200 database requests on each page and some have more than 500."

@AndyT: Why!?

Bad Behavior is an anti-spam, not a caching, plugin and is notorious for eating up CPU itself.

Your biggest problem is you OS. There is an OS called ubuntu, and I hear its much better.

@Linus: Mmmm, no thanks. Windows OS works fine for me.

[sentax]
As some people have mentioned that it may be the database back end that is causing the CPU spikes, I was researching web hosts a month ago and I wanted Windows server with Wordpress, all of the hosting companies I found didn't offer it. I couldn't make Wordpress work on a Windows setup because they offered only MS SQL Express instead of MySQL which if you know Wordpress only works on MySQL. So in order to get Wordpress I would of had to use a Linux account with Wordpress, then MySQL would be included in that account and then I'm good to go with Wordpress.

I'm thinking maybe this is how hosting companies are getting around the Windows+Wordpress performance problems, or maybe it's just the WP-Cache they don't know about? They are avoiding the CPU problem by only offering a certain setup to run on their servers.

Makes me wonder.
[/sentax]

Jeff, you didn't mention whether you were using MySQL or MSSQL, but assuming the former you should definitely enable query caching there for some potentially huge gains. We have a jsp app doing 20-30 queries per page load on ~300,000 row tables, and enabling the query cache improved performance by an order of magnitude (once the initial queries were cached, that is). The relevant variable to google is "query_cache_size".

There are a lot of other tuneables for MySQL too, but nothing else made nearly the difference that the query cache did.

Have you looked at DasBlog? It is a .NET solution...

My blog is not exactly a world-beater but it gets descent traffic and WP2.5 barely registers on my CPU load. I'm running it on FreeBSD on an ancient Celeron box with 256MB of RAM! I really think the problem here is that Windows is not a great platform for running PHP on.

I'd suggest going LAMP and then re-running your tests. I think you'll be surprised by the difference.

Bart.

The advantages of serving dynamic content are really only useful with dynamic content. A lot of what WP does could and should be done statically.

But that's considered evil and wrong and would be too much like MT. Matt's hinted as much previously.

Which is made all the more amusing that folks will go to great lengths to make as much content as static as possible (which is what caching tries to do) in order to gain some control over CPU usage.

And the built in caching that was trialled a few versions back now just didn't work right with dynamic db calls, causing borkage and pain to anyone crazy enough to try using it.

WP has some very inefficient db calls - that's really where a lot of the CPU load is. They've tried to improve it too, but the moment a handful of plugins or widgets are enabled the db calls become crippling.

It's still a big problem. Add load to that and WP won't cope. Not without some serious iron. db caching and PHP accelerators can help mitigate a lot of that.

Interesting stuff. I have a little WordPress blog; in fact, it *is* my website. With photo galleries and the works. Love it. But yes, the code is a nightmare: I thought it was just me, because I hate hate hate PHP. But you have to dig into some pretty hairy code just to do simple modifications to the templates.

As for CPU issues... I'll let my provider deal with that. I never heard of any issues before. But I was also kind of under the impression that WordPress didn't scale well, because I've never seen any *major* sites using it.

You should try linux eco system.

"And really, all of the Apache/Linux vs Windows comments completely miss the point -- the difference between the two OS' is almost invisibly small relative to the gross inefficiency of Wordpress in a default install."

While in all cases a poorly-written program will have a more significant impact on its performance than which operating system it's running on, there are two important differences between Linux and Windows that I can see will make a difference here.

1. Windows memory management is broken. It puts all sorts of data into its page file even when there is lots of free RAM remaining. This can be an especially bad choice if you are caching content to RAM or are using a database with a large memory footprint. The Linux kernel comes configured out of the box pretty well, but you can also manually adjust the kernel's swappiness to determine when it swaps RAM data to disk.

2. Windows virtualization is immature and has very poor I/O performance. On Linux you can use Xen to achieve virtualization with very little overhead. A poorly performing VM will kill performance for most programs. It's even worse with Windows running on top of Windows when you factor in the poor memory management from my previous point. Virtual Server and VMWare Server are almost unusable for anything more than a development setup.

I run 30 wordpress blogs.. Everything was fine when they all did less than a 100 hits a day. When they hit 1000 hits a day my host informed me that my CPU was at a constant state of 100%.

Using Caching my CPU is now at an average of 18%... And my blogs doubled in traffic since people don't have to wait 30 seconds for a page to load.

I can't believe you called the developers of word press sloppy. Just because YOU have a requirement that they didn't meet. (Out of the box, super fast, ready for digg running on windows)

Wordpress is one of the best blog engines out there because it is configurable and has an awesome ecosystem.

I would say that sloppy is just setting something up quickly and assume it can handle high load without tunning. (And running PHP on windows? come on!)

I too wish wp-cache were built into Wordpress and more easily configured. Wordpress has so much going for it but issues like this make me want to run Serendipity - http://www.s9y.org - and other blogging platforms.

Why don't you vote with your choice of blogging engines and pick a "better" one?

You may want to try different blog software.
Try this one..
http://www.dotnetblogengine.net/

Themes...
http://www.dotnetblogengine.net/page/themes.aspx

Extensions...
http://www.dotnetblogengine.net/page/extensions.aspx

This is slightly out of topic...so excuse me. Why PHP? Are you leaving Microsoft development because you're partnering with Joel and he doesn't like MS products?

I agree WP-Cache should be included in the default bundle. And I agree that you need it for WP to perform properly. There's really no reason not to download, install and activate it, though. It comes pre-bundled in DreamHost's One-Click Install of WordPress for a reason.

With WP-Cache enabled, WordPress flies like an unladen European swallow. Not only does that cause all WP pages to be cached, but they are served in a RESTful, HTTP-friendly manner too, with Last-Modified headers and everything you need to do conditional GETs.

Although it doesn't improve WordPress' code quality, I'd also recommend you to host it in a Linux environment and preferably with mod_php (not FCGI). Just out of interest; are you running the database and web server instances on the same virtual machine?

"[WordPress 2.5] came out of the box with a broken file uploader for a whole lot of people because of its required dependence on a Flash component."

Yes, it's dependent on Flash, but if you don't have flash it gracefully degrades to the old pre-2.5 file uploader. What's the problem here?

jumping topics...
"The problem is, besides the huge task of refactoring itself, it's impossible to change WP into something well structured without breaking *all* plugins and templates, and it's this ecosystem of add-ons that is major part of WP's success in the first place."

If the plugins properly use the hooks as they are supposed to, you should be able to do just about anything to the core backend without breaking them. Reworking the core would only break plugins that try to access things directly. Isn't that the whole _point_ of abstraction???

The more modular and manageable the web-app, the worst the database query efficiency.

Are you hosting with Godaddy? (as your WHOIS lookup suggests)

From their site it looks like they're running Windows 2003 on virtual dedicated, or do you know something I don't?

A. Freaking. Men.

Dive into the code. Prepare to be disappointed. Browse the Trac bug entries. Prepare to be upset.

Consider that Automattic just got $25 million in round B funding. Prepare to understand how dumb stuff like the subprime crisis is possible.

20 database lookups per page view is unforgivable. 20 times PHP had to contact MySQL, send a query, wait for it to be executed, get the results back and parse them into PHP-usable data. I've seen some blogs that had stats of up to 50 some database queries. Again. Totally unacceptable and unforgivable, given what WordPress is supposed to be doing.

If you have a 1,000 users, that means 20,000 database queries being executed unless you have some very tight caching going on there. And... this is considered acceptable out of the box?

In the open source world, if you want something, you *might* have to do it yourself.

Go for it Jeff!

The Roll Your Own solution works fine for a super-basic blog, but honestly, wordpress has a LOT of features baked in. The plugin system, auto-generated RSS feeds, creating "friendly" urls, letting you define the "friendly url" structure... categories, tags, permalinks, pagination, widgets... You'll pretty much need a team and a year or so of 40-hour weeks to get to where wordpress is today.

On the other hand, if you don't care about any of that... A very basic blog can be thrown together in about an hour, given enough familiarity with the language you're working in. I tossed together something that fit the bill for what I needed in Coldfusion in about a half hour (of course, CF is more of a RAD language for web stuff than ASP.NET, so mileage will definitely vary)

Also, you might want to check out some other alternatives: Pivot's also PHP, and I was a fan of it- only switched over to Wordpress because the Admin ui drove me nuts (they're working on that).

"blog.stackoverflow.com is getting, at best, a moderate trickle of incoming traffic"

trickle defined based on your stats? Or just on a hunch? Joel linked to it, and he's got an incredibly popular blog himself.

Also, how does WordPress handle or react to RSS? Could that pounding have anything to do with all the RSS programs your readers use? To say nothing of now all the iTunes instances hitting it for the podcast.

Thanks for the link to WP Super Cache! If you scroll to the end of that page you'll see a *huge* spike of traffic that was handled by laughingsquid's WordPress blog in combination with WP Super Cache.

This plugin goes beyond what WP-Cache does by creating static html files and then serving them with the help of a few mod_rewrite rules. With that installed even a small web host can survive a huge bombardment of hits.

Why is it not included by default? I'm not sure, but a few issues spring to mind:
1. Some people don't have access to mod_rewrite so the static html file functionality won't work.
2. Added bloat. Despite the CPU graphs above, a bare bones WordPress install works perfectly fine for many people. Why make it more complicated?
3. "Why doesn't widget X update immediately?" People expect things to update straight away. Full page caching defeats that unless you invalidate the cache for every small little change, or use Javascript. I recommend using Javascript, but the cache does invalidate for most of the major actions that happen on a blog. (Publishing a post or comment mainly)

You should look up the object cache stuff Ryan Boren worked on. There are memcached, APC and Xcache backends for that if memory serves. With that installed your blog can be fully dynamic and not hit the db.
Here's a pretty good overview of it:
http://neosmart.net/blog/2008/wordpress-25-and-the-object-cache/

I took the path of least resistance, and registered my blog with Wordpress themselves in the end (let them take the strain).

I've seen the same situation develop with several open source projects - as soon as you have different people pulling in different directions, you lose focus. The biggest problem with Wordpress is that there is no one core of developers in charge.

@mark - Drupal ain't no magic bullet. I maintain some relatively large Drupal sites and let me tell you, it has its own scaling and caching issues.

The built-in "Minimum Cache Lifetime" function is totally broken in the latest 5.x and 6.x releases and the Free Tagging functionality works in such a way that it creates several temp tables *on disk* every time you visit a tag page.

Comparing .Net to WordPress is apples to oranges. Heck, comparing .Net to PHP is peaches to strawberries. Once you say '.Net', you are talking about a specific framework which runs in a limited set of environments (i.e., Windows).

OTOH, WordPress is written to run in a very heterogenous set of environments. It can run under Window, Linux, BSD, MacOS. It can run under Apache, IIS, and a couple of other web servers -- just about anything that supports PHP and MySQL. It can run under pretty strict shared hosting setups, where the user might not even be able to modify the directory permissions necessary to allow caching. So I think it's at least a little bit forgivable that caching is left to plugins, for those who need it.

As mentioned above, checking the MySQL query cache (and other tuning) might be another area for investigation. The WP Object Cache is getting a rework, and is supposed to return in WP 2.6. I don't think it will turned on out of the box, but again, for those who need it, the underpinnings will be there.

Out of curiosity, I assume the .Net caching bits you mentioned are similar in nature to PHP's output buffering? So, you have to tell it where in the filesystem to put the cached files, yes? And I assume that this also means that you have to make sure that the web service has permissions to write to that location? Or does .Net make this a magic-bullet that you just fire and forget?

But seriously, there are a lot of layers of optimising you need to make WP run fast.

1. MySQL query and key caching will save you a lot of time. Most times a page is displayed and nothing has changed.
2. PHP opcode caching. There are several. I use xcache.
3. Selectable object cache. It's a little known fact that Wordpress does some half-arsed internal caches of intermediate objects; an even less-known fact that you can get it to use PHP opcode caches or memcached to hold those intermediate objects. This combination can really zip up the PHP side of things.
4. Reduce the number of plugins running if you can.
5. Don't put your blogroll, archives or author listings on the front page. Move them onto a separate page. Each of those listings performs a nasty old bunch of queries. Not single queries that reduce to a single result set; oh no, dozens of queries.

I agree that Wordpress is an evolutionary dead end. But unfortunately it currently does what I need it to do. I have Stockholm syndrome.

Email me -- jacques@chester.id.au -- if you have any other questions or queries.

Blame Canada...!

Unbelievably, there are people around there who value more the dynamic rendering approach of WP than, say, the Perl driven static philosophy of WP. If the cache stuff was built-in, I'd deactivate it for a number of well thought reasons. Unbelievably, there are also people who seem to handle slashdotting/digg/whatever on WordPress and a cache plugin. Go figure.

Why is everyone knocking PHP when the problem is the db requests coming out of PHP code and not the code itself... ?

Why else would caching help?

Maybe I misunderstood something?

Dare I say it - it's a characteristic fault of the open-source ecosystem: "I'll fix it when _I_ realize it's important." (Curiously similar in this respect to Big Software.)

And CPU-hogging isn't the only hidden failing of WordPress. I'm moderately familiar with (X)HTML/CSS, yet I'm continually baffled by the uncommented, undocumented, messy and highly individual CSS coding of WordPress theme authors. In stark contrast, TypePad is wonderfully slick and comes with decent support - TypePad's tech people may be a nonchalant, superficial, and lazy, but they'll deliver the answers if you goose them hard enough. And it's worth the money. For blogging newbies who plan to tweak their themes, WordPress is the worst possible choice; TypePad is the only way to go.

I'm too far down to expect a reply (:/) but I'm curious why you didn't use a .NET blog (like blogengine.net).

That just seems more likely considering the source.

@Jheriko

You're right, there is a fundamental problem with WP making 20 db calls; however, caching would help because WP wouldn't have to go out to the db to display the article, it could grab it from the cache - therefore utilizing less resources.

"Unbelievably, there are people around there who value more the dynamic rendering approach of WP than, say, the Perl driven static philosophy of WP. If the cache stuff was built-in, I'd deactivate it for a number of well thought reasons. Unbelievably, there are also people who seem to handle slashdotting/digg/whatever on WordPress and a cache plugin. Go figure."

Why do you need dynamic publishing for most blogs? If it gives you warm fuzzies or you have a real reason for doing so, that's fine, but seriously, why do you need dynamic publishing? The very fact that you need a cache plugin to handle a link from slashdot or digg is a bad sign about the nature of dynamic publishing.

@Dougal: It's actually along the lines of the "magic bullet". You just add a declaration at the top of the page and the framework does the rest (google for "asp.net page cache" if you are interested).

I agree that WP-Cache should be standard install. I've been feeling that way for a couple years now, ever since my own blog's performance problems demanded that I install and configure it.

And in arguing the merits of WordPress vs. other services, it often comes up "But you just have to install WP-Cache." Yes, but you do just have to install it. And that sucks.

So it's making 20 database calls? That's all I/O. Why is the CPU doing so much?

Ask yourself this, is a database really required for a blog?

An average engineer adds complexity, a good one removes it.

What is wrong with static HTML?

Simon

It's clear to see that the open-source movement combined with the added code reuse capabilities of OOP are working towards reducing development effort. "Write your own blog software" is getting as many votes as "Install Linux, PROBLEM SOLVED".

What if he installed Linux, customized the kernel so that it was highly optimized for hosting a blog, wrote his own web scripting language (with caching built-in), then wrote blog software using that language? It might take a few years, but then his blog would be *optimal*.

Or maybe WP could fix their product so that he can click a button and have a blog ready for him, instead of wasting months reinventing a wheel that comes in 31 flavors already?

"So it's making 20 database calls? That's all I/O. Why is the CPU doing so much? "

No, it's not. First of all, MySQL has to execute the statements, which includes finding and possibly modifying data. Second, PHP has to wait for MySQL to finish and parse the results into a format usable by the PHP script.

I recommend using a PHP op-code cache, like xcache. In my experience, it can cut CPU usage by 75%.

I also recommend switching to Drupal ;)

Will every one saying "don't use Windows/IIS use Linux" JUST FUCK OFF!!!

Please.

Might have been posted here already, but I'd highly, highly recommend Drupal. I'm 3 months into learning how to use it and Wordpress (AND MovableType) pale in comparison. So much so that I'm re-doing my Wordpress-based blog in Drupal at the moment :)

I agree agree with Simon. The blog should be static pages that get refreshed every once in a while. It could be after every blog post or on a timer (like every 30 seconds). Put a cache header on the page to say not to cache this page, then all the load is on the web server servers static page with some load on the database for querying the content and rendering the web page (rendering could occur elsewhere).

I once worked on a content site that we updated nightly. It was very fast because the pages were static. Version 2.0 used dynamic queries for everything and it made the site much slower (user complained all the time about the performance). I beleive the better solution would be to keep the static nature of the site but refresh or content more frequently or refresh sections when the content was updated instead of a totally dynamic site.

Blogging and blogs are content and mostly static, so a dynamic retrieval engine is probably not needed. Every time you make a call into the database it is costly regardless of OS, platform, or RDMS.

blog articles themselves may be static, but blog comments are not. therefore a db is needed. and i'm pretty sure jeff would want a comment section on his blogs.

i had to switch hosting company to get wordpress to run smoothly. i'm now on a linux server. yes, windows server *can* run php, but there are limitations.

>blog articles themselves may be static, but blog comments are not.
> therefore a db is needed.

In some cases a database is appropriate. Doing something like Reddit, Slashdot or Digg without a database is just silly.

However, for most blogs, you still don't need a database even if you allow comments. Why not just update the static HTML file with the new comment?

Using a database should not be automatic. They're hard to set-up, hard to design right, use lots of memory and CPU and are difficult to scale.

Even for sophisticated blogs, you probably want to write the changes to a database then update the static files as necessary. You don't want the brunt of your web-requests hitting application code unless it is required.

Simon.

I'm a huge fan of caching, I even use it for dynamic sites because it drops your serverload to almost nothing. For example, I recently build a site for company with loads of active trackers. I needed around 11 DB calls (including making the connection) but because of the nature of the site MySQL's query cache was almost useless and the 5-10 visits per second during office hours quickly brought the server to it's knees. I enabled Smarty's (http://smarty.php.net/) caching mechanism with a cache validity of 2 seconds, and now it's working fine. The temporary files are written to and read from a ramdisk until the new server arrives with a much faster I/O setup, and the CPU load is now around 20-30%. Because of the low cache validity of only 2 seconds the information is still almost realtime, and my customer is very happy with it.

congrats you are now result 4 on google searches for wp cpu usage!

@Donny, thanks for posting the link to BlogEngine.NET - it looks like an interesting WordPress alternative. I'd much rather work in a .NET environment than php.

I'm currently running WordPress 2.3 on IIS, and it took quite a bit of fiddling to get WP-Cache working. If anyone is interested, I posted the steps required to get it working at http://www.fanrastic.com/archives/2007/06/06/wp-cache-up-and-running-on-iis/

"Even for sophisticated blogs, you probably want to write the changes to a database then update the static files as necessary. You don't want the brunt of your web-requests hitting application code unless it is required."

it depends on the nature of the blog site, and how the author intends to run it. For me, i like blogsites that show comments instantly, because on a lot of popular blogsites(very much like jeff's) there are always conversations going on, in within commenters.

again, i think it really depends on the nature of the blog site.

Well, since you are using IIS7 why dont you just use output caching, its provided by iis and can be setup through the iis console, or through the web.config file. iis.net should have some screencasts on it.

Its pretty slick, you can even set it up so that it creates a cache for every combination of query string variables.

I work for a web hosting company's tech support.

Why the hell does wordpress store all the posts in the DB anyway? It's not a forum, and it's completely unneccessary. The whole thing could be rewritten not to use SQL, it would run better and use 1/3 the cpu/memory/resources.

Many web applications do these excessive queries. The caching system is most important but other things in PHP such as OPT Code caching will increase performance an average of 30%.

Make sure your WordPress database isn't collecting spam comments. Don't forget to back up your database as well because my hosting company hosed my site and I had to use search engine cached pages to restore my old posts. I'm using SQLyog to export a SQL Dump.

While backing up the MySQL database I saw that the comments table had a lot of records. I discovered that by entering spam keywords to filter comments I was essentially hiding them from the usual moderation procedure. Now I have to run a query to delete comments marked as spam.

Quite a few MovableType users in shared hosting complain that though the static page does boost the performance, the process of staticization consumes too much memory and CPU usage, and got killed.

That is kind of ironic.

I'm extremely amused by the linux fanboys on here. I can guarantee that 99% of them have never used IIS, let alone IIS7.

IIS7 is currently the fastest application server to run PHP on, how fast? Try 800 times faster:

http://blogs.iis.net/bills/archive/2006/10/31/PHP-on-IIS.aspx

That said, PHP sucks, mySQL sucks, and Wordpress sucks. All three are a beautiful catastrophe of sloppy coding that scale by throwing obscene amounts of hardware at them.

I'm sorry. Did you say *Windows* and *PHP* and *lighttpd*??

*Windows*?? For hosting?

On other notes, I do agree that IIS can be made to run PHP nicely. However, surely WP blogs are one example of where caching can be *far* more aggressive than other situations due to almost complete lack of dynamic content bar comments, which are exceptionally simple to implement.

Did you get into computers so that you can sit in the corner and wank over windows verses linux or php verses .net?

How does this graph show anything?
Where are the metrics?
What are you measuring?
What is your bias?
What are your baselines?
Are there any affecting/impacting parameters?

Simple scientific methods would make you a laughing stock of the science community if you presented this shitard piece of work with little to no supporting documentation (geez reminds me of the typical consultants I clean up after)

Here's a graph of performance before on an IIS install with php:
|===========

and here it is after I rebooted:
8==D

here it is after I installed colinux on my windows box with php in a VM:
8=D ~

wahahahahahahahahahaha

About a year ago I did some heavy customization of word press and all I can say is....

WHAT A ROLLING PILE OF CRAP!!!

I'm sorry, MAYBE it has a good user interface (not really, but it get's the job done some of time..)

What really drove me nuts was the code.
Wordpress' coding framwork... isn't a framework. A bunch of files randomly sewn and included together that somehow manages to produce a page. UHG!

The sad bit is, IS one of the best things I've seen so far.

If I had to depoly a blog tho, I'd use Joomla. It's WAYYYY more than you need, but there are awsome plugins.. and your blog can grow if you need it to.

Another thing I've done is manually edit my themes. A lot of the database calls are from PHP code that can just be written into the theme. For example, why not just edit the title of your blog in the theme. Not only do you avoid a DB call, you also avoid some PHP code!

Thanks a ton Jeff, I had no clue that wordpress didn't have a solid cache. I have wp-cache running on all the blogs I manage now.

Thanks again!

graffiti CMS FTW.

This thread is so frustrating because Jeff is getting flamed but not for the right reasons. WTF does windows vs linux have to do with anything?

What really annoyed me was:
"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."

So right there you went from "Wordpress sucks" to "PHP sucks and ASP.NET is much better". Now I'm not a fan of PHP but that's a giant non sequitur if ever I saw one.

All those people suggesting Jeff install linux are missing the point btw, wordpress scales badly on any platform. The only reason it's so popular is because it managed to get some nice themes going and has a large addon community. Performance wasn't on the developer's minds. So now everyone seems to be stuck with it.

@Khi
Your memory problem are surely related to apache more than wordpress.
I've modified my apache server to the threaded MPM, and lowered almost by 5 my memory usage:
http://www.webalis.com/2008/04/what-can-do-a-threaded-server-for-a-memory-hungry-application/

Someone asked about handling RSS traffic. I recommend Feedburner for this. They will cache your feeds and do other neat things if you want them.

"it depends on the nature of the blog site, and how the author intends to run it. For me, i like blogsites that show comments instantly, because on a lot of popular blogsites(very much like jeff's) there are always conversations going on, in within commenters."

You don't have to cache the whole page. An alternative would be to cache everything except the comments.

"IIS7 is currently the fastest application server to run PHP on, how fast? Try 800 times faster"

That was because IIS can cache requests in memory, so that it never involves PHP in the first case... So what you are saying is that if IIS can output HTML directly from memory, it is faster than executing a PHP script...

Using a memory cache is not something new, and there exists solutions for that on any platform. That it took Microsoft so many years to implement it themselves, is not somthing to brag about.

Ah, yes, this happened to me; I responded by moving to MovableType and eventually Blogger; spam was getting to be a big problem, and I didn't want to deal with it myself.

The funny thing is, Wordpress used to be far worse, speedwise. Until quite recently every page load involved lots of MySQL cache-busting queries...

This is why the people who think that relational databases are the bottleneck are wrong.

http://codeeleven.blogspot.com/2008/04/why-relational-databases-end-up-being.html

wait until you your site gets hacked, there are so many security holes in this thing is not even funny

Yes... wordpress always was one of the most CPU loading CMS. But it useful. And it do wordpress popular.

best regards,
<a href="http://abcbasket.com">Giftman</a>

Bad coding in WordPress? You're kidding ... :D

That's why I'm so happy I switched to a Windows environment so I could discover, and use, BlogEngine.NET ( http://dotnetblogengine.net/ ).

What percentage of hosted Wordpress sites get Dugg?

What percentage of hosted Wordpress sites get >1500 visitors/day?

What percentage of hosted Wordpress sites use more than 5 plugins? (or ANY plugins?)

The power of Wordpress (and the value) is found in a CMS that is easy on the novice, is easily extensible, and empowers people to communicate in ways beyond their technical skill.

So hey -- let's slobber all over ourselves while gnashing at the project, because it doesn't elegantly scale for those one-in-a-thousand sites that EVER gets a DiggStorm. Let's have a party over the grave of a platform that can't be all things to everyone.

Is the coding somewhat spaghetti? Yes.
Do I wish it were more consistent? Yes.

Now let's talk about a couple of possible solutions you HAVEN'T mentioned yet.

First, there are many unnecessary calls that come about in the themes. Blog title, RSS feeds, and other information that should not change should be tweaked. Once you decide on a theme, replace the PHP with direct links and text. It's not that hard. Also, the "queries and time" in the footer is just more unnecessary DB calls. Ditch them.

Ideally, there would be an admin panel option that would replace these specific things in the header and footer. Actually do a find-and-replace of those specific pieces.

Second, I've seen a noticeable improvement when using one of the AJAX plugins. No need to call header-footer-sidebar every time to click on a different post.

Third, blogrolls. Either stash them and tend them externally, or ideally get rid of them. They serve little purpose these days. Unless someone comes up with a better way to cache them.

Wordpress is a Ford Taurus: suitable for most people, and it CAN be tricked out for NASCAR if you know what you're doing... but let's not bash it because it's not a Formula-1 racer out of the box. Most people can't afford it, and it's too much horsepower to carry the groceries.

Is Apache on Windows any better than IIS for Wordpress?

One of the main problems with PHP is that it doesn't maintain a cached version of the page by default, whereas other languages like Java, C# and Python do. So each time a user makes a request, not only does it make those 20 database calls, but it also recompiles the PHP script, which is extremely inefficient. By installing APC or e-accelerator, you can make it so that PHP stores the compiled version of that script in memory, and only recompiles it when the code actually changes.

However, note that these opcode caches are relatively unstable, and sometimes will segfault (at least with Apache, I don't know about IIS). I personally have a script that checks the Apache logs every minute to see if it has segfaulted, and it then restarts Apache if so.

Another thing that will make a HUGE improvement is enabling MySQL query caching. It stores the results of all SELECT queries until the underlying data changes, so that the results are pulled using an O(1) hash operation, rather than actually re-running the query.

Also, Zend Optimizer can optimize the PHP scripts in a way similar to how a compiler does, so that helps it run a little faster.

I find that using Zend Optimizer, an opcode cache and MySQL query caching leads to huge reductions in CPU usage (depending on your site, can be on the order of 10x). For each request, it removes the compilation of the script and the execution of the common SELECT queries from the process, which is where the bulk of the time is spent.

For further reading about this, I highly recommend the following two books:
http://www.amazon.com/Building-Scalable-Web-Sites-applications/dp/0596102356
http://www.amazon.com/High-Performance-MySQL-Optimization-Replication/dp/0596101716

More from the masses:

Why not use BlogEngingeDotNet? All C#. All MS.

FROM: another satisifed user of BE.NET.

I have to say that this scares me as i've recently created a blog myself with wordpress.

Interestingly enough, Matt DID think about including Wp-Cache in the CORE wordpress code at one stage, as written here:
http://ma.tt/2005/05/wp-cache/
Anyway, I never got bothered by the CPU limit as much as by the MEMORY limits... but caching solves them both.
Of course writing better queries and database structure would help a lot too. WordPress is very popular as it is EASY to understand (it grew more complex, but started VERY basic and easy years ago) and that initial simplicity, together with the APIs, made the plugin ecosystem/community possible. Therefore it became popular. But I won't call it really "polished". Who cares, anyway. I have been using it for years with pleasure, but I have that on Linux. If I had the luck of a Windows Hosting, I would give GraffitiCMS or subtext or dasblog a try.

I can sympathize with the WP folks. When I am writing a web application, I don't want to also be writing the platform it runs on at the same time. It's not exactly clear what sort of "caching" the author is talking about, but whether it's caching of DB results or rendered pages, it's not really something I would expect to care about as a web app developer. It should be handled by the platform.

But then, I don't use PHP. ;-)

I couldn't get wp-cache or wp-super-cache to work on my wordpress-blog at http://am.aurlien.net, so I ended up using hyper-cache (http://wordpress.org/extend/plugins/hyper-cache/), it works great.

Is the database on the same server? Seems like that may be another culprit if so...otherwise, if the DB is on another server, then I'd have to ask what the heck WordPress is doing that requires all of that CPU?

I don't know or care about WordPress and do not doubt for one second that the insides are something like a steaming pile of burned lentil soup - however, this post reminds me of a fellow at our LUG who was complaining about how slow rsync was with lots of files when running under cygwin.

Perhaps I should try running a large DotNetNuke site with Mono on Debian unstable inside a Windows 98 Virtual PC and write a blog complaining about how bad it is.

WordPress + WP-Super-Cache + server running LiteSpeed = super-fast, solid site. Fireball-proof. ;)

Also, there's a lot you can do to remove redundant DB queries in a custom theme vs the standard theme files.

I agree caching should be rolled into the core, though.

Hey Drupal Fanboys,

Drupal is not the answer and is sometimes even more egregious, especially when the PathAuto (a must for SEO) module is deployed. And if you use Views (which most installations also require), a simple block with it can throw your queries through the roof (as many as 80 more per page). So drupal is not the answer to performance in any stretch of the imagination and its blogging tools are atrocious, lacking even fundamental features bloggers need. Not trying to start a holy war, but having used both at the enterprise level (30 - 80 Million uniques a month on some of our sites), I kind of have a handle on what it means to scale either one of these open source apps.

As far as the whole thread goes, Windows/IIS is a poor choice for PHP in general, much less for high traffic php apps. As you noticed a similarly equipped linux server can chew through it even more. Further more, 'CGI' PHP is slower overall from 'Module' PHP, and is another thing skewing the results.

>>"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"

Actually, WordPress 2.5 does have just that sort of thing built right into it. It's called the object cache:
http://neosmart.net/blog/2008/wordpress-25-and-the-object-cache/

Here's the key though.. Where do you store your cached data?

The caching solutions you're talking about are "whole page" solutions, which cache the resulting HTML output of page generation and serve it up instead of regenerating the page. WP-Super-Cache is particularly effective at this, but does indeed rely on running Apache with mod_rewrite (the current most popular webserver combination).

The built in caching in WordPress is an object cache. Data retrieved from the database is stored and saved somewhere else. But, by default, WordPress does not attempt to tell the user where they should store that data. It's a framework, with several possible plugins for just that.

See, back in previous versions, WordPress had a built in cache that defaulted to storing the data in a local cache of files. This helps somewhat, but for the most part, it's not helpful. Storing data in files and retrieving them from files incurs a lot of disk I/O. And what is a database server but something that does much the same thing? So that was ripped out of 2.5 and the generic platform for object caching was put in instead. It can cache to a number of different things, including persistent and fast memory (using memcached). A plugin does exist to cache objects to files though:
http://neosmart.net/blog/2008/file-based-extension-to-the-wordpress-object-cache/

But on the whole, this is not going to reduce your CPU time, because you're still generating the page. Database access is not the CPU limitation on most hosts, as the database is usually on another server entirely. Thus the need for whole page caches.

Incidentally, WordPress provides the necessary hooks specifically for whole-page caching. This was designed in, not some sort of "hack" that was done by these plugin programmers.

WordPress is designed, from the ground up, to be a *base* of systems, not to be a complete and total system in and of itself. WordPress does not do everything, it just does one thing as well as it can. You don't use can openers on luggage, do you?

> Wordpress' coding framwork... isn't a framework. A bunch of files randomly sewn and included together that somehow manages to produce a page. UHG! ... If I had to depoly a blog tho, I'd use Joomla.

$irony++;

I used to blog and got out of it after using both WordPress and Movable Type. I agree with your comments about WP, and, in fact, they can be extended to cover any blogging engine that goes to the database every time a page is refreshed.

The WP approach makes life easier on the blogger because it eliminates the need to wait on static page rebuilds everytime new content is posted. But, as you point out, the burden is then passed to the blog readers, who are made to wait while WP makes those redundant database calls.

Certainly, the host I used sold lots and losts of shared space to WP users, but told anyone who asked that those sites would go belly up as soon as they began to get a lot of incoming traffic. While they didn't push MT, they acknowledged that a large MT blog running on a fast non-Apache server would very likely survive its own popularity.

Jeff, how do you explain wordpress blogs surviving multiple social bookmarking front pages (digg, stumble and delicious) while on shared hosting?

I did it at least 10 times, and it never crashed.

By the way, I did that with no cache plugins whatsoever.

Umm, database accesses are just that, no matter if it's mySQL, SQL Server, using PHP, .NET, Apache, IIS....

Unneeded db accesses are just bad design.

I love all of the comments about running PHP on Windows being the problem. 20 database hits per page? I'd be hung if I wrote code that did that. There is no way to reconcile the fact that this is not necessary and expensive.

Jeff, I'm not sure if you are aware, but running PHP on windows is not only slow, but emboldens the terrorists.

First of all, I don't see the big deal with installing WP-Cache separately after installing WordPress. After all, it IS a UNIX program. In UNIX, everything is an option - nothing is forced on you, unlike Windows. I'm sure there are cases where WP-Cache is not wanted, or, more likely, people want to be able to pick which caching plugin they want to use. Because of this, it's better that it not be included by default.

Besides, why are you using Windows Server? I mean, Windows is a mediocre OS for the desktop, at best. But Windows SERVER? Those two words just don't go together in the same sentence. I'm sure you'd get much better results from KVM+JEOS, or just a straight up Debian, SUSE, Slackware, RHEL, or Gentoo install, if you don't want virtualization.

20 lookups isn't good, but I wonder how some of the plugin appearance widgets will work without some lookup overhead.

Beyond that, we have a couple of Wordpress mu (multi-user) sites set up and the processors aren't even breaking a sweat. There not big sites either, but one of the is serving health lecture podcasts and is incredibly popular (I am assuming the RSS generator is dynamic as well and should be putting a load on the system) and another RSS feed is in the default display of our portal system that gets thousands of hits a day.

We're using unix/apache.

Is there something special in that mix that separates them from Jeff's situation?

Blah blah blah rabble rabble Linux rabble Ubuntu blah blah rabble blah Windows Server!!?!?!?? Blah blah corporations blah blah blah inferior blah freedom blah blah borg blah blah blah fascists rabble rabble!

Blah blah STOP USING WINDOWS NOW!!!!!

Now I'm going back to slashdot.

WordPress optimization is horrible (or shall I say there's no optimization?). Earlier, I used to worry about even the size of images in the theme design, but have since forgotten such things because optimization (or the lack thereof) of WP is a bigger matter.

For what it's worth, I might add that the Super Cache plugin does an incredible job (it creates actual HTML files, a 'la MT).

I survived two medium-sized diggs on Dreamhost (ha!) with Super Cache. So, I am sure that Super Cache can handle half a million hits or whatever in a day on a better host.

As for Daniel Scocco's comment above ^, I personally know that his host is Doreo (and I am on it too, now). They are a small but reliable company, and servers are blazing fast.

Last week, I survived 2200+ diggs on a post without any caching plugins. Of course, lesser hosts would've crumbled (for example, Dreamhost), but it shows that the host is to be blamed too (for cramming hundreds of sites per server and overselling).

Just wanted to say that the issue is not actually in the wordpress itself but the enviromment it is used on, but there's plenty such comments...

I'm also curious to know why you never spoke anything of MT's vices in optimization (there's atleast some).

How about, um, rebuilding the cache?

Vladas: Because running it on linux would somehow decrease the number of queries how?

I used to have a number of sites running WordPress on various shared servers (Linux), and when traffic spikes, CPU usage goes through the roof (WP_Cache has a problem in 2.5 with .gzip; I haven't figure that out yet), Shared Hosts get panicky, and close down sites-- pretty much like everyone else's WP site with traffic.

I decided to dump WP and move all sites to ExpressionEngine (running on Linux and Xserve), which has a highly effective multi-level caching system. Rock solid, even with regular DIGG hits. EE has a price tag but the benefits out weigh the dollar cost. Love it.

"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."

That's one opinion. I know where he's coming from -- a lot of stuff we can't control from within WordPress. We can't install a PHP opcode cache or set up MySQL's query caching (two huge legs up for any PHP/MySQL application). But the simple fact is that HTML output caching (a la WP-Cache, WP-Super-Cache) makes a huge difference in the performance of a WordPress site, whether the server is correctly configured or not. We're talking almost two orders of magnitude. I agree with you -- I think that it's high time we had an HTML output caching system baked into core. This issue is going to be tackled by a Google Summer of Code applicant, under guidance from senior WordPress developers.

Jeff, at far as I can tell (by using Alexa), this "trickle" is hundreds of tousands of page views PER DAY.

I see typical "just use linux" comments, with backing. Well, here's some backing: varnishd. It's a smart front-side cache that relies on a smart virtual memory system. Now, WordPress still needs to set cache-control headers properly, but that's a much easier solution than implementing fine-grained caching of database resultsets.

At the risk of starting a language war, I think you'll find the problems start deeper, in the roots of PHP itself.

PHP on windows has long been a notorious poor performer and when I tried it with a phpnuke variant for simple blogging, it was pretty much unusuable it was so slow.

Combine that with the poor design that PHP's flexibility encourages (and the PHP community seems to embrace as a whole) and you wonder if the main reason linux users aren't screaming is because you aren't supposed to complain about free software, under penalty of excommunication.

I like VB.Net based dotNetNuke for content management myself, but the blogging engine that comes with it has caused me nothing but problems thus far (outright cpu spirals into the ground site crashes that may be involved with my inability to configure it correctly, rather than a product flaw, but that still speaks to a fundamental product weakness in my mind) Shame really, otherwise I suspect it would be more popular than it is already.

I'm the student working on the gsoc wordpress project to integrate caching into wordpress out-of-the-box:
http://code.google.com/soc/2008/wordpress/appinfo.html?csaid=7E1A38664ABC103C

I've done some research into wordpress caching and why it isn't in the core (yet). The penultimate reason is exactly the problem Jeff is having with the plugins - support for myriad of different Wordpress users. Sure, it may seem like everyone and their dog is running a LAMP stack on a virtualized host. In reality, a substantial portion of the users are shared-hosting users, installing from their control panel with one click. Those people can't be expected to find and understand the "cottage industry" of caching plugins out there. 99% of these users don't hit digg, but 1% of the wordpress userbase is a lot of people and a lot of horror stories.

On the flip side, Wordpress.com is running wordpress as well (surprise!). They host almost 3 million blogs. Yes, they have memcached clusters. The NYT runs wordpress as well.

Whatever out-of-the-box solution will need to cater to the shared-hosting, IIS users as well as flexible for the wordpress.com, blogs.nytimes.com, etc users (to implement their own solution, for example). This is difficult to do, requires a lot of time and planning and support from the community.

I'm thinking that a summer of code project would provide much of the impetus needed for such an endeavor. By August, I hope the out-of-box wordpress performance won't be as dismal.

Read more about it at http://neodude.net/archives/2008/03/caching-in-wordpress

Your metric of 20 queries per page refresh is conservative and optimistic at best. I've seen Wordpress installs that do upwards of 60, and, in one particularly disheartening case, about 120.

how are you virtualizing the windows box, and how many virtual servers do you have on the one bit of hardware?

Most forums of 'full virtualization' (as opposed to paravirtualization, as I use to run Linux virtual servers) are fairly expensive, performance wise. have you installed the paravirtualized drivers for disk/network on your windows box?

> congrats you are now result 4 on google searches for wp cpu usage!

You're right -- that's *hilarious*.

I am collecting feedback and I will post an update at the end of this entry once I've collected it all.

My hope is that something constructive will come of this -- that the WordPress team will realize how important caching is and how it needs to be folded into the core, like, yesterday. The Summer of Code information is a great start!

> PHP on windows has long been a notorious poor performer and when I tried it with a phpnuke variant for simple blogging, it was pretty much unusuable it was so slow.

It's a totally different story with IIS7 -- Win2k8 is a first-class PHP host.

http://blogs.iis.net/bills/archive/2006/10/31/PHP-on-IIS.aspx

Honestly, I can't say enough good things about Windows Server 2008. I've been extremely impressed with it. People found Vista underwhelming, but the newest iteration of Server is substantially better than 2003. And the "Web" edition is reasonably inexpensive, though not free like the *nixes..

>It's a totally different story with IIS7

Do you work for the Microsoft press department or something? While Microsoft is completely willing to sacrifice any prior products if it helps sell the newest outing, I'd expect more of someone in the industry.

Firstly, FastCGI is available for all contemporary IIS versions. Secondly, FastCGI is fast *compared to CGI*. If you don't need CGI isolation, it's slower than ISAPI, and of course there has been an ISAPI version for time eternal, and IIS 6 has fantastic ISAPI.

The new caching features are novel (though kernel caching exists in 6.0) and nice. It's also interesting to note that you can get IIS 7 in Vista (albeit with the normal limitations).

Anyways, yeah -- RAH WINDOWS 2008! REVOLUTION!

Most sane people realize that microsoft is evil moto is not the best way to bring down the System. I do not even see google "not be evil" moto anymore.

I'm in agreement, platform aside, given enough stress WordPress falls on its face. I have seen a site driven by WP on a LAMP install fall on its face without caching enabled. The load average on the machine was HUGE compared to while caching was on so it is not just a Windows/IIS thing.

While I agree that having caching out of the box (as a non-default option at the very least) would be a -good- thing, I still have to ask "What have you done to clean up your wordpress theme?". My not-fully-optimized theme has 12 queries for a single-post page and 6 for the frontpage. Could I drop it lower? No idea, but when I'm done I'll let you know.

Kevin

Quit dicking around and install BlogEngine.NET or Graffiti.

I use Drupal extensively at our company and I love it - clean, well documented code, great features, great community, and fantastic flexibility.

That said, a standard Drupal 6 installation with no custom modules runs about 60 queries per page view. My local PC that I use to develop:

Executed 59 queries in 114.35 milliseconds

Just to view the front page. An actual site that we run runs 100s of queries per page view, in less than 500ms.

Now, my attitude is that while it would be better to run very few queries per page, it is entirely immaterial if pages render quickly and reliably. My biggest site gets 500 uniques a day, so I am yet to experience any major growing pains. Drupal seems to scale brilliantly, with some VERY big sites running on the system without any high-profile performance issues.

The point I am trying to make is that I think developers can get very narrowly focussed on the 'proper' way to do something, when all that really matters is the result. I am as guilty as anyone. Your users don't care that you managed to serve them a static cached version of the page, they just want the site to load quickly and work reliably.

WordPress is ugly as sin under the hood, but I think it has proven itself as a very, very capable blog platform. Similarly, a purist would say Drupal is a terrible platform because it runs 100s of queries where perhaps a few would do. But, it is easy to maintain, easy(ish) to use, and creates great sites.

Saying that a platform that runs 10s or 100s of queries is straight 'bad design' when the evidence suggest otherwise is simply elitist.

OK, so it's just my home computer, but I installed Appache, MySQL and PHP on Windows XP ... then I switched over to Ubuntu.

Apt-get and the synaptic package manager made installation much easier than I was expecting.

I found that the Linux versions of applications seemed to have fewer bugs (stored procedures didn't work in the Windows Version of MySQLAdmin).

The HowTos had command lines that I could copy and run under Linux.

L-A-M-P, they were designed to work together, so I asked myself, why only go three quarters of the way into open source?

>L-A-M-P, they were designed to work together

LAMP was a retronym coined for a particularly popular stack of software (each having been developed entirely independently).

> LAMP was a retronym coined for a particularly popular stack of software (each having been developed entirely independently).

Apache was built to run on Linux, as was mysql. PHP was built to run on Apache. It may be a retronym, but they are all very closely linked.

>Apache was built to run on Linux

No, it wasn't.

>as was mysql

mysql was originally built on Solaris.

>PHP was built to run on Apache

No, it wasn't.

>but they are all very closely linked

Actually, no they aren't. PHP for years was run predominately as CGI, which is basically as unlinked from the webserver as possible, and to this day has its own world of configuration separate from the web server.

> Actually, no

Damn, you're 100% right. Still a great platform though :P

Why not just turn on output caching from the IIS7 Output Cache module? You can even turn on kernal mode caching. Should take just a few minutes.

Jeff, is it possible that you put "moderate trickle of incoming traffic" into some numbers, so we can understand how severe is the problem?

Thanks.

I'm developing a bigger project based on wordpress, so I'm alarmed reading this excellent post. I'll try these plugins and hope they'll help me out.

http://modechecker.de/

Thankx captaion of "coding horror", i've enabled my wp-cache. Cheers and keep up the good work.

Wordpress is utter garbage. The only part that doesn't suck is the installer. Moveable Type is greatly superior.

Jeff, if you really do read all the comments you get, my condolences.

The following isn't meant to absolve the Wordpress team of responsibility, and is coming from someone who (in part) makes his living with PHP, usually in a LAMP style environment, and usually cleaning up someone else's mess (because it's more lucrative than making a mess of your own).

It's not just Wordpress. There's a lot about PHP, both as a platform and as a culture, that results in rank abuse of the database.

First and foremost, the early history of PHP is linked closely with the business of shared web hosting. When you're writing an application where that's your target and you need to write something down, you have two choices. The file system or a database. Since using the filesystem comes with a set of security and configuration headaches, the database quickly evolved into the go-to place to store, and later serve, information.

For a lot of PHP programmers without the formal CS or programming background, this is all they've known. For a lot of PHP programmers **with** a formal CS or programming background, they face an uphill battle maintaining legacy applications while at the same time facing the never ending onslaught of new feature requests/demands. Do you rewrite something that works most of the time and can be made to work when traffic spikes come along? Now you're in holy war territory (http://www.joelonsoftware.com/articles/fog0000000069.html).

Wordpress is a legacy application. It's been around since 2003, and is the official fork or the b2\cafelog weblog software which was started in 2001 (http://cafelog.com/index.php). It is, at it's core, a **PHP3** application, with a pile of evolutionary OOP thrown into the mix over the years. It's easy to say "Hey, wtf, where's caching?", but the team placed its priorities elsewhere, and it's hard to argue with their success.

To the larger issue of PHPs red-haired step-child status in the developer community, it's important to remember it brought two major "value propositions" (ugh word) to the table.

The first is horribly cold hearted, mean, shortsighted, something no one likes to hear, and is 100% true. In a market where a professional .NET, Java, or perl/python developer will cost a company $80,000/year, they can find a PHP developer willing to work for $50,000 a year, and get the same immediate results. Yeah, they're probably setting themselves up for real pain when it comes time to scale and there'll be code that will haunt future developers for years to come and OMG security but American business (in general) is horribly focused on the short-term.

The second value proposition is a bit more heartening, although a lot of people will disagree. Like all the big shifts in programming, PHP enabled a new class of people to use code and develop software that solved a problem they were having, problems that the CS-community wasn't (again, in general) interested in. PHP and those early, hacky perl scripts (Damn you Matt Wright!) laid the foundation for the social-web as it exists today.

I'd blame PHP. Its a horrendous language.

http://pankaj-k.net/weblog/2008/03/did_you_know_that_each_integer.html

Alexander: "You'll pretty much need a team and a year or so of 40-hour weeks to get to where wordpress is today."

A single decent engineer could do it in about 2 weeks with sufficient caffeine, and the code wouldn't suck nearly as much. WP is such a disgrace it deserves its own thedailywtf section.

Cris: "I'd blame PHP. Its a horrendous language."

PHP is fine. Bad developers are the problem. Yahoo!, Facebook, Flickr and others have made it abundantly clean there's nothing wrong with PHP as long as a real software engineer is writing the code.

Has anyone ever conducted a comprehensive comparison study of the resources used by the various popular CMS: Wordpress, Drupal, Serendipity, MovableType, Joomla, Textpattern, DotNetBlogEngine, DotNetNuke. If Wordpress runs very inefficiently out of the box, how much worse does Wordpress run relative to other options?

someone: "blog articles themselves may be static, but blog comments are not. therefore a db is needed."

Not true. You could process your form and append the comments to a text file in your file system. Not that you'd want to, but the db is not an optimal content delivery method in a lot of cases. It's great for storage, but for reading there's some overhead you can sometimes do without. The reason people jump to the database is because that's all they know, not because it's the best solution. That's why there are so many caching mechanisms--it just ain't all that.

Thanks for this - I will be following your advice immediately!

Um.... your issue is clearly not Wordpress. It is clearly Windows.

I run wordpress on multiple sites and various servers (all linux) and I have never seen such results on the CPU. I don't run the caching plugins because they aren't necessary... not for a moderate trickle of traffic at least.

If I was running a high traffic blog.... I would look for some other solution... or most likely just beef up the server it was running on... as would be the case for any high traffic website.

I'm finding these “it's doing 20 database round-trips”comments hilarious, in context.

A few points:

1. Yes, it's Windows. Suck it up. Yes, it's virtualised. Look at the specs of the hardware. A 486 should be able to serve these pages without breaking a sweat.

2. 20 trips may be bad, but they're 20 insignificant trips—or should be. Given the size of the blog and the miniscule amount of data involved, the whole database will pretty much live in RAM, which means the RTT for any one of those queries will be measured ten-thousandths of a second. That is, unless the queries themselves are problematic, which is entirely possible.

3. MySQL's in-built cache is good, but it shouldn't strictly be necessary. If you're using MySQL (and it's on the same host)—and I'm assuming you are, because WP isn't particularly database-agnostic, try turning it on and seeing if the CPU load drops off: if so, it's the database that's your problem.

4. I'm particularly unconvinced by Windows being an “excellent” platform for PHP: traditionally PHP on Windows has been slow and buggy. If recent work has made it fast, I'd strongly suspect it to be fast and buggy for a while yet (PHP tends to take a while to stabilise).

5. Caching will band-aid WordPress, but it's not the solution. It _should_ be database-bound, and so it should be fast until you need to rethink the database structure… but it's not.

A Google search for "wp cpu usage" was evidence for how bad wordpress is with CPU usage. All the top results for that search are links to this post which cites as evidence an install on a virtual machine on a windows server, database unknown.

brainlessly stupid...?

Running PHP with Windows is not a very good idea. But I agree that Wordpress is really a heavy web application. I only use it if my client wants a real quick solution, otherwise I always implement custom solutions.

As a Movable Type user myself, i totally agree with you.

@Gio

"You're right, there is a fundamental problem with WP making 20 db calls; however, caching would help because WP wouldn't have to go out to the db to display the article, it could grab it from the cache - therefore utilizing less resources."

...

I get that, I just don't get why anyone would blame PHP for that... thats the programmers fault for using the programming language to make multiple requests and not implementing a caching solution.

If it was written in something lower level this would be a no brainer... languages aren't supposed to provide optimal, or even good solutions to arbitrary problems, they are just supposed to provide the means to implement them. PHP provides a lot of unnecessary bonus material... which is good, but I don't think its fair to criticise it for not providing more... particularly something as non-trivial as caching, which can't be implemented blindly for a guaranteed performance increase. :P

I note that just two comments above me is another one about PHP running like a dog on Windows... completely irrelevant given that the problem stems from db requests and bad programming.

I understand that it's beneficial to have full control over your blog if it is a major part of what you do, but for most people blogger or something should suffice.

I believe thinkchristian.net is on wordpress. This would explain its sluggishness.

1. Stable, high performance
2. Exciting, fast development

Pick one. And as previously noted, everyone seems to pick number 2. Me included frankly.

Wordpress screams on my box, uses about 5% CPU at the worst of times, and does, oh, say 30k page views a day, which is nothing I know. But even when I get a hit of traffic that spikes up to 250k a day, same story. Funny thing is I'm running on linux, and all the bits and piece of the stack (mysql, php, apache, wordpress) are caching...

@Jheriko

"I get that, I just don't get why anyone would blame PHP for that... thats the programmers fault for using the programming language to make multiple requests and not implementing a caching solution."

I don't think Jeff was saying that PHP should having caching built in (maybe he did, I read the article yesterday morning), I think he is saying that Wordpress should have it built in... although I'm not sure why he compared .NET to Word Press (unless Word Press is considered a platform and not an application... I don't know, I've never used it).

I get that too... I am just curious about all the smug comments about PHP running badly on Windows.

It really grinds my gears when comments like this are posted without any justification... its typical Linux vs Windows crap. No justification and strong opinions. As much as it maybe true it seems to me that it has nothing to do with the matter at hand...

I've got an install of WordPress running (without WP caching) on a site serving 10-20k pages per day on a small VPS with other sites, sometimes hitting hundreds of simultaneous connections. Our loads are nothing like yours listed.

1. bad-behavior is not a cache plugin at all

2. you can't compare movabletype to WP: Movabletype's slow-as-molasses perl can't render pages in realtime at ANY realistic realtime load - try "re-compling" 1000 movabletype pages just to affect a simple page change

3. You are running on a windows box with PHP as a cgi, possibly the slowest way possible to execute PHP

4. You're obviously running without a PHP opcode cache while I suspect comparing it to fast-cgi perl which is cached?

I will never, ever, go back to Movabletype after having the flexibility of WordPress. Neither is perfect but I'll take WordPress's attitude over MT's ways anyday.

> thats the programmers fault for using the programming language to make multiple requests and not implementing a caching solution.

Remarkably, that is the one constant in software: there's no shortage of terrible programmers in all languages across all platforms!

> thats the programmers fault for using the programming language to make > multiple requests and not implementing a caching solution.

1. WordPress originally had a caching system which was abandoned for reasons I never followed, possibly when it was externalized as a plugin (wp-cache) which was superior to what they had.

2. Near-future versions of WordPress (and bbPress) are supposedly going to have object based caches where internally (and plugin developers) can save any results to it's cache in a structured manner (ie. userlists, front page topics, etc.)

I recommend doing some comparison testing using something like ab [http://en.wikipedia.org/wiki/ApacheBench]. Test your current setup. Test with Apache/mod_php on Windows. Test with Apache/mod_php on Linux. Test with and without WP-Cache. Get some real numbers and repeatable testing.

Of course, I also think that changing a database-backed blog to purely file-backed is kind of silly, and that fastcgi is a problematic way to run code (though I currently use it). So I'm sure my views are considered suspect.

Wordpress is DOING IT WRONG.

Plain and simple, no matter the platform those 20 roundtrips to the database by default are nonsense on *nix, windows, and any other platform.

@Jheriko

"It really grinds my gears when comments like this are posted without any justification... its typical Linux vs Windows crap. No justification and strong opinions. As much as it maybe true it seems to me that it has nothing to do with the matter at hand..."

Agreed.... and some how comments on this board combined both language vs language and OS vs OS!

I'm not a PHP programmer... but I'll never knock it. I judge a language not by syntax or performance (for 98% of programming the difference between languages doesn't matter), but by library support, freely available code, and a large community so that it is easy to Google questions. PHP has plenty of all three.

Move to Linux and you will not see this prob. Trust me.
-Des
<A HREF="http://techwatch.reviewk.com/">Techwatch</A>

I am running WordPress 2.5 on CentOS, apache, and MySQL.

To my experience there are no excessive/disproportionate CPU load issues. My understanding is that WordPress is well-designed and can be scaled for high-availability and/or high-traffic environments. Unlike Microsoft platforms, WordPress is very standards-compliant.

I believe that the CPU load issues experienced in this article are particular to Jeff Atwood and his configuration.

D.Shak

Never mind destroyer of CPUs, WordPress seems to be a destroyer of code. I have been using it for the past few months for a programming blog and it seems every once in a while if I go back and make the most trivial change to a post, it destroys all the code formatting in that post.

Why not try to collect some actual statistics rather than just taking a screen shot of taskmgr.exe?

Maybe if you had some numbers for page faults, virtual memory use, HTTP traffic, Interrupts/Sec or other sundry performance counters you wouldn't look like a complete git. Nie.

I thought part of being a computer scientist was passing familiarity with the scientific method. I guess that I was wrong.

Okay I had a few setup virtual machines around, (a Ubuntu 7.10 machine, anda W2K3 Standard machine) so out of curiosity I took a few moments and setup Wordpress on both of them (along with MySQL), posting the same set of entries to both and then with the Web Application Stress tool got some throughput benchmarks.

I rescind what I said above. I have had need to deploy some PHP apps before intermixed with some "Microsoft ecosystem" code, and in those cases I always validated that the performance compromise of putting the PHP app on Windows wasn't too penalizing. In the case of Wordpress, however, the differential is quite dramatic.

With Ubuntu/Wordpress, running 4 threads with 4 sockets each pounding it, a homepage with 3 large entries pushed out 7.63 pages per second averaged over 30 seconds.

With Windows 2003/Wordpress, running 4 threads with 4 sockets each pounding it, a homepage with 3 large entries pushed out 1.95 pages per second, again averaged over 30 seconds.

Adding APC (a PHP bytecode cache) on the Linux machine and the throughput jumped to 13.77 pages per second.

Adding APC on the Windows machine and the throughput jumped to 2.67 pages second.

The Windows machine was using PHP ISAPI. With FastCGI (the same one you spoke of earlier), the throughput was almost identical (obviously with traditional CGI it was much, much worse).

So you have tremendous overhead running this on Windows, and I rescind my statements earlier.

(those virtual machines were both given access to two CPUs and 1GB of memory, and environmental variables were normalized. They were virtualized in VMWare Server)

Sidenote - Not taking into account application caching which could completely change the equation, WordPress 2.2.2 is quite a bit faster than Wordpress 2.5

Been running Wordpress for two years been on the Front page of Digg 15+ times (among others...), I get 200,000 uniques a month, and I never had any overages. I use a unix host, MediaTemple, and have never crashed or even slowed down...

http://www.WiiNintendo.net

I've not dived into WP (not the least bit of interest), but this multi-log about caching strikes me as more web-kiddy ignorance.

Web-kiddies have never heard of 3NF or the operator JOIN, only that "databases" are a place to dump "files". Thus, they have no notion about defining a database for web pages in such a way that a single (compiled) query returns a result set containing the page data. The caching/buffering belong in the database. This is especially true if concurrency is needed. If not, then static pages, sans database, is best.

Application caching of database data wastes the power of the database; concurrency and data integrity. MySQL (vanilla) is merely a SQL parser in front of files, nothing more.

I do believe that the screen shot of task manager was simply to show that his CPU was hitting levels of use that were higher than they should be for the size of the blog he was running on it, not set up some huge study on every part of his server for every connection it gets. Jeff simply has a before and after caching image along with system specs to show that caching reduced the CPU use to an acceptable level. The point of this post is that there's no reason for WP to make so many queries to load every page. The people who keep bringing in things like OS's and programming languages would do well to remember what the actual topic is, since you start to give the appearance of being a simple-minded troll. I'll accept OS arguments of the "should have used Linux" sort as valid when one of you posts proof that somehow the different OS makes the excess DB queries go away without any optimization for the OS.

As a reminder the topic to my understanding is WP should have caching on by default or not query the DB so much. There was some good posting up above, and I'd like to see more good posts.

I've not used or taken apart wordpress to analyze it's code yet so I'm not the most qualified to talk about it, but from my bit of research done I have to agree with the people above who said it's a mess on the inside. I currently can't think of any way to make my own sites need 20 DB queries for the homepage without repeating queries or including junk ones. One to get the articles which I'd have another row that holds a tally of comments on the articles, one for the side bar content if I was going to really store that in a DB, maybe one to a table holding information on which stylesheets should be used on which pages depending on the site. 1-3 queries depending on how crazy I am and how exactly the styles are set up for a site. What's the other 17 WP needs to make?

The saddest thing is there are some Wordpress plugins that won't work with WP-Cache enabled.

By the way, the default install of MySQL has it's cache OFF by default if I recall correctly? 20 queries are a moot point if they are the same for every page load and a cache is properly setup.

20 queries is nothing. The most efficient non-cached blog setup I have seen needs at least a dozen queries to render a fully loaded page because you need separate tables for the users+posts+tags+comments and then the inefficient plugins do their own lazy queries.

Something important: the default WordPress install has the option turned off to pre-load all the option settings at once. If you turn it on, you'll probably drop the queries by a half-dozen or more. Try putting this into your wp-config.php and see what happens:

$wp->load_options = true;

The "please support open source" story goes like this:

Don't be stupid, Microsoft is evil. Use open-source software.

When there's something wrong with open-source software,
1) "oh you got it for free, dont complain!"
2) "fix it yourself!"
3) "don't use open source software unless you know what u doing!!!"

If you use Microsoft, you're stupid. If you have problems with open-source software, you're stupid. Sounds really complicated.

WordPress in fact DOES have a caching subsystem. It just looks like nobody knows. It is for sure better that WP-Cache. I have not tried WP-Super-Cache yet.

To use the native WordPress caching just create a directory wp-content/cache and make it writeable by the Web server.

To your wp-config.php add

define ('ENABLE_CACHE', true);
define ('CACHE_EXPIRATION_TIME', 1800);

The cache exiration time is the time in seconds before cached content is discarded.

After enabling the caching WordPress will place the cached content into the cache directory. The number of queries goes down to 50%-30%. The major plus of this subsystem is that all plugins can use it easily (as I do with my <a href="http://turmsegler.net/tag/wordpress/">WordPress plugins</a>). And second: the WP programmers do know for sure when a page needs to be rerendered.

Check it out.

>> congrats you are now result 4 on google searches for wp cpu usage!

>You're right -- that's *hilarious*.

ok - so I couldn't resist and I googled it. Now it's #3 lol.

I agree, wordpress is shipping a broken product. It also has very slopping coding - run it under PHP5 and look at all the warnings.

I use it because "word on the street" is that it's the best..

There's plenty for the well-versed to rail on PHP about, but if the sum total of your experiences with it consist of installing PHPNuke or reading some stupid blog entry about how memory_get_usage() implied that there might be some overhead associated with all the magic functionality dynamically typed languages bring to the table, you need to be quiet and let the grown-ups talk--it's not the language's fault somebody wrote a giant turd in it which you chose to sniff. If Python or Ruby were as ubiquitous amongst budget hosting providers as PHP is you'd have just as many adolescent IRC morons who think they're slicker than snot on a doorknob writing and distributing terrible software written in them. It's certainly not my first choice for every task, but it's a perfectly useful language, and like it or not, it does run on Windows.

As for the benchmarks themselves, the fact that WP's installation instructions require you to place password laden config files in the public document root should be warning enough as to the quality of the code one can expect to find within its sprawling source tree.

We obviously can't expect non-engineers to judge any of these products' vendors by anything other than their shiny facades and marketing hype, but if you're the sort of person who knows NOTHING about programming AND you have a website, try to keep in mind that it wasn't any harder for them than it was for you.

@Benjamin Stein

WP2.5 removed the native file-based object cache. There is a caching API in place and it does reduce a lot of DB calls during each page request, but the data is not stored anywhere after that.

As far as the object cache being better than wp-cache, that depends. If you aren't relying on a lot of truly dynamic data and have a small user base, then wp-cache is the way to go. If you need dynamic abilities that change every few page requests, then the object cache is the best method. Also if you do things like required registration for comments on a larger blog, wp-cache will kill your server with invalidating old cache files for each user once a new comment is posted. I found that out the hard way on a site with 6,0000 users that averages over 1,000 comments a day. Now I use my own caching for non-logged in users that works off the same premise as super-cache. Logged-in users get dynamic pages (with object cache using an APC backend) and non logged-in users get the static file (through mod_rewrite). Works out really well that way.

20 queries is considered much? I work at an internet retailer. Nearly every page contains data tailored for the customer looking at it hence caching makes little sense. There are lots of products (millions) hence caching makes little sense. I would guess that an average page view makes a couple of hundred of queries. Sure, this is not a my-personal-blog-at-a-$5-a-month-host but this system could quite easily be run with a decent level dedicated server. Keep joins down and make useful indexes. This is a LAMP system btw (where the P is mod_perl).

>20 queries is considered much?

While that piqued attention and became an assumed source of ills, when I did the benchmark's listed above MySQL contributed very little to the workload -- overwhelmingly the work was in the PHP CGI handler.

Sometimes people forget that databases have the whole concept of caching pretty proven out -- a tiny option table, for instance, will almost certainly be cache-resident for read operations, with lookups basically being a hashmap lookup with proper indexing. Querying it a million times won't differ that much from just looking it up in a collection presuming there isn't expensive connection setup/teardown type activities.

@intoxination

Wow! I didn't even notice that the native cache has been removed in WP 2.5! Thanx for the hint. After reading here about WP-Super-Cache I gave it a try, and it seems to do a really good job.

@Dennis Forbes, thank you very much for bringing some empirical sense to this discussion.

I love the ignorant assclowns who come here and say that they've never had any problems with WordPress and that is must be Windows fault, when the bottom line is that their blogs get little to no traffic and therefore they wouldn't have any reason to be concerned with CPU usage.

WordPress blows, and it's not news.

Man, they sure are hacking our gibsons.
Insanely archaic caching aside, WP still holds a special place in my heart.

We had a couple of posts get on the front page of digg. Wordpress with wp-cache handled 24,000 unique visitors in three days just fine on a PIII Xenon running FreeBSD. You have to make sure apache is configured properly for your resources though, otherwise it's child processes can get pretty crazy. The MT approach is good too - very utilitarian - throttle once render many!

Wordpress is a great success story and I think we bloggers (including ASP.NET developers) owe it a debt of gratitude. And I say this as a die-hard ASP.NET developer. Sure, Wordpress is a mess under the hood but you're looking at the platform which more than any other brought blogging to the masses. So don't knock it too hard. In the hands of a competent developer, all of these technologies can be made to work although some have the advantage of being newer than others.

Jonathan H: Well I have done some test with checking the server load with newly installed WordPress and you know what, the server load was not so high as in tests by Jeff.
Actually when Jeff says:
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.

It sounds like he not really knows anything but windows machines and everything how to "run stuff" on them.

Well on PHP "we" have cache too, and by the way it performs better on UNIX type machines than on Windows.

Well the bad thing that we can't have caching by default, but it is not enabled by default in most of the CMS and blogging software, you always need to go extra step to do that. And if talking about PHP frameworks (and there are plenty of them) there is caching and quite good, so when reading the original post I was really pissed off about "darkness" of the writer, as I was thinking of Jeff as more bright person... (Sorry Jeff) ;)

2c

One more interesting thing I noticed is that the software USED to be much less bloated than it is now.
Caching helps BUT I have been narrowing this down a bit further.... what actually takes up the most CPU and MEMORY in 2.5 is... the new DASHBOARD.
If you avoid it from loading the whole bunch of RSS feeds from the net, store them in the database and then read them again from it... you save at least 20-30MB for EACH time the dashboard loads!
This other plugin lets you "strip down" the dashboard to just what you find useful: http://wordpress.org/extend/plugins/wordpress-dashboard-editor/

Yo como siempre recomiendo usar joomla, tiene una gran comunidad, muchisimos plugins, Codigo Abierto, usuarios, categorias, secciones, foro, email marketing, RSS, Urls amigables, manejo de idiomas, ufff y mucho mas, visita http://www.joomla.com

Uh-oh... My Drupal senses are tingling!

Couldn't help but jump in and comment after seeing the chatter about Drupal in this context. I'm far from unbiased, but I've worked with a number of platforms, from MT to ASP.Net hand-rolled to Drupal, and I'm now one of the core Drupal developers.

Modern dynamic CMS/blogging packages are database <i>hogs</i>. Period. End of story. That side of the equation is unavoidable, IMO, given the demands that most reasonably complex sites have for them. You can counter that by 1) sacrificing the 'dynamic', 2) scaling down functionality, 3) caching dynamic data, or 4) optimizing your code and your queries.

The comparison between MT and WP is an interesting one because Movable Type's entire page generation strategy is really just aggressive, filesystem-based caching baked into the system. MT stores posts and comments, and manages them, like almost every other blog/cms, but it assumes that the content will always be delivered to the user via the cached files and optimizes for that.

Drupal has a swappable caching system out of the box, with db-stored page caching being the default. MT-style filesystem based caching or memcached backends are both in use on a variety of high-traffic sites (FastCompany, MTV, Britney.com, etc.), but most small-to-mid-range Drupal sites roll with the standard stuff.

The key take-away, I think, is that not making <i>provisions</i> for scaling does users a huge disservice. WP originated as a tight solution for small-to-midrange bloggers, and it's growing up as it's used in a wider variety of scenarios. The second is that claims of multi-platform support should take 'must-have' plugins and addons into account.

Windows is a superior Web hosting platform and that is proven over and over. LAMP requires massive horizontal scaling, meaning you have to add numerous servers for what can be hosted on a single IIS server. Just check out plentyoffish.com. The problem is PHP is a scripting language and it is single threaded. ASP.NET is multi-threaded as is IIS. IIS 7 has already proven to be the absolute best web server to host PHP scripts because it actually scales PHP, unlike Linux. Obviously WordPress is short changing its users, I guess that is why I hear them talk about the 20 servers they have to host sites I know I could host on one IIS server with about 100 other sites without pegging the resources on the server.

lol and behold... look what they released today: http://wordpress.org/development/2008/04/wordpress-251/
wordpress 2.5.1. Yep. .1.
guess what's new in it?

[...]
2.5.1 focuses on fixing the most annoying bugs and improving performance. Here are some highlights:
Performance improvements for the Dashboard, Write Post, and Edit Comments pages.
Better performance for those who have many categories
[...]

performance, performance, performance :-)

The moment I saw "WordPress", "PHP" and "FastCGI" in the post I knew the die-hard Linux trolls would be swarming here in their droves. I really despise having to wade through 20+ comments of "OMG U USED WINDOZE LINUX IS SO MUCH BETTAR" crap, just to find one useful viewpoint.

@Dennis Forbes: your performance tests were run on Windows 2003 and Jeff is using Windows 2008, so your numbers aren't really relevant to the discussion at hand, other than proving that Windows 2003 is slower than Ubuntu 7.10 when it comes to serving up PHP.

As for WordPress... let's not go there. The code is "infinite number of monkeys typing on an infinite number of keyboards" bad... some of it's classes, some of it's functions, some of it's just massive PHP blocks... need I go on? I have to agree with the commenter who believes that WP is a dead end - it may be the most popular blogging platform around, but it's far from the best.

Which is a pity, because WPcould have been a highly visible poster child for the FOSS movement; unfortunately, it's merely a poster child for what happens when you open-source a hack.

"it may be the most popular blogging platform around, but it's far from the best."

The most popular is rarely the best. Though it does usually have the best marketing, or is the easiest to use/setup.

>@Dennis Forbes: your performance tests were run on Windows 2003 and Jeff is using Windows 2008, so your numbers aren't really relevant to the discussion at hand, other than proving that Windows 2003 is slower than Ubuntu 7.10 when it comes to serving up PHP.

I wish I had unlimited time -- I have the Windows 2008 ISO ready to install...

But ultimately I find this whole debate so ridiculous. The slow point of the equation is *not* IIS, it's the Windows build of the community edition of PHP, where the overwhelming bulk of runtime occurs. It doesn't *matter* how much you speed up IIS in this case (and no, IIS 7 isn't faster. The article Jeff linked to has some pretty blatant switcheroo going on to prove that case).

So no, it doesn't have anything to do with IIS versus Apache. It has to do with the Windows build of PHP being just on the side of terrible. What do you know, but Zend -- the gatekeepers of PHP -- sell a faster, commercial version of it for Windows that happens to be quite a bit faster (which is the sneakeroo pulled in Jeff's Windows 2008 sample).

So my numbers are *completely* relevant and accurate, but I'm not going to bother going through the trouble of proving them unless someone wants to pay me. Say about $1000?

"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?"

If you use MySQL, just turn on query cache.. One problem solved ;)

I am so sick and tired of the silly (should I say retarded?) answers like :

* Run it on Linux (why, the number of queries, or the COST of the queries will go down!? HOW? MAGICALLY?) At least some queries could have been "merged" with others to at least reduce their number.

* Your problem is Windows, IIS ... Microsoft in general (after all the great PHP is cross platform unlike .NET isn't it?! OR IT IS NOT REALLY CROSS PLATFORM AND ALL IT CAN RUN ON IS LINUX?)

* Turn on MySQL caching (WTF?!? the TCP/IP cost where will it go?)

There should be a rule on this blog : Answer only with some kind of technical argumentation not just empty bla-bla statements.

I run on wordpress.com. It seemed to cope ok during my 15 minutes of fame when I was simultaneously dugg, slashdotted and reddit'ed. However I am also very much as their mercy:
http://successfulsoftware.net/2007/10/19/normal-service-resumed/

"One of the main problems with PHP is that it doesn't maintain a cached version of the page by default, whereas other languages like Java, C# and Python do." - Erm, what, now? That's very much a framework feature, rather than a language one...

That said, PHP is not the only issue here. My rather modest webserver manages about 70,000 page views a day of a not-wonderfully-well-written PHP app I put together in 2003. That same server used to have trouble with my modest blog, whenever there was the slightest traffic spike, backed when I used Wordpress.

Don't get me wrong. PHP is a horrible language. I know; I've used it. But the issue here isn't PHP, it's that Wordpress is very poorly written. Look at the source if you don't believe me.

> So my [Windows Server 2003] numbers are *completely* relevant and accurate, but I'm not going to bother going through the trouble of proving them [on Windows Server 2008] unless someone wants to pay me. Say about $1000?

If you went to the trouble of testing Win2k3 and Apache, how much more work could it be to test Win2k8? I think a nice blog post on the topic would help your reputation more than cantankerously asking for $1000 in the long run, but what do I know.

> If you use MySQL, just turn on query cache.. One problem solved ;)

Query cache helps, no doubt (and I'm still appalled that the default MySQL installer has a 0-size Query Cache out of the box), but the fastest database trip of all is not going there in the first place. :)

Why not treat the disease itself instead of the symptoms.

So the first step in getting good performance is: have a famous blog. Then Matt Mullenweg will help you out.

Forgive me if I sound at all bitter, twisted, sarcastic etc.

>If you went to the trouble of testing Win2k3 and Apache

I already had "clean" virtual machines for both of these.

>I think a nice blog post on the topic would help your reputation more than cantankerously asking for $1000 in the long run, but what do I know.

My reputation? With all due respect, Jeff, I'm not seeking any reputation boost amongst the Coding Horror readership. I appreciate your suggestion about a blog entry, but honestly I'm just not that interested in that sort of conversation, or the readership it brings.

And the $1000 comment was obviously being facetious. It is absurd when people make grand, unsupported claims (no, I'm not talking about you) but then demand that the other person go through the effort to prove their statements.

>Turn on MySQL caching (WTF?!? the TCP/IP cost where will it go?)

When you're talking about a system serving up a mediocre 2 or so page renders per second, I suspect that TCP communications between the PHP runtime and MySQL accounts for a vanishingly small percentage of the overhead.

Dennis Forbes said: "I appreciate your suggestion about a blog entry, but honestly I'm just not that interested in that sort of conversation, or the readership it brings."

Sounds to me you're indeed interested. With the amount of time you commented on this topic, you probably could've made an informative blog entry as jeff suggested. you obviously want to be heard.

From the look of some of the responses, this is not a WordPress problem, it is a Microsoft problem.

Duh.... It is so obvious that if you just ran Linux all the problems would go away.

Nice advice Nixtards!

>Sounds to me you're indeed interested.

I posted an original supposition, and then posted follow-up facts that *refuted my own point*. My motivation for a follow-up was actually because I have enough self-doubt that I feel burdened to validate my own claims where I feel that they are open to question.

>With the amount of time you commented on this topic

How much time do you think that it takes?

>you probably could've made an informative blog entry as jeff suggested. you obviously want to be heard.

Not particularly. A couple of cast-off comments on a discussion board don't mean that I care enough about the topic to associate myself personally with it beyond a small group. Honestly, I don't care what people think about PHP, MySQL, Linux, IIS, whatever. It's a boring debate, honestly, circa 1999 (hey I joined Slashdot in 1998, with a 4-digit UID, purely to have the debate. It's been done), however I did originally throw in with Jeff purely based on personally experience, but then re-validated my assumption and found it blatantly wrong. Mea culpa.

Wordpress is garbage. It might as well have been written in crayon. It's the most disgusting amateur code I've ever seen.

"Wordpress is garbage. It might as well have been written in crayon. It's the most disgusting amateur code I've ever seen."

so is facebook/myspace. what's your point?

"Query cache helps, no doubt (and I'm still appalled that the default MySQL installer has a 0-size Query Cache out of the box)" - There's a good reason for this. MySQL query cache for a given table is generally invalidated whenever the table is written to, so unless your load is mostly reads it is worthless. In fact, it's worse than worthless; for a mostly-write load, I've seen turning it off increase throughput by about 20%.

It's fine for blogs, though, I suppose.

There's a nice and clean db abtraction layer for php called ADODB it has many many features including query cache management, also is compiled as a php module. Not only gives you portability but faster nicer code.

Serving images and other static content can eat up more bandwidth and CPU load than you can imagine. Delivering images from the same server as the pages (presumably with Apache), is a big no-no if you care even a bit about performance. Server-side caching with WP-Cache also helps a lot, but its significance is not obvious if each of your pages spawns tens of HTTP requests. That leads to the creation of many server processes and threads with constant processing overhead. Not to mention memory usage - an Apache process to serve a single JPEG image will have mod_php, mod_ssl and everything else loaded up.

Check out the recently released WP-Offload plugin. It will seamlessly mirror and redirect all the requests for static content to external cache servers. Combining it with WP-Cache will really make your blog a fast one-page-one-request experience.

99% of the Wordpress blogs out there will never get the level of traffic required to make this an issue. Wordpress knows this - they host over 3 million blogs.

Why should the Wordpress code be changed to account for the minority of users that this would be an issue for ? THAT IS WHAT PLUGINS ARE FOR.

If you are in the minority and getting a ton of traffic - install the WP-Cache plugin.

Did you know that wordpress is free? If you don't like it- don't use it. Or spend 5 minutes to install the plugin (which is also free)

If you think wordpress is amateur code, take a look at PunBB. Sure, it's fast, but that's because almost every line of HTML is hardcoded into each page.

i wonder why do you use Win Server when you run PHP :/

Excellent post. I knew WordPress is absolutely terribly coded, but I never knew it was such a CPU beast. I think the ammount of needles queries could explain this.

@Jin: My point is that you're incapable of following the premise of a discussion. No one is talking about myspace/facebook.

@Kerry Mann: No kidding it's free! You don't think they could sell that gimpy pig do ya?!?

@Patrick P: I could sit here all day picking on poorly written projects, but we're talking about Wordpress. It's PHP's biggest and blackest eye.. a shameful piece of slop.

WP-Cache is not a solution, it's a band-aid to cover fundamental flaws.

@A. programmer: my point is that myspace/facebook was also poorly written, but look at their success.. sometimes what's under the hood doesn't matter, except for you alpha geeks. there's the commerical side of things. you'll learn.

@Jin: You obviously have no idea what you're talking about. First, you don't know what their code looks like do you? If you did, I'm guessing you wouldn't be qualified to judge its condition given your obvious ignorance. Second, if you had any business sense whatsoever you'd understand the cost benefits of a well coded application.

@a.programmer: myspace and facebook codes was well criticised a while back. a lot of popular things are crap underneath. but it's really the business success that matters. Windows.

@Jin: So, you're basing your entire argument on hearsay and speculation? It's ignorant to assume you have any idea how well MySpace, Facebook and "now" Windows is coded. These apps dominated theirs markets because they worked well and they were cost effective/affordable to produce and operate. You cannot build a successful business on a weak and flailing foundation/product. To assume otherwise is brutal ignorance.

@a.programmer: i don't assume. wordpress is popular for a reason, not for how it's written. please tell me how wordpress is not "cost effective/affordable."

@Jin: Last response. It's affordable because it's free, but it's not cost effective in the sense that if you actually tried to build a medium to large scale service, you'd be throwing all kinds of resources ($$) at sustaining poorly written code. The more resource intensive the app is the more $ spent on hardware and maintenance. See graph and comments above.

You can run Wordpress practically *anywhere*, on a thousand different (often crappy) shared hosting setups. No other blog software has that level of compatibility.

If you get famous, you can use (free) plugins to scale as high as you want to go, all the way to full-static (SuperCache).

No other blog software is as easy to use for complete newbies either, nor as flexible. That's why it's so popular.

Nobody gives a crap about what the code looks like, as normal users never see it.

And my point was that you're sort of wrong: lots of people use it, and that's what I believe you're turning a blind eye toward. This is strictly anecdotal evidence, of course, but moving to IMAP email over SSL seems to be a trend everywhere I've been.

I used wordpress in my website, I just learn how to edit wordpress template, very interesting.

I use WP Super Cache on <a href="http://richardxthripp.com/">my Wordpress MU network</a>, set to update the cache after a day. It makes everything really fast, though category and tag pages lag behind.

Of course, caching doesn't prove that Wordpress is fast; just that it can be cached. It's still slow on the first load of each page, and <a href="http://comox.textdrive.com/pipermail/wp-hackers/2006-November/009771.html">inefficient in general</a>. Wordpress.com's 3 million blogs doesn't prove that it's fast either; it just proves they have 10x the computing horsepower to compensate for it's sluggishness.

It's still worth it though; I'm amazed at what I've been able to do with no original coding, from reading the codex and by using the great plugins everyone is creating.

very nice article

that's right!

I'm developing a bigger project based on wordpress, so I'm alarmed reading this excellent post. I'll try these plugins and hope they'll help me out.

http://dressnice.de/

You always get what you pay for.....

>You always get what you pay for.....

Generally but your mileage may vary.

I set up 2x test sites on the same (shared - $6/month at ICDsoft) server & tested them with
http://www.vertain.com/?sst (web site speed tester).
Wordpress 2.6 results - 13.4 & 14.3 seconds
Drupal 6 Results - 7.4 & 7.1 seconds

Note: - I couldn't get the SuperCache to work, despite lots of Google-based research.

Both crap results because the (shared) server is in Hong Kong (not for long!). I tested another server I have with the same host but in Boston, running Drupal 5.8, and it returned 1.6, & 3.1 seconds. The host platform is the same but obviously it is serving different sites.

I'm in Australia so latency and the number of hops is a major factor in page loading times for most sites. I noticed the Wordpress site has a lot of t0 & fro-ing whereas the Drupal site seems to have very few requests.

It's hardly a scientific test but I feel it is/was a reasonably indicative seat-of-the-pants test.

It's a shame the Drupal is such wrestle to set up compared to Wordpress.

The lesson there is if you use Wordpress, make sure your front page (or the slashdotted page) is light-on

IMO, Wordpress is coded "badly" throughout. The template "system" is ridiculous, the method to get different languages even worse. The code is hard to read through because it just looks messy. I haven't been at all the core files, but everything I've touched that has to do with the templates or localization is just awful.

On the surface it looks nice, is easy to use and is obviously very popular, but under the bonnet its a disappointment.

I'm developing a bigger project based on wordpress, so I'm alarmed reading this excellent post. I'll try these plugins and hope they'll help me out.

Worldwide client base in the mobile communications space.See the details at www.icoft.com/roke.html

Worldwide client base in the mobile communications space.See the details at www.icoft.com/roke.html

WORLDWIDE client base in the cell phone sector. Tremendous opportunity to get in the stock now. Check out how big the opportunity is at www.icoft.com/roke.html

In my opinion this is really very nice and informative post. I really like this post very much.
-----------------
lauran
Social Bookmarking

Quoting from here:
http://hublog.hubmed.org/archives/001654.html
Look at what happens to a query before its used to make sure it's "safe":
1 Passed through stripslashes_deep() to remove the slashes that magic_quotes_gpc() has added if it's on by default [wp-settings.php].

2 Passed through add_magic_quotes() to make sure quotes are escaped (add_magic_quotes calls $wpdb->escape, which calls addslashes()) [wp-settings.php].

3 Passed through stripslashes again [wp-trackback.php].

4 Converted to $blog_name [wp-trackback.php].

5 Passed through mb_convert_encoding($blog_name, get_option('blog_charset'), $charset), to convert strings provided in a different character set into the local character set [wp-trackback.php].

6 Passed through $wpdb->escape (addslashes()) again [wp-trackback.php].

7 Converted to $comment_author [wp-trackback.php].

8 Passed as part of the $commentdata array into wp_filter_comment(), which calls apply_filters(), which applies the pre_comment_author_name filter, which passes the string through strip_tags, trim, wp_filter_kses and wp_specialchars. [wp-comment.php]

9 Finally, inserted into the database by direct insertion into a query as above.

Seriously, has noone heard of a prepared statement? When you pass yourself through nine silly different filters in the name of a vague attempt at security, no wonder you have CPU issues.

Data Entry India, Data Entry Company India, Data Entry Services, Ecommerce Data Entry, Data Mining, Data Processing, Internet Research, Data Entry

without exception, every major franchising company has Advertising Fund. This is not the case in the dollar store industry. Us Dollar Store is the only dollar store franchise that operates and a Advertising Fund is a unique strength to this franchise. A Marketing Director runs the Us Dollar Store Franchise Retail, Retail Franchise,

If your going to blog you have to try WordPress if for no other reason than curiosity about a popular project. And it's interesting to dissect it's various attributes. Whether it's the right solution for a specific need has to be determined case by case - as always.

Rather than point to an alternate application as the one to choose over WordPress, I recommend playing with all the major candidates. I only wish I had more time to just sit and wander around in the worlds of code that have been spawned by the creativity of countless hobbyist and pro hackers around the globe.

BTW, I'm about to give Concrete CMS a whirl. Has anybody worked with it? If so please comment.

The sheer amount of technical misapprehensions on this page (including comments) is mindboggling. Might I suggest deleting the whole thing to save confusion?

Particularly this one:
>You always get what you pay for.....
Fool of fools!

Wow, that's scary. I have about 4 e-commerce sites that I cannot afford to slow down. And one site that I have at another host which I was thinking of moving over which has a wordpress blog. I think I will just keep the blog where it is...I cannot afford to slow down the other sites. Thanks for the info.

Wordpress does suck.

I think anybody with half a brain could have written the entire software platform in a weekend...

Unfortunately it has escalated to the point where millions are losing their weekends just to keep it working...

i feel lucky can find this usefull informations..
thanks for this great posting..

Very interessting. Sometimes my space is not available. Maybe i should change the cms.

Good system, thank you comment

Great Blogging!!
Keep Your Good Work Going!!

Great Blogging!!
Keep Yout Good Work Going!!

Great Post!

I enjoyed reading this.. this information can save us from those blunders we do generally.

Thanks,
Cignus Web Services

It's not the OS, it's sloppy coding. WP code looks like spaghetti. html intermingled with php everywhere. no concept of MVC whatsoever. That it doesn't have a viable caching system doesn't surprise me.

Jeff,

Thanks for posting knowledge based blog, it’s really helpful to prevent routine mistakes.

Cheers :)

thanks for the inforamtion an greetings from Germany

Thanks for posting this blog!!
my motto: Mountains never meet, people always

thanks for posting this blog.
my motto: Mountains never meet, people always

The above is really nice and informative post thanks for sharing. I will look forward for more information.

First, I highly recommend WP-Cache. I wouldn't do a WP site without it. Atwood is right.

Now Xtensible said something I need to dispute, and he said, "What about 20 database calls does Linux do any faster?" And the answer is simple -- Linux has far less API layer goo to get through for those calls to work. Have you not seen the famous IIS versus Apache system call diagram before? It's a classic example of what's wrong with Windows. Apache was just a few lines in the chart, but IIS was a hairy mess. And yet Apache is the #1 web server on the Internet and can be secured to a larger degree than IIS.

One great book on WordPress is called Rockstar WordPress -- it's well worth it. However, there are two things I dislike about WordPress:

1. Lack of a series of admin themes so that I could find one that might be faster or might be more user-friendly, as in Fisher-Price Playskool kind of friendly for some kinds of users.

2. Lack of the ability to create custom forms like you can in Drupal.

P.S. It's also sad that somehow the reCaptcha thing has been hacked here and people are able to post spam. Pretty sad yet amazing stuff.

thanks.I think it is very useful.

Great Stuff..
Keep Your Good Work Going..
Regards!
Boblee