making bbPress (and WordPress) work better!

Posts tagged “wordpress performance

Another Performance Regression in WordPress 3 Future

MySQL 5 is proven to be slower than MySQL 4, and WordPress doesn’t require any MySQL 5 specific features to operate.

But they announced today that WordPress 3.2 will require MySQL 5.0.15

MySQL 5 has performance improvments mostly for InnoDB which WordPress does not use. MySQL 4 is faster at MyISAM which the is the more common db format (and used by WP).

Also, they are insisting that servers run PHP 5.2 minimum for WP 3.2

While PHP 5.2 is faster than PHP 4.4 (and PHP 5.3 is measurably faster than 5.2) it’s not very hard at all to support PHP 4.4 In fact I’m sure they are going to have to go out of their way to force PHP 5 to be required by actually REMOVING simple code that helps PHP 4.4 already in WP.

So why not keep software flexible when it’s easy? The reality is this is probably to help keep reports of security problems with WordPress down by forcing people to keep their servers up to date.

Personally I don’t think that is WordPress’s business or responsibility but I guess people have a choice which software they want to use, especially when it’s free.

ps. You know what else just dawned on me – Matt has data on a million servers that run WordPress when they “phone home”. This doesn’t bother anyone?


WordPress still uses the nasty SQL_CALC_FOUND_ROWS

(update: please don’t try this patch as is on WP versions newer than 2.8 – I am only leaving it here as a suggestion if some coder in the future decides to tackle the problem)

We’ve known for over two whole years now that SQL_CALC_FOUND_ROWS did nasty things in bbPress 0.8

It was fixed by mdawaffe (Michael) after discovering how SQL_CALC_FOUND_ROWS caused an overload on the Automattic wordpress.org forum servers due to a MySQL bug.

But to this very day, it’s still used in all WordPress versions, up to and including 2.8.2

(Even more ironic, now that bbPress 1.0 has switched to the backPress core which is based on WordPress, SQL_CALC_FOUND_ROWS is back inside bbPress, though it works around the bug)

SQL_CALC_FOUND_ROWS is typically three times slower than using COUNT() on the same query without LIMIT and ORDER restrictions.

I’ve seen at least one slow-log for MySQL that is FULL of SQL_CALC_FOUND_ROWS queries from a large WordPress installation on a dedicated server that took 11-15 seconds per query (and crashed MySQL, repeatedly).

Here is my quick & dirty patch to the WordPress (and BackPress) core that attempts to change SQL_CALC_FOUND_ROWS to the COUNT() workaround – it’s inside wp-includes/query.php – it’s tested working but not heavily tested so use with caution and let me know if you have improvements?

My changes are against the file from WP 2.5.1 but the file has barely changed since 2.5, even 2.8 is virtually the same so it should be easy to modify other versions.

There is one other use of SQL_CALC_FOUND_ROWS left in WordPress but it’s in the admin section so I am not going to worry about it for now.

More about the MySQL bug due to it’s poor optimization:
http://bugs.mysql.com/bug.php?id=18454 (cache)
http://bugs.mysql.com/bug.php?id=19553 (cache)
http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/


WordPress will be 15% faster under PHP 5.3

I may finally upgrade my servers from PHP 4.4.8 to PHP 5.3 when it’s released. I’ve been sticking to PHP 4 because I don’t use anything that needs 5.x and 5.0 is slower than 4.x is some situations.

But apparently the performance has been put back into 5.3 according to this obscure posting on php.net which quotes WordPress (among others) as an example of performance improvements:

http://news.php.net/php.internals/36484