WordPress – lightning fast response
Lightning fast? No chance!
Here at Jaybase, we’ve worked over the years with many programming languages, frameworks and the odd CMS (we’ve even built a fair few CMS of our own). When it comes to CMS, there is no shortage to choose from – WordPress, Drupal, Moodle to name but three of the more than 1,200 that are out there. One of the advantages of these systems is their relative ease of set up and maintenance. So, you can have a blog site up and running in minutes on a hosted server for just a few dollars/month. But, chances are your system is sitting on a shared server with 1,000 other CMS systems. In short, performance may be an issue. If you then go on to use the full capabilities of your chosen CMS and start doing e-commerce with much more than 500 products then the chances are you’ll see response times getting longer and longer instead of being lightning fast. So, why is this?
Any CMS has to be all things to all men (and women). I might want to post pictures of crazy cat antics in a blog format. You might want to sell dried fruit. Any decent CMS will provide both sets of functionality through plugins or modules and these can be mixed with all sorts of other fancy features to provide a comprehensive package to entice your users. Now, all these fully-featured processes have to fit within the chosen CMS framework and adhere to its core concepts . Thus, any WordPress plugin has to use the in-built data-handling mechanisms and conform to a defined structure and method of working. This a good thing as it means, in theory at any rate, you can use lost of plugins safe in the knowledge that they won’t interfere with each other. Standards are everything in the CMS world!
The disadvantage here can be just that conformity. One plugin may grab some data from the database because it needs it. Another may grab the same data from the database for its purposes. What we have here is a lot of code being run and a lot of database accesses. If you ever look at the monitoring systems available with your CMS, you’ll be staggered at the vast numbers of database calls racked up by just one click! You may also be surprised how many of them are grabbing the same data!
Dull as ditchwater - the response I mean
Recently, we started a system conversion, moving a complex e-commerce system from a PHP framework to a CMS-based system, in this case WordPress. Most people do it the other way round when WordPress starts to run out of steam but, hey, we like to different and we love a challenge! Our big problem was the 200,000 products the system featured! That’s about 195,000 more than most WordPress e-commerce systems and sure enough, even on one of our dedicated servers, we immediately saw that with just 100,000 products our users might expire waiting for a response. This dedicated server came with PHP 5.6.23 and a fairly standard MySQL database, version 5.0 so way behind the line. Our first port of call was to upgrade the database server. We’ve worked with the Percona Server elsewhere so we grabbed the latest version from there – at the time 5.6. The Percona Server is the full Enterprise Edition with the best of MariaDB thrown in and their own InnoDB engine, XtraDB. This provides serious performance and integrity hikes and without doing anything other than dropping our database into Percona, we saw an avergae 40% drop in database responses. With some more tweaking of InnoDB indexes (we tried the TokuDB engine but saw little difference but maybe more on that another time) and adding some new variables into the MySQL configuration, we got up to 50% improvement.
Good but a response of 3 – 5 seconds is still way outside what we wanted. So, bite the bullet and upgrade PHP. We’d read a lot about performance improvements in PHP 7 and when we built PHP 7.0.8 and ran it, they weren’t wrong! Response times dropped to 1 – 2 seconds and resource usage on the server dropped dramatically too. Good news all round but we were still between 1 and 2 seconds and we wanted more.
Enter Redis. Redis is an object caching system so stores database objects, etc, in memory. Like Percona and PHP 7, there’s no cost involved apart from the time taken to understand the product and its configuration. We needed a WordPress plugin to ensure WordPress could use the Redis object cache and after looking around, we chose redis-cache. When we restarted everything with Redis sitting in there, we got what we wanted – sub-second responses on our product set!
None of this was trivial. You need to understand a lot of software systems and sub-systems and how they integrate (or not) to put it all together – unless your hosting provider will do it for you! There’s a lot of package building, configuration and re-configuration to get the optimal set up. But it can be done and soon, we’ll have one of the largest WordPress e-commerce systems around. And it’ll perform!