Ramblings of a web guy

Well, I have written a good bit about MySQL Cluster this year.  We had been using it as a sort of pregenerated cache for our forward facing web servers.  However, we have decided on a different route.

Why the change

With normal MySQL, configuration can make big performance differences.  With cluster, it can make the cluster shut down. We woke up one morning to errors about REDO logs being overloaded.  It had been overloaded for about 8 hours.  We had made some changes the day before, but they all worked fine on our test cluster.  So, we shut down the processes that were new and even shut off all other processes that were loading data into the servers.  4 hours later, the simplest insert would still complain about the REDO logs.  The only thing that cleared it up was a full rolling restart of the storage nodes.  That took 5 hours.  Luckily, we were still operating with a single server as a backup that had the same data stored in InnoDB tables.  We switched to it before we started the rolling restart. So, after all that was done, we really became worried about the ups and downs of cluster.  We started thinking that maybe cluster was not ready for us and the use we had in mind.

Enter Replication

We had tried replication years ago with not a lot of success.  We found we had to baby sit it weekly as queries would fail on the slave that did not fail on the master or indexes would get corrupted on the slave.  Just annoying things that would take up time.  But, that was MySQL 4.0 and we were trying to replicate our main database.  Faced with massive down time with cluster, an annoyance every few weeks seems like an acceptable risk.

The new setup

So, with the new  structure, we have two masters and two slaves.  We had already written code that would synchronously write data to two (or more) MySQL servers using transactions to ensure the data was written to all the hosts.  Its what was used to write the data to the cluster and InnoDB servers already.  So, now, it  just writes data to the two masters using InnoDB and then the two slaves read from them.  So far, there have been no outages whatsoever.

Scaling: Cluster vs. Replication

One of the big things we liked about MySQL Cluster was that it scaled very well.  As connecitons increased, query speed and response time did not degrade at the same rate as connections.  InnoDB on the other hand linearly degrades.  Basically, an InnoDB server with 128 concurent connections returns data twice as slow as it does with 64 connections.  Cluster on the other hand would only see about a 10% reduction in performance.  But, with InnoDB and replication, we can more quickly add new nodes and scale out in an emergency.  Once the hardware is in place, we could have new nodes online in about 30 minutes.  If we hit a wall with cluster, it would take us a day or two to bring the server online after the hardware was in place.  Adding storage nodes would mean a full dump and reload of the database.  So, the solution we have now will not scale as well as cluster with the same equipment, but it will be easier to scale out once we need to.

I am not a big fan of templating solutions for PHP.  The primary reason is because of Smarty.  Its not fast compared to straight PHP and, IMO, its not that much better than PHP syntax wise.  Its good for places where you need to force people to adhere to the MVC philosophy.

A coworker of mine found out about a project called Blitz.  its a PHP extension that does templating.  It will of course have one advantage over Smarty.  Smarty is slow as its all written in PHP.  PHP is slower than C and always will be.  Its just life.

So, Rob did some simple tests to see how Blitz, Smarty and plain old PHP perform.  I thought some folks (hey Jay) might be interested in this.

Yes! Its here! Phorum 5.2 has reached alpha status. Its been over a year since we branched the 5.1 code and started on 5.2. A lot has changed and Phorum is better for it. Much of the success of Phorum 5.2 goes to Maurice Makaay. He has done a lot of work to make the core code cleaner and easier for module developers. He has also been instrumental in the documentation project. As for new features and changes, below are a few. We are still updating a wiki page with all the changes and features at http://www.phorum.org/development/wiki/Phorum52News.

For your users:

• Brand new template. Emerald is a more modern, full featured template. It uses many interface design recommendation used by usability professionals.
• Rewritten search engine for faster search with more options.
• New hybrid read page that is threaded and shows all messages
• Better error messages when posting to help your users know what is wrong.
• All new code for forum feeds. Both RSS 2.0 and Atom are supported.
• New announcement module that gets announcements out of the message list and into a more prominent position.

For the admins:

• New APIs for making modules that work with the core. (Along with full docs)
• Template core changes so that similar vars in different templates have the same name.
• More modules included with Phorum and officially supported.
• Module run time ordering. You can not control in what order you modules run.
• Sanity checks updated to help admins know if their Phorum is running properly.

There is a lot more that I don’t want to list here. Please have a look at http://www.phorum.org/development/wiki/Phorum52News for the full list. We will be updating that list as we go along as well.

What is alpha status you ask? Well, while in alpha status, Phorum 5.2 may still get new minor features and code may be reworked extensively. Basically, it means that the major features we wanted for 5.2 are done. They need testing and that is where you come in. If you have the facility to test the code with your data, please do and report bugs.