You may want to try different blog software.
Try this one…
http://www.dotnetblogengine.net/
Themes…
http://www.dotnetblogengine.net/page/themes.aspx
Extensions…
http://www.dotnetblogengine.net/page/extensions.aspx
This is slightly out of topic…so excuse me. Why PHP? Are you leaving Microsoft development because you’re partnering with Joel and he doesn’t like MS products?
I agree WP-Cache should be included in the default bundle. And I agree that you need it for WP to perform properly. There’s really no reason not to download, install and activate it, though. It comes pre-bundled in DreamHost’s One-Click Install of WordPress for a reason.
With WP-Cache enabled, WordPress flies like an unladen European swallow. Not only does that cause all WP pages to be cached, but they are served in a RESTful, HTTP-friendly manner too, with Last-Modified headers and everything you need to do conditional GETs.
Although it doesn’t improve WordPress’ code quality, I’d also recommend you to host it in a Linux environment and preferably with mod_php (not FCGI). Just out of interest; are you running the database and web server instances on the same virtual machine?
“[WordPress 2.5] came out of the box with a broken file uploader for a whole lot of people because of its required dependence on a Flash component.”
Yes, it’s dependent on Flash, but if you don’t have flash it gracefully degrades to the old pre-2.5 file uploader. What’s the problem here?
jumping topics…
“The problem is, besides the huge task of refactoring itself, it’s impossible to change WP into something well structured without breaking all plugins and templates, and it’s this ecosystem of add-ons that is major part of WP’s success in the first place.”
If the plugins properly use the hooks as they are supposed to, you should be able to do just about anything to the core backend without breaking them. Reworking the core would only break plugins that try to access things directly. Isn’t that the whole point of abstraction???
The more modular and manageable the web-app, the worst the database query efficiency.
L-A-M-P, they were designed to work together
LAMP was a retronym coined for a particularly popular stack of software (each having been developed entirely independently).
Are you hosting with Godaddy? (as your WHOIS lookup suggests)
From their site it looks like they’re running Windows 2003 on virtual dedicated, or do you know something I don’t?
LAMP was a retronym coined for a particularly popular stack of software (each having been developed entirely independently).
Apache was built to run on Linux, as was mysql. PHP was built to run on Apache. It may be a retronym, but they are all very closely linked.
A. Freaking. Men.
Dive into the code. Prepare to be disappointed. Browse the Trac bug entries. Prepare to be upset.
Consider that Automattic just got $25 million in round B funding. Prepare to understand how dumb stuff like the subprime crisis is possible.
20 database lookups per page view is unforgivable. 20 times PHP had to contact MySQL, send a query, wait for it to be executed, get the results back and parse them into PHP-usable data. I’ve seen some blogs that had stats of up to 50 some database queries. Again. Totally unacceptable and unforgivable, given what WordPress is supposed to be doing.
If you have a 1,000 users, that means 20,000 database queries being executed unless you have some very tight caching going on there. And… this is considered acceptable out of the box?
In the open source world, if you want something, you might have to do it yourself.
Go for it Jeff!
The Roll Your Own solution works fine for a super-basic blog, but honestly, wordpress has a LOT of features baked in. The plugin system, auto-generated RSS feeds, creating “friendly” urls, letting you define the “friendly url” structure… categories, tags, permalinks, pagination, widgets… You’ll pretty much need a team and a year or so of 40-hour weeks to get to where wordpress is today.
On the other hand, if you don’t care about any of that… A very basic blog can be thrown together in about an hour, given enough familiarity with the language you’re working in. I tossed together something that fit the bill for what I needed in Coldfusion in about a half hour (of course, CF is more of a RAD language for web stuff than ASP.NET, so mileage will definitely vary)
Also, you might want to check out some other alternatives: Pivot’s also PHP, and I was a fan of it- only switched over to Wordpress because the Admin ui drove me nuts (they’re working on that).
“blog.stackoverflow.com is getting, at best, a moderate trickle of incoming traffic”
trickle defined based on your stats? Or just on a hunch? Joel linked to it, and he’s got an incredibly popular blog himself.
Also, how does WordPress handle or react to RSS? Could that pounding have anything to do with all the RSS programs your readers use? To say nothing of now all the iTunes instances hitting it for the podcast.
Thanks for the link to WP Super Cache! If you scroll to the end of that page you’ll see a huge spike of traffic that was handled by laughingsquid’s WordPress blog in combination with WP Super Cache.
This plugin goes beyond what WP-Cache does by creating static html files and then serving them with the help of a few mod_rewrite rules. With that installed even a small web host can survive a huge bombardment of hits.
Why is it not included by default? I’m not sure, but a few issues spring to mind:
- Some people don’t have access to mod_rewrite so the static html file functionality won’t work.
- Added bloat. Despite the CPU graphs above, a bare bones WordPress install works perfectly fine for many people. Why make it more complicated?
- “Why doesn’t widget X update immediately?” People expect things to update straight away. Full page caching defeats that unless you invalidate the cache for every small little change, or use Javascript. I recommend using Javascript, but the cache does invalidate for most of the major actions that happen on a blog. (Publishing a post or comment mainly)
You should look up the object cache stuff Ryan Boren worked on. There are memcached, APC and Xcache backends for that if memory serves. With that installed your blog can be fully dynamic and not hit the db.
Here’s a pretty good overview of it:
http://neosmart.net/blog/2008/wordpress-25-and-the-object-cache/
I took the path of least resistance, and registered my blog with Wordpress themselves in the end (let them take the strain).
I’ve seen the same situation develop with several open source projects - as soon as you have different people pulling in different directions, you lose focus. The biggest problem with Wordpress is that there is no one core of developers in charge.
@mark - Drupal ain’t no magic bullet. I maintain some relatively large Drupal sites and let me tell you, it has its own scaling and caching issues.
The built-in “Minimum Cache Lifetime” function is totally broken in the latest 5.x and 6.x releases and the Free Tagging functionality works in such a way that it creates several temp tables on disk every time you visit a tag page.
Comparing .Net to WordPress is apples to oranges. Heck, comparing .Net to PHP is peaches to strawberries. Once you say ‘.Net’, you are talking about a specific framework which runs in a limited set of environments (i.e., Windows).
OTOH, WordPress is written to run in a very heterogenous set of environments. It can run under Window, Linux, BSD, MacOS. It can run under Apache, IIS, and a couple of other web servers – just about anything that supports PHP and MySQL. It can run under pretty strict shared hosting setups, where the user might not even be able to modify the directory permissions necessary to allow caching. So I think it’s at least a little bit forgivable that caching is left to plugins, for those who need it.
As mentioned above, checking the MySQL query cache (and other tuning) might be another area for investigation. The WP Object Cache is getting a rework, and is supposed to return in WP 2.6. I don’t think it will turned on out of the box, but again, for those who need it, the underpinnings will be there.
Out of curiosity, I assume the .Net caching bits you mentioned are similar in nature to PHP’s output buffering? So, you have to tell it where in the filesystem to put the cached files, yes? And I assume that this also means that you have to make sure that the web service has permissions to write to that location? Or does .Net make this a magic-bullet that you just fire and forget?
But seriously, there are a lot of layers of optimising you need to make WP run fast.
- MySQL query and key caching will save you a lot of time. Most times a page is displayed and nothing has changed.
- PHP opcode caching. There are several. I use xcache.
- Selectable object cache. It’s a little known fact that Wordpress does some half-arsed internal caches of intermediate objects; an even less-known fact that you can get it to use PHP opcode caches or memcached to hold those intermediate objects. This combination can really zip up the PHP side of things.
- Reduce the number of plugins running if you can.
- Don’t put your blogroll, archives or author listings on the front page. Move them onto a separate page. Each of those listings performs a nasty old bunch of queries. Not single queries that reduce to a single result set; oh no, dozens of queries.
I agree that Wordpress is an evolutionary dead end. But unfortunately it currently does what I need it to do. I have Stockholm syndrome.
Email me – jacques@chester.id.au – if you have any other questions or queries.
Blame Canada…!
Apache was built to run on Linux
No, it wasn’t.
as was mysql
mysql was originally built on Solaris.
PHP was built to run on Apache
No, it wasn’t.
but they are all very closely linked
Actually, no they aren’t. PHP for years was run predominately as CGI, which is basically as unlinked from the webserver as possible, and to this day has its own world of configuration separate from the web server.