WordPress database performance: Percona server vs MySQL w/o InnoDB

1 Views

I don’t want to ask a subjective “which DBMS is best?” or “which DBMS of these two is better?”. This doesn’t have to be a fanboy debate.

Rather, I welcome any benchmark test results or specific experiences, when it comes to one specific criteria – performance – especially with respect to one particular application: WordPress.

Read More

I understand that WordPress doesn’t use InnoDB, and so disabling InnoDB in MySQL can speed things up. On the other hand, Percona is a MySQL fork that replaces InnoDB with XtraDB and also claims to be highly efficient, high-performance.

How does each stack up on performance when it comes to running WordPress? (no need for competition…both might come out looking very well, for all I know)

I have tried searching generally on Google, but haven’t come across so much as an intelligent discussion, let alone performance benchmark tests.

Would greatly appreciate if any of the experts here could share their experiences. Many thanks!

And please keep any smug, snide comments like “why don’t YOU try” to yourself. If I could, I would. And the purpose of Stack Overflow is to share expertise and learn from each-other, not to do everything yourself.

Post Views: 1

Related posts

Leave a Reply

2 comments

  1. This question is less “MySQL vs. Percona Server” than “MyISAM vs. InnoDB/XtraDB”. They both have their own performance characteristics and which storage engine is right for you largely depends on your workload. Most WordPress sites are low traffic and read-mostly, so as long as your data fits into your buffer pool (for InnoDB/XtraDB) or key cache (for MyISAM), I would expect not-too-dissimilar performance.

    Having done a lot of work on WordPress database optimization, I can tell you that the performance of your WordPress site depends more upon the class of your hardware and your chosen plugins.

    • You should use a Caching plugin so that you can just avoid a ton of database read requests
    • You should avoid plugins that issue expensive queries (sadly, this covers most plugins)
    • You should prune your comments (usually comments are 99+% SPAM so the ones that are marked as spam are just sitting in your database taking up space)
    • Your host should have enough RAM for the hot dataset to fit in memory

    If you really want to go into detail about MyISAM vs. InnoDB/XtraDB, you can check out the following links:

    http://www.mysqlperformanceblog.com/2009/01/12/should-you-move-from-myisam-to-innodb/
    http://www.rackspace.com/knowledge_center/article/mysql-engines-myisam-vs-innodb

    So, to make a long answer even longer, you’ll need to profile your MySQL instance after you can generate production traffic. I know you said you couldn’t, but … this question is kind of like me asking “What haircut would look best on me”, without including a picture.

  2. WordPress can use InnoDB (or XtraDB) just fine. I have done consulting and training for sites that host WordPress at scale, using any of MyISAM, InnoDB, and XtraDB.

    WordPress 3.5.1 creates tables without specifying the storage engine. So it honors the default storage engine on whatever instance of MySQL you’re using. As of MySQL 5.5 (ca. December 2010), the default storage engine is InnoDB. I tested installing WordPress on a virtual host running MySQL 5.6.10, and it created tables using the InnoDB storage engine.

    I don’t have any benchmarks to share, but those would be of limited use anyway, because performance depends so much on the given hardware, the traffic load, and other factors.

    A CMS like WordPress tends to be heavily weighted toward read-only queries. This is where InnoDB should give good benefit, because it caches data pages as well as indexes. MyISAM only caches indexes, and relies on the filesystem cache to hold data.

    So the key to making WordPress perform well is to allocate enough innodb_buffer_pool_size to hold the data and indexes for all your tables. The data size of a WordPress site (even one with hundreds of articles) isn’t typically very large, so you probably only need a few GB of buffer pool to hold all frequently-requested data in the buffer. Once the data and index pages have populated the InnoDB buffer pool, 99.9% of your queries will be served out of RAM, and the site will have great performance.

    As with any caching system, the real killer to performance is when your “hot” data is larger than the cache, forcing queries to incur disk I/O. A single disk I/O is worth a few thousand RAM accesses, so you want to serve content completely out of RAM as much as possible.

    The improvements in XtraDB are designed to help as the number of Threads_running gets higher, or the buffer pool gets larger (e.g. dozens of GB). It’s unlikely that a single WP site will exercise either MySQL or Percona Server so heavily that these improvements will offer more than a slight advantage. Unless you’re going to host hundreds of WP sites on a given server like a hosting company.

    You may even find that the bottleneck ceases to be the database, and then you need to focus on front-end optimizations.