How can we find extra ways to test MaxScale? It‘s now working its way through a beta program, heading for general release. As part of the team responsible for its development, I’ve been looking for ways to find obscure bugs. Several approaches are involved, including unit tests and system tests. But another thing we wanted to try was to put a real life application, written by other people, in front of MaxScale.
What’s it all about?
To recap, the role of MaxScale is to present itself to clients as if it were a single MariaDB or MySQL database. In reality, it’s nothing of the kind. Instead it is an ingenious mechanism for talking to some kind of database group – maybe a cluster, maybe a master-slave group, maybe some more esoteric combination of multiple databases. MaxScale can adopt a variety of strategies to decide which of the back end databases will receive any particular query. And it’s extensible as additional modules are added.
For this group of tests, we used a master database with several slaves. MaxScale was configured to automatically route any SQL that involved a write operation to the master database. Requests that only read the database were automatically spread across the slaves. With this setup, the application in front of MaxScale should perform normally without needing to know it is actually engaging with a group of databases. Yet the potential scale of operation is greatly increased over use of a single database.
Why test MaxScale with WordPress, Joomla and Drupal?
An awful lot of websites are built on a Content Management System (CMS). It would be nice to be more precise about numbers, but reliable web statistics are very hard to come by. Certainly the number of CMS based websites runs to tens of millions, maybe hundreds of millions. WordPress is the top choice, and Joomla comes second. We also carried out tests on Drupal, another popular CMS, and Aliro which I wrote some years ago.
A CMS relies on database storage, typically MySQL/MariaDB. Each request for a web page involves a number of SQL requests. In the case of the Joomla page we used for load testing, the average was 25 queries per page. Some of these are writes; most are reads. The initial setup of each CMS also worked through MaxScale, and typically involved table creation and large INSERT statements.
Tests of this kind give us an indication of whether MaxScale can operate correctly against an unknown client that was developed by others without any knowledge of MaxScale.
What happened with Joomla and others over MaxScale?
Our first tests went very smoothly. Then we realised that the configuration was wrong and was bypassing MaxScale! With that resolved, we found ourselves up against a fault that was already being investigated by one of the team. Once the fault was fixed, all the systems worked flawlessly. Utilising web load testing tools, we were able to prove that the systems continued to work with increasing numbers of clients. Any tail off in performance seemed to be attributable to the CMS rather than to MaxScale. Encouraging results, but we’re still testing!