programming and human factors
by Jeff Atwood
Lately I've been delving into the WordPress ecosystem, as it seems to be the most popular blogging platform around at the moment. I've set up two blogs with it so far. In the process, I've gotten quite comfortable with the setup, interface, and overall operation of WordPress.
I've been thoroughly impressed with the community around WordPress, and the software itself is remarkably polished. That's not to say that I haven't run into a few egregious bugs in the 2.5 release, but on the whole, the experience has been good bordering on pleasant.
Or at least it was, until I noticed how much CPU time the PHP FastCGI process was using for modest little old blog.stackoverflow.com.
For context, this is running on a Windows Web Server 2008 virtual machine with a single core of a 2.13 GHz Xeon 3210 entirely dedicated to it.
This is an incredibly scary result; blog.stackoverflow.com is getting, at best, a moderate trickle of incoming traffic. It's barely linked anywhere! With that kind of CPU load level, this site would fall over instantaneously if it got remotely popular, or God forbid, anywhere near the front page of a social bookmarking website.
For a bare-bones blog which is doing approximately nothing, this is a completely unacceptable result. It's appalling.
As evidence of what a systemic problem this is, there's an entire cottage industry built around shoehorning better caching behavior into WordPress. Take your pick: WP-Cache, WP-Super-Cache, or Bad Behavior. The caching add-ins don't work very well under IIS because they assume they're running on a *NIX platform, but they can be coerced into working.
Does it work? Does it ever. Here's what CPU usage looks like with basic WP-Cache type functionality enabled:
I'm not alone; just do a web search on WordPress CPU usage or WordPress Digg Effect and you'll find page after page of horror stories, most (all?) of which are solved by the swift and judicious application of the WP-Cache plugins.
It's not like this a new issue. Personally, I think it's absolutely irresponsible that WP-Cache like functionality isn't already built into WordPress. I would not even consider deploying WordPress anywhere without it. And yet, according to a recent podcast, Matt Mullenweg dismisses it out of hand and hand-wavingly alludes to vague TechCrunch server reconfigurations.
A default WordPress install will query the database twenty times every time you refresh the page, even if not one single element on that page has changed. Doesn't that strike you as a bad idea? Maybe even, dare I say it, sloppy programming?
I understand that users may have umpteen thousand WordPress plugins installed, all of which demand to change on every page load. Yes, the easiest path, the path of least resistance, is to mindlessly query the database every time you're building a page. But I cannot accept that a default, bare-bones WordPress install hasn't the first clue how to cache and avoid expensive, redundant trips to the database.
It's frustrating, because caching is a completely solved problem in other programming communities. For example, the .NET framework has had page output caching and page fragment output caching baked into ASP.NET for years.
I sure am glad I started this blog in Movable Type way back in 2004. Their classic static rendering blog engine approach may be derided today, but I shudder to think of the number of times the Coding Horror webserver would have been completely incapacitated over the years by the naive -- no, that's too tame -- brainlessly stupid dynamic rendering approach WordPress uses.
What I just don't understand is why, after all these years, and all these documented problems, WordPress hasn't folded WP-Cache into the core. If you're ever planning to have traffic of any size on a WordPress blog, consider yourselves warned.
Update: Matt Mullenweg kindly responded to this post and offered his recommended MySQL configuration optimizations. I definitely agree that the Query Cache is extremely important to performance, and for some reason it defaulted to off (zero size) on my installation. You may also want to look into innotop and mysqlreport to ensure that all your MySQL caches are functioning at appropriate levels. Also, thanks to a few commenters for letting me know that one of this year's Google Summer of Code projects is integrating caching into the core WordPress code. It is badly needed.
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?
fishstick_kitty on April 23, 2008 2:00 AMI 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.
Anonymous on April 23, 2008 2:03 AMWordPress + 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.
stevenp on April 23, 2008 2:06 AMHey 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.
xentek on April 23, 2008 2:09 AM"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++;
ceejayoz on April 23, 2008 2:16 AMI 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.
Daniel Scocco on April 23, 2008 2:23 AMBy the way, I did that with no cache plugins whatsoever.
Daniel Scocco on April 23, 2008 2:25 AMUmm, 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.
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.
Marth on April 23, 2008 2:51 AM20 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?
Jim on April 23, 2008 2:55 AMWordPress 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).
Sumesh on April 23, 2008 3:29 AMJust 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...
Vladas on April 23, 2008 3:30 AMI'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?
Sumesh on April 23, 2008 3:34 AMVladas: Because running it on linux would somehow decrease the number of queries how?
Jonathan H on April 23, 2008 3:46 AM"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.
Mark Jaquith on April 23, 2008 3:58 AMJeff, at far as I can tell (by using Alexa), this "trickle" is hundreds of tousands of page views PER DAY.
Dotmad on April 23, 2008 4:05 AMI 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.
David Durham on April 23, 2008 4:13 AMAt 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.
Xepol on April 23, 2008 4:28 AMI'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
Thomas Bukowski on April 23, 2008 4:48 AMYour 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.
visinin on April 23, 2008 5:25 AMI 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? ;-)
Matt Johnson on April 23, 2008 5:35 AMThe main problem isn't WordPress. The main problem is that you're using Windows.
Switch to Linux and fly!
Seize on April 23, 2008 5:40 AM@Seize
Why, does Linux make those 20 database calls faster?
It's MAGIC!
Jeff Atwood on April 23, 2008 5:44 AMI highly recommend you switch to Drupal! ;)
Mark on April 23, 2008 5:44 AMRunning 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.
alphager on April 23, 2008 5:45 AMInteresting 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?
Eric Florenzano on April 23, 2008 5:45 AMIt'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.
Mo on April 23, 2008 5:49 AMRunning 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.
MatthewT on April 23, 2008 5:52 AMIntegrating 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
Adam Dempsey on April 23, 2008 5:57 AMFor 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/
Pdraig Brady on April 23, 2008 5:58 AMIn 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
JohnW on April 23, 2008 6:02 AMI 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!
Kit Roed on April 23, 2008 6:06 AMMake 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...
Jheriko on April 23, 2008 6:06 AMI using my XSLT blog system to generate static html files, including a stylesheet to generate photo albums.
http://markraddatz.org/fooweb/
Mark Raddatz on April 23, 2008 6:14 AMI 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.
Khi on April 23, 2008 6:14 AMYou 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.
Maggus on April 23, 2008 6:17 AMhow 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?
Luke Crawford on April 23, 2008 6:30 AMNevermind 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).
Phil on April 23, 2008 6:33 AMcongrats 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!
Jeff Atwood on April 23, 2008 6:33 AMI assume you have seem this:
http://www.hanselman.com/blog/ScreencastHowToIIS7AndPHPWithFastCGI.aspx
?
It includes a part about caching built into IIS.
MLeo Daalder on April 23, 2008 6:35 AMPHP 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..
Jeff Atwood on April 23, 2008 6:36 AMThis 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.
Brian Warshaw on April 23, 2008 6:40 AMAs 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.
Fred on April 23, 2008 6:40 AMIt's because they hate your freedom.
Mitur Binesderty on April 23, 2008 6:42 AMWhat's the database back-end? Some database engines do better query caching that others, making those 20 trips not such a big deal.
rfunk on April 23, 2008 6:43 AMIf 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.
fool on April 23, 2008 6:43 AMDear 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.
baxter on April 23, 2008 6:49 AMTry 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).
Mike on April 23, 2008 6:52 AMFirst 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.
Shawn Weekly on April 23, 2008 6:54 AMOh. Windows, IIS, FastCGI, PHP.
Match made in heaven, indeed.
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!
Dennis Forbes on April 23, 2008 7:00 AMAnd going along with everyone elses suggestions... Graffiti CMS?
It seems nice and lightweight and the same sort of experience, but on ASP.NET.
Andrew T on April 23, 2008 7:07 AMJeff,
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
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.
Hoffmann on April 23, 2008 7:11 AMHi 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.
Nick on April 23, 2008 7:14 AMI'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.
Mark on April 23, 2008 7:15 AMWhile 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
Kevin on April 23, 2008 7:20 AMHi 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...
Stephane Grenier on April 23, 2008 7:21 AMI 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!
David Mohundro on April 23, 2008 7:21 AMIt'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.
Rick on April 23, 2008 7:21 AM**
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.
vasudeva on April 23, 2008 7:27 AMQuit dicking around and install BlogEngine.NET or Graffiti.
Josh Stodola on April 23, 2008 7:40 AMI 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.
Morgan Goose on April 23, 2008 7:42 AMTextpattern (http://www.textpattern.com) anyone? highly configurable, free, and has a good plug-in community too :)
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.
Dennis Forbes on April 23, 2008 7:49 AMI 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.
Matt Green on April 23, 2008 7:50 AM"brainlessly stupid"
Flamy flamy....
Ba-a-a-a-d Wordpress. I hope your post pushes someone that has anything to say in WP.
Niels on April 23, 2008 7:50 AMAre 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.
Thomas on April 23, 2008 7:54 AMI 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. :)
Sentax on April 23, 2008 7:55 AMAfter 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?
Kelly on April 23, 2008 8:00 AM@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.
Jesse Wolgamott on April 23, 2008 8:00 AMOur 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.
AndyT on April 23, 2008 8:07 AM@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.
Steven on April 23, 2008 8:08 AMWith 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?
pete on April 23, 2008 8:09 AMI'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.
Brad on April 23, 2008 8:11 AM"Our Drupal site has a minimum of 200 database requests on each page and some have more than 500."
@AndyT: Why!?
Steven on April 23, 2008 8:11 AMBad Behavior is an anti-spam, not a caching, plugin and is notorious for eating up CPU itself.
Matt Moore on April 23, 2008 8:13 AMYour biggest problem is you OS. There is an OS called ubuntu, and I hear its much better.
Linus on April 23, 2008 8:14 AM@Linus: Mmmm, no thanks. Windows OS works fine for me.
Steven on April 23, 2008 8:15 AM[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.
Jeremy T on April 23, 2008 8:19 AMHave you looked at DasBlog? It is a .NET solution...
Sean Gephardt on April 23, 2008 8:22 AMThe 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.
Brendan on April 23, 2008 8:33 AMInteresting 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.
Rhywun on April 23, 2008 8:34 AMYou should try linux eco system.
Vamsee on April 23, 2008 8:35 AM"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.
Dave on April 23, 2008 8:36 AMI 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.
V_RocKs on April 23, 2008 8:37 AMI 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.
Cameron on April 23, 2008 8:38 AMOK, 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?
Andrew on April 23, 2008 8:41 AMI 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!)
rm on April 23, 2008 8:45 AMI 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.
Workpost on April 23, 2008 8:46 AMWhy don't you vote with your choice of blogging engines and pick a "better" one?
Rob on April 23, 2008 8:46 AMYou 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
The comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |