Behold WordPress, Destroyer of CPUs | Hacker News Reader

Behold WordPress, Destroyer of CPUs

codinghorror.com

46 pointspchristensen35 comments

I confess to deeply mixed feelings about this post. I guess I don't like his tone. And there's a problem, I can't really criticize the post without descending into ad hominems of a sort.

I guess I would rather read an essay about how much caching improves product X than an essay saying that the developer of product X is an idiot for writing a product that needs caching. Both essays have the same factual content, but I admit to bias towards the former, especially from one programmer to another.

Well, remember that Coding Horror is more of a classical personal blog or online diary style work, rather than a medium for delivering essays. Jeff freely admits he tends to shoot from the hip, in contrast to guys like PG or Joel Spolsky (Jeff talked about this briefly in the first stackoverflow.com podcast). As a result from time to time you get posts that more emotionally driven by Jeff's issue du jour.

For me I just tend to take Jeff's tone with a grain of salt rather than expecting each post to be dispassionate analysis. Jeff simply doesn't vet his material the same way as PG, but we end up with more of it from which occasionally really good observations and discussions result.

Atwood gets a lot of crap from the HN crowd, so it's great to hear a reasoned, dispassionate argument about the pros and cons of Coding Horror.

The "shoot from the hip" comment was that while Spolsky might go over one of his showcase pieces 30-40 times, Atwood would look at it maybe once or twice while he was writing it and the hit "Publish".

And as a result, Joel's writings are a lot more valuable.

I have a personality like Atwood -- if I'm mad about something, I immediately feel the urge to write a scathing and negative blog entry. Every time I do this, though, I get a lot of negative feedback. So, I try to tone down my personality and stick to instructional entires now, and amazingly I get positive feedback every time. Nobody cares what I think... but if they learn something, then my blog is worth reading.

"Show, don't tell." is what they teach in elementary school. It is a very valuable piece of advice. (In this case, I mean "show why foo is good", not "tell the reader that bar is bad". Criticism and snarkiness breads criticism and snarkiness.)

I think he could provide more understanding to his readers (and possibly for himself) if he were to explain exactly why each of those queries are made.

Wordpress is meant to make online publishing easy for non developers and it has to make sacrifices for flexibility. Wordpress serves most people very well and there are many high traffic sites running it. Surely he will be able to do the same for himself if he chooses to run Wordpress.

"For me I just tend to take Jeff's tone with a grain of salt rather than expecting each post to be dispassionate analysis."

Well, I like a lot of what he writes (by a lot, I mean, "a lot of posts every year," not necessarily, "most of his posts.") I'm quite happy his posts aren't dispassionate. Shrug. I guess I'm being remarkably asymmetrical and patently unfair: I want his passion, it's just that this post is a necessary consequence of his style.

I'm glad someone finally spoke out against WordPress like this. This has bothered me for ages, but whenever I bring it up to people the argument is always, "cpus are cheap." But, I don't want to buy a new high end server just to run a blog. I want it to be speedy fast on shared hosting without fussing, by default.

If you want a feature in an open source project, the logical idea is to send them a patch.

I think most people who read HN would have thought of that; from Jeff Atwood's article, it sounds as though the primary problem is a political one, not a technical one. A plugin already exists that can be that "patch," but the project leaders are dismissive of the problem.

Makes me feel not-so-bad for using the tired, aging, not-as-popular Blogger platform for my blog. It's hard to have overwhelming CPU loads serving static pages.

Caching needs to be built into WordPress? Hrm, I guess great minds think alike - http://news.ycombinator.com/item?id=168268 ;)

And to say that WordPress is not sloppily programmed is to say that you have never actually looked at the source code. I dare you, I double dare you. Wake up and smell the ashes.

About a year ago i looked at the WordPress code. My PHP knowledge is limited, but it was easy to see that the code was not very good. Perhaps it has improved, but i personally wouldn't use it, especially on a server that runs important services.

I've looked at it on occasion as well, and while it's not exactly a work of art, it's not exactly terrible either, especially for an open source blogging product.

If you really want terrible code, take a look at Pivot. That's awful. WP is just, well, spaghetti-ish, I guess, but not terribly so.

Even worse is chyrp. For reasons unbeknownst to me, they designed it in such a way that it ends up making 55 queries to render http://chyrp.net/blog/. This only increases when more content is added (so my assumption is that the authors don't know what a join is). Also, the last time I looked, it took your password, md5'd it (without a salt) and put it in a cookie for authentication to the admin. WordPress looks amazing compared to that.

Disclaimer: I'm the dumbass developer of Chyrp. I was pointed here by a follower. :P

55 queries? I see 18, and 20 when logged in. Something's weird there. Admittedly, it used to be quite high (116, nervous chuckle), but nowadays it hovers below WordPress' query count.

I don't know where you're getting that whole admin authentication thing from. Nowhere in the code does it do anything remotely similar to what you said. The cookies simply hold the browsing user's ID and md5ed password (the md5 is the only information on the password that is stored), which is then authenticated. It's not a username and password for the admin area. It's just the information of the user who's logged in. Nothing new.

There's no single "is_admin" check or anything of the sort. There's no "authentication to the admin". It's not an all-powerful section that checks for a single thing before giving you access to every function. The group that the browsing user is associated with must have the proper privileges to perform the various functionality that is checked throughout the administration section.

As for using salts on the md5 encryptions, I don't see anywhere in WordPress's code does that either (I just downloaded the latest copy). I might add it in to 2.0, though. Should be a fairly easy change.

If you want the software to improve (which doesn't exactly seem to be the case), I just think you should either file tickets or confront the developer (me, and a couple contributors in the IRC channel) instead of spouting off misinformation on other sites.

"If you want the software to improve (which doesn't exactly seem to be the case), I just think you should either file tickets or confront the developer"

Consider removing the parenthetical remark and adding a period after a statement like this and leaving it there. Simple, powerful, and makes your point:

"If you want the software to improve, I just think you should either file tickets or confront the developer."

You could remove a few more words and make it

"If you want the software to improve, file tickets or confront the developer."

;-)

OK, OK, you can be my editor. Just stop following me everywhere and correcting my statements. Sheesh. Normal people just turn in a resumé or something.

Let me be perfectly clear. I have not investigated the code of Chyrp, primarily because I was turned off right away by a) the number of queries made, b) unsalted-hashed password in cookies (not that salted-hashed password in cookies is any better) and c) the fact that I dislike PHP. I should also mention, that I'm NOT an advocate of WordPress either.

I didn't say that there's an is_admin thing, just that the password is stored in a cookie, seemingly for the purposes of authentication. Storing a hashed password like that is probably a bad idea, and perhaps even worse is storing the associated user id with it. Logging into the demo and looking at my cookies shows both of these things. This does nothing to prevent session hijacking, at all. In fact it doesn't even make an attempt.

In regards to queries, I should point out this screenshot taken a few minutes ago: http://apgwoz.com/images/chyrp-85.png in which you'll notice, 85 queries, a bit worse than the 55 I saw before. It was probably my mistake for linking to the homepage, which shows 18 queries, rather than an inner page with other content. I apologize for that lack in judgement.

As for wanting the software to improve, you're right--I don't care. It's not solving a problem that hasn't been solved many times before, and aside from looking pretty I don't really see the need for a new blog platform. Just my 2 cents. Good luck in your efforts to release a version 2.0.

EDIT: I wanted to commend you on your sense of style. I really like the Chyrp homepage's design.

Strange, I've never had that many queries show up in testing the comments module, but now I see it too. I'll look into it.

Thanks for the design compliment. :) I might be changing it soon though, since white-on-black doesn't really work well for other sections of the site, like the documentation and forums.

Storing the password in the cookie? What possible reason could you have to do this? Storing the MD5 isn't much better than storing the plain text. And anyone that doesnt use a salted hash when keeping passwords in a database should not be allowed to program. Then again rampant security problems is a big reason why I don't use PHP apps.

With due respect, but I don't think storing an MD5-ed password in a user cookie is a smart thing to do. It's probably safer to store a session id or somesuch.

I thought this was interesting because I have WP on a shared host. It sure is slow sometime but I didn't know if it was the host or WP. I guess the answer is probably ... both :) Makes me wonder if part of WP's success is that most people don't have it on their own server so they don't have to care as much about performance.

Now I'm resolved to install WP-Cache!

I'd advise using WP Super Cache instead. It's based on WP-Cache, but allows you to generate static HTML files as well. I've found it vastly improves WP's performance on shared hosting.

http://wordpress.org/extend/plugins/wp-super-cache/

It would be interesting if he could provide similar usage graphs for Movable Type and do some real data-backed comparison instead of ranting.

...because serving static HTML pages uses lots of database queries...

Wordpress or Windows (that he is using)?

I read this Jeff's blog as some is interesting, but I always laugh at how he is so pro-windows.

When I read he was going to do some web stuff I was wondering if he would use a windows server. I admit I don't keep up on what MS offers in the server side but it seems linux + apache is still a better choice.

Unless you're already extremely proficient on [your tools] but would take a lot of time and tweaking to learn the ins and outs of [other supposedly better tools].

> I read this Jeff's blog as some is interesting, but I always laugh at how he is so pro-windows.

On the plus side, he's not pro-Windows in the sense of being an evangelist or anti-something else. He's been working for a consulting business up until now, and there's great money in .Net consultancy, just like there is with Java. It's just a very different world from the LAMP-style web community.

> I admit I don't keep up on what MS offers in the server side but it seems linux + apache is still a better choice.

People publish working websites all the time on Java+whatever and on .Net+Windows, and Microsoft is working to make Windows/IIS a workable platform for PHP. I would personally recommend a LAMP-style stack for someone trying to decide what web technology stack to learn, but for someone who already knows a different stack, it may not be worth the trouble unless you need immense scale.

The fact that he's running it on IIS through FastCGI seemed to me to be a bigger problem than the fact that he's running WP as well. Not because I don't think IIS is a capable web server, but because Wordpress seems to me to be primarily oriented towards Apache + mod_php. Maybe WP is doing something that's really stupid on IIS + FastCGI but on Apache + mod_php it seems to run fine to me. I just clicked through a poorly visited WP blog of mine while monitoring top and CPU never spiked above 9% use on a 3GHz celeron. (this very same blog until a year ago ran on a celeron 400MHz with no problem as well, btw).

That said, he does have a point that WP's insistence on making everything dynamic is rather silly.

That's relevant to his complaints about observed CPU usage but irrelevant to the observation that WordPress makes excessive database calls and doesn't cache intelligently.

Better solution: Build caching into the DB. Then every program using the DB gets free data caching and there is more general code reuse. Interesting how RDBMS's like Postgres and Oracle already have it.

I don't see how caching in the DB would improve performance much. The best you could do would probably be to cache the most expensive queries. The main advantage of having caching in your application is that you can cache your data in a more high-level way, i.e. taking into account the way the data is going to be used. So you can pre-process your data as much as possible and store the result of this. Compared to that a cache in the DB would be rather dumb. This isn't to say that a database cache is useless but just not a replacement for having caching directly in your app.

What RDBMS's don't have caching? If we're talking about mysql, there's a query cache, a data cache, more...

Reply on news.ycombinator.com