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.
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.
cthulhu.hpl on April 24, 2008 7:27 AM@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.
Gio on April 24, 2008 7:42 AMMove 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
Daniel Shakhmundes on April 24, 2008 8:12 AMNever 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.
ferruccio on April 24, 2008 9:02 AMWhy 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.
jbs on April 24, 2008 9:35 AMOkay 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.
Dennis Forbes on April 24, 2008 10:25 AM(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
Dennis Forbes on April 24, 2008 10:31 AMBeen 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...
Mickey on April 24, 2008 10:32 AMI'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.
BuggyFunBunny on April 24, 2008 10:32 AMI 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?
Felstatsu on April 24, 2008 10:39 AMWordpress 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.
James Devlin on April 24, 2008 10:42 AMThe saddest thing is there are some Wordpress plugins that won't work with WP-Cache enabled.
Scott on April 24, 2008 11:01 AMBy 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.
u r stupid on April 24, 2008 11:23 AMWordPress 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.
Benjamin Stein on April 24, 2008 12:19 PMcongrats 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..
bEAVIS on April 24, 2008 12:47 PMUm.... 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.
Todd on April 24, 2008 1:00 PMThere'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.
Nathan Duran on April 24, 2008 1:00 PMI'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.
Mo on April 24, 2008 1:07 PM20 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).
Berserk on April 24, 2008 1:57 PMOne 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/
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 :-)
Daniele Muscetta on April 25, 2008 2:45 AMThe 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.
The_Assimilator on April 25, 2008 6:44 AMYo 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 ihogs/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 iprovisions/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.
Jeff Eaton on April 25, 2008 10:06 AM"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.
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.
Chris Love on April 25, 2008 11:30 AMJonathan 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
Vladas on April 25, 2008 1:01 PM@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?
Dennis Forbes on April 26, 2008 11:28 AM"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 ;)
Andries Louw Wolthuizen on April 27, 2008 3:51 AMI 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.
Andrei Rinea on April 27, 2008 4:15 AMI 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.
Robert Synnott on April 28, 2008 2:23 AMSo 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.
Jeff Atwood on April 28, 2008 3:08 AMSo 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.
Jacques Chester on April 28, 2008 4:05 AMWordpress is garbage. It might as well have been written in crayon. It's the most disgusting amateur code I've ever seen.
A. Programmer on April 28, 2008 6:14 AMIf 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.
Dennis Forbes on April 28, 2008 7:50 AMTurn 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.
"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?
Jin on April 28, 2008 8:24 AMDennis 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.
Jin on April 28, 2008 8:27 AMFrom 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!
jjMan on April 28, 2008 9:04 AMSounds 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.
Dennis Forbes on April 28, 2008 9:07 AM"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.
Robert Synnott on April 29, 2008 10:54 AMServing 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.
Blagovest on May 1, 2008 5:09 AMIf 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.
Patrick P on May 1, 2008 6:52 AM99% 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)
Kerry Mann on May 1, 2008 10:52 AMi wonder why do you use Win Server when you run PHP :/
valajbeg on May 4, 2008 8:57 AMExcellent 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.
April Toys on May 5, 2008 2:30 AM@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 on May 6, 2008 3:23 AM@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 on May 6, 2008 3:28 AM@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 on May 6, 2008 12:02 PM@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.
A. Programmer on May 7, 2008 3:52 AM@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 on May 7, 2008 8:21 AM@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 on May 7, 2008 10:21 AM@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 on May 7, 2008 11:05 AMYou 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.
Dan on May 19, 2008 11:27 AM
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.
Will on May 23, 2008 11:26 AMI 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.
Richard X. Thripp on June 24, 2008 10:02 AMvery nice article
jocuri on June 26, 2008 2:43 AMthat's right!
schrander on June 27, 2008 4:27 AMI'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.
Peter on July 13, 2008 8:29 AMYou always get what you pay for.....
Plantage on July 17, 2008 5:26 AMYou 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
CAD bloke on August 4, 2008 12:05 PMIMO, 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.
Nenad on August 7, 2008 10:08 AMI'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.
sklep komputerowy Bydgoszcz on October 22, 2008 8:14 AMWorldwide 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.
Joe on November 10, 2008 10:34 AM
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,
Franchiseretail on December 8, 2008 4:17 AMIf 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.
Binary is on December 13, 2008 2:50 AMThe 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.
Speed Dating NYC on January 21, 2009 2:05 AMWordpress 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...
james on February 7, 2009 8:14 AMi 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
Windows Vps on May 13, 2009 9:29 AMGreat 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.
Sajaki on July 3, 2009 2:06 AMJeff,
Thanks for posting knowledge based blog, it’s really helpful to prevent routine mistakes.
Cheers :)
Data Outsourcing India on July 17, 2009 2:26 AMthanks for the inforamtion an greetings from Germany
trauringe on July 20, 2009 3:56 AMThanks for posting this blog!!
my motto: Mountains never meet, people always
thanks for posting this blog.
my motto: Mountains never meet, people always
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.
Volomike on July 29, 2009 12:22 PMThe above is really nice and informative post thanks for sharing. I will look forward for more information.
data entry india on July 29, 2009 1:36 PMthanks.I think it is very useful.
Levis Jeans on August 19, 2009 11:54 AMGreat Stuff..
Keep Your Good Work Going..
Regards!
Boblee
Er, isn't Bad Behavior an anti-spam plugin?
The Mighty Borkon on February 6, 2010 10:24 PMIf 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.
strongThat 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.
Jon Hohle on February 6, 2010 10:24 PM"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.
Jon Peltier on February 6, 2010 10:24 PMno 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
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.
Jon Tackabury on February 6, 2010 10:24 PMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |