WordPress 3.4 is just out. (Full list of changes for the technically inclined.) I was astonished to see that WordPress.org had found the time to make an almost content less video narrated by some bored British guy but not much time to really improve the software. The video is more about guitarist Grant Green than WordPress. Which makes sense as not much important has happened.
Grant Green guitarist
Instead of major architectural and database improvements (oh heavens does WordPress need those) we have semi-automated tweeting and the ability to browse more installed themes more quickly:
lots of themes we’ve made it quicker to browse them all at once without paging
Guys, a quick hint: if you have so many themes installed it’s difficult to browse them all, it’s time for a clean reinstall. You should have no more than two or three themes installed at any given time. The one you are using and the one you are working on and maybe one you are considering.
It is nice that theme preview is built in finally. But that functionality has been available for years in plugins.
Rather than these visually lollipops, what WordPress core really needs is some serious work on performance. There is so much left undone and unreviewed on that list. At the same time, “Support Facebook’s HipHop” has been accepted.
To take a concrete example, one of the worst performance issues right now is Revisions. Revisions are made every time anyone touches or opens a post. Any given post can easily end up with twenty revisions. That makes the live posts database twenty times larger. Huge tables like that make database caching in memory (a big performance help) much more difficult, requiring vast quantities more memory or elaborate MySQL tweaks to slice the database.
Far simpler would be to keep a separate table for revisions. Revisions are only needed about twice/week on one of our sites with thirty authors and ten posts/day). That simple change to architecture would vastly improve memory performance for WordPress. WordPress.org’s HipHop performance crew can’t even be bothered to keep the ticket open.
Four years ago rawalex wrote:
More importantly, the vast majority of the queries done on this table (every normal page view) doesn’t need this data. It isn’t a complicated concept, it is very basic design: Don’t load up tables with irrelevant data.
Some beardo named Ryan considers that this is a matter for the WordPress hackers list. Hackers list? Revisions and database structure are an essential core performance issue.
ryan boren: wordpress
performance issues belong
on the ”hackers list”
Enjoy the integrated tweeting on your very slow WordPress site. I guess I should be grateful to Ryan, Matt and co. for making it so difficult to manage a busy WordPress site: it only helps Foliovision’s business. Sometimes I wonder if the lousy WordPress performance on larger sites is deliberate: Automattic’s biggest business is as a WordPress consultancy as well.
At VIP.WordPress.com, hosting starts at $3,750 month. It shouldn’t be that hard to host a busy WordPress site.
Anyway enjoy the integrated Tweeting…and if you have a busy WordPress site which you need to run faster, come and see us. Our work is not inexpensive but is a lot less than $3750/month for hosting.
Relatively little known Grant Green’s career suffered on account of drug addiction. Let’s hope WordPress stops with its own eye candy fixes in time and deals with its more substantial core issues soon.
Another round of updates for all our clients for little gain. Let’s hope not too much breaks this time.
Alec Kinnear
Alec has been helping businesses succeed online since 2000. Alec is an SEM expert with a background in advertising, as a former Head of Television for Grey Moscow and Senior Television Producer for Bates, Saatchi and Saatchi Russia.
I also work on WordPress.com, which runs billions of pageviews a month across millions of blogs. A 10% speed-up means I can get rid of over a hundred servers… we pay a lot of attention to performance.
Along those lines, 3.4 includes a number of improvements there. Some users are benchmarking it 20-30% faster than 3.3.
With regards to revisions, specifically, because of the indicies WP uses the extra rows don’t add any query overhead, and even at 20x the size of most people’s tables are just a few megabytes, or even at tens of megabytes it’s not a big deal on modern systems with many gigabytes of memory. I’ve only seen a handful of blogs in the past 5 years where the size of the database was a scaling challenge, and it always came from comments not the posts table.
The wp-hackers list is where we discuss potential changes or improvements to developing WordPress.
Hi Matt,
Thanks for stopping by.
That’s exactly what I don’t understand: as you guys are running WordPress.com, Automattic should be more motivated to improve core performance.
We’ve found that both comments and posts table cause performance issues fairly early on. Of course we are dealing with sites with about 300K comments and 15,000 posts on relatively modest hardware and not vast specially structured server arrays.
I think Automattic might have started to become a bit out of touch after you moved to nginx. The server structure is so different under nginx that you do not run into the standard issues we do on Apache or Litespeed. Yes it’s possible to tinker enough with the database to get decent performance out of WordPress.
But our point is why should it be necessary to do that much engineering work just to publish moderately busy sites.
If you go through Trac on performance issues, there is a lot of relatively easy work left undone. This is the second time we’ve found major performance blocks and you guys have just swept it under the carpet.
If Automattic/Wordpress.org would really prioritize performance and stability for a few months rather than new features of questionable value, I believe we could double the speed of WordPress and halve the administrative maintenance requirements.