Then I noticed something last morning that made me think. I know that does not happen often but I like it when it does. I happened to click on the “Activity Log” tab on the VaultPress dashboard and found the following.

VaultPress Activity Log

For those of you that are not the programmer types, the above is a list of all the database “writes” that this blog had performed in the last 3 minutes. Also for the non-programmer types, database reads and writes for the most part, writes more so than reads, are what increases or decreases the time required to produce webpages that are generated by applications with a database back end. That was a mouthful. Simply put, in general, the less interaction with the database or the more efficient the interaction, the more efficient your page. So when I found this nicely tabulated list of database queries with past histories of each entry, I was pretty happy. Now I know which plugin(s) the above queries are from, I can remove them and/or fix them and the problem would go away.

Now back to VaultPress. What an elegant way to troubleshoot errant code that is write intensive! It acts like a scrolling database change log, along with the recent history of all such activity, for each commit! This is the stuff of geek dreams!

Not only does the service offer you peace of mind from disaster, protect your blog from malicious file changes (version update oversights notwithstanding), it also gives you a very elegant way to perceive your blog, in real time, from the perspective of your database.

I can’t wait to find other nondescript ways that VaultPress will prove to be useful. Besides the obvious stuff, the statistics, the security and now the activity log, what other gems have you found hidden in the vaults of VaultPress?

The change really comes as no surprise. Both PHP 5 and MySQL 5 are far more secure than their predecessors and they are actively developed. How long has it been since an update was made to PHP 4 and MySQL 4? The final version of PHP 4 was released during August of 2008, followed by the final version of MySQL 4 on December of 2008. Both PHP 4 and MySQL 4 have been discontinued for almost two years.

The WordPress team is confident that the change in requirements will be relatively inconsequential. According to Mark Jaquith, “Only around 11 percent of WordPress installs are running on a PHP version below 5.2 [and] fewer than 6 percent of WordPress users are running MySQL 4.” Mr. Jaquith adds that most users running a PHP version less than 5.2 belong to hosting providers which actually support PHP 5.2 or higher. These users may have the ability to enabled PHP 5 via their hosting provider’s control panel or request to be moved to a server with PHP 5.2 or higher and MySQL 5.0.15 or higher.

Arguably, some hosting providers still swear by PHP 4 and MySQL 4, but considering that both Drupal and Joomla will sport similar requirements later this year, many will be forced to finally offer PHP 5 and MySQL 5. If your hosting provider insists on forcing you to use a PHP and MYSQL version that has been discontinued for almost two years, consider the cliché “there are many fish in the sea” and find a new hosting provider.

Hot on the heels of this announcement is the new Health Check plugin which will immediately confirm your server’s WordPress 3.2 compliance upon activation. The plugin will be receiving several additional features in the near future, but for now it should provide peace of mind for most of you regarding the impending change in WordPress’ requirements.

WordPress Super Cache does a pretty neat job too at handling heavy traffic, however, there will be a time when the cache in itself will not solve your problems and you will need to make changes to your server setup in order to ensure that your website loads properly and fast.

One of my pet projects on my personal websites has been to scale the site to allow around 70-100 thousand+ users to seamlessly access the site without having to suffer slow load times on a daily basis.

I did tweak my server quite a bit, however, after a point of time I ran out of tweaks and looked at what I could do to scale the system to seamlessly manage more traffic. I did manage to handle traffic to a point by tweaking the servers, but alas the traffic kept increasing and my I ran out of tweaks.

This is when I started to scale the system itself to handle more traffic. Though I am not done fully yet and will do some more changes in near future to scale it further, I thought it best to document my changes so that others could benefit from it. So here is the first part, which includes a tutorial on how you can scale WordPress by using a master-slave (replication) setup for MySQL.

Note: The guide is aimed towards users use standalone WordPress installation on a VPS or dedicated server. Shared hosting providers do not allow users to change system settings, and this implementation will require to make few.

What Is MySQL Replication or Master-Slave Setup?

MySQL replication basically involves an automatic replication of data from one MySQL database server to a different one located on the same machine or another one. In this scenario you can setup a master MySQL database to which data is written, once that happens the data is then automatically replicated across all the slaves you have setup.

Let me give you a practical example; you have database A where inserts/updates happen, now in a master-slave setup this will be your master server. With replication, you keep the master database as is, however, you add new slave databases which will constantly check back with the master database for updates and then automatically replicate it to themselves without you having to run manual SQL update/insert statements.

So when you insert new data into the master database, the slave database will be notified and will automatically copy the new data over to itself, this replication happens quickly enough that you may not even notice it. If you are not yet clear about what this means, you can visit the MySQL manual for replication.

How Does MySQL Replication Help?

In a production environment of a website database reads constitute a major chunk of the total database accesses. So for example, if 1000 users visit your website, there might be somewhere around 1000 or more hits to the database, depending on how your site works. The latency to respond to those requests will be higher when compared to a site which gets lesser traffic since all those 1000+ hits have to be processed by a single database.

With MySQL replication you can distribute the reads between the master itself and several slaves, so the latency to respond back to requests will be much lower since the load is distributed among several servers.

In addition to that, since you are replicating data, you will also have backups in several places, which you can then use as failovers if your main database has any problem.

How Can You Replicate MySQL Data In A Master-Slave Environment?

Replicating data from a master to one or more slaves is very easy, all it takes is a few configuration changes. A master server will have to be configured only once, and so will a slave. However, you might have to repeat certain steps on the master server in order to grant privileges to multiple slaves to access the data on it.

I would rather prefer not to go into the steps required to create a master slave environment, as an excellent one already exists on HowtoForge: How To Set Up Database Replication In MySQL.

In my setup I have used a Master-Slave environment, but you can also use a Master-Master environment, I would not go into that, but you can always look it up on the internet.

How do I use a MySQL Master-Slave Setup with WordPress?

After you have created a master-slave setup you have multiple resources, but how do you really tell WordPress to actually read from multiple databases?

Don’t worry you do not have to scratch your head and hire programmers to do it. There is a solution in the form of HyperDB which is written by the WordPress team, and is actively used in WordPress MU and on WordPress.com(?).

Just download HyperDB and follow the instructions to setup the different databases you have created. Once that is done, HyperDB will internally take care of distributing the load across multiple MySQL servers.

HyperDB is not like a regular plugin so you will need to follow the installation instructions and also make changes to the DB settings to specify the different MySQL servers you have. Once you have made the changes, your WordPress install will load faster than when it did with a single MySQL database.

That’s it, with two simple steps you now have multiple databases serving your website. This will definitely ease out the load on your servers and will also allow you to easily scale by adding more slaves to your setup.

In my scenario the cost of scaling added only around $20 per box a month, since I threw in servers with minimal configuration as they were only DB servers and did not take up much resources to read data. If I need to scale more I could throw in few more boxes and handle more traffic easily.

Just an afterthought, it does make a difference if your slave servers are on the same network as the master or if they are on an outside network, as far as possible try and add boxes on an internal network itself.

Did you find this guide interesting? Do you think this will help you scale your system? Do let me know through your comments. Oh and also do tell me if you have used any other method to scale your system or would prefer to do it differently.

Weblog Tools Collection uses a lot of plugins and is very query heavy but the in spite of that, the front page uses 59 queries to generate itself. I think the default (on a vanilla WordPress install on the default theme) is 27 or something of that nature. The larger the number of queries, the slower the page is going to load and the more load you are going to put on your MySql server. All of the above is true if you do not use inline or regenerative caching mechanisms. The caveat on this blog is that its plugins and its MySql server are highly optimized (via inline caching mechanisms) to reduce load.

Larger number of queries on a WordPress blog are probably caused by plugins that have been installed. Plugin authors can have non-optimized and useless queries that either take a long time to execute or need a large(r) number of queries to acheive a simple(r) result. I suspect that one could follow the 80-20 rule with 80% of the queries on your blog being generated by 20% of the plugins. If you can identify the top hitters and either optimize or replace them, you will have a happier blog and a happier MySql server.

It is also important to remember that the number of queries might not be the only straw that is breaking the camel’s back. SQL queries can be poorly constructed and can put a tremendous drain on resources. I remember a certain recent comments plugin that made queries which scanned entire tables before producing a result. If you are concerned about the speed of you blog or the number of queries, start disabling plugins. You might be pleasantly surprised to find that a few plugins might be causing most of your headaches. Once you identify the suspect plugins, you can then either find replacements that are more oprtimized or find other ways of obtaining the same result.

How many queries does your font page generate? If you find efficiencies by disabling plugins, please tell us about the results.

While we are on the subject of optimizations, the newly released WordPress 2.1 Ella has introduced many code and query optimizations that should make WordPress much faster than it already was. For example, one of the changes introduced to handle future posts gives the database the ability to cache more queries at the MySql level and should reduce load on the database server (however minuscule).