Continuing with our MongoDB monitoring series, today we are releasing Cacti Performance Graphing templates and unit tested data sources for MongoDB. These are built on top of Baron Schwartz's excellent Cacti Graph framework found here (http://code.google.com/p/mysql-cacti-templates). This framework allows you to define graphs via a simple (relatively) perl file and to create testable data sources for your graphs. I highly recommend it.

There has been a lot of talk about No-SQL databases recently, especially in the Drupal community. One of the most popular being MongoDB, due to its easy interface, feature-full design and speed. Use of MongoDB and No-SQL in general is only going to increase in the coming months.

At Tag1, we have been working on a few projects with MongoDB as a central infrastructure component. Due to this, we have come upon one of Mongo's problems, youth and because of youth a lack of good tools around it. Monitoring in particular is a complete vacuum. Over the next few weeks we will be releasing the first round of tools we have developed to monitor and test MongoDB, the first being a Nagios Plugin called check_mongo.

I began porting the dba module to Drupal 7 as an opportunity to learn more about the new database abstraction layer. In this upcoming Drupal release, our database layer is now built upon the PHP Data Objects (PDO) data-access abstraction layer, introducing new syntax and symantecs into writing queries with Drupal. A powerful new query builder makes it possible to easily write queries that run on any database type supported by Drupal, currently including MySQL, PostgreSQL and SQLite.

The dba module was always intended to be a useful tool for any database administrator, and toward that end I have recently merged in mysqlreport functionality which utilizes MySQL's server statistics to offer an overview of server health and performance. As an enhancement, I also merged in the knowledge shared in this earlier Tag1 Consulting article, so now problem areas detected in the mysqlreport output are automatically highlighted along with some useful help text offering tips on better tuning your database.

At the beginning of 2009, I was hired by Tag1 Consulting as Jeremy Andrews' full time partner. A decidedly questionable decision on his part, but a great change for me! I used to work at the Open Source Lab at Oregon State University and I am currently the sysadmin for drupal.org. Working at the OSL and drupal.org spoiled me, I'll be completely honest about that. I got used to working with interesting new technologies and consistently pushing the limits of my knowledge.

We at Tag1 have used the Cacti Memcache templates many times. (http://dealnews.com/developers/cacti/memcached.html) They have become a staple for us and many others. However, we and one of our clients have had issues making them work for monitoring multiple Memcache instances (running on different ports) on the same host. It is possible to make this work with the vanilla templates, but it is a bit difficult.

There are some standard tools in every MySQL DBA's back pocket, these include maatkit, mysqlreport and mysqlsla. I have a new addition to this: statpack (http://www.markleith.co.uk/?p=21)

There are few options for sharing webroots among multiple webnodes. This is especially true for Drupal, which has a files directory that could be constantly diverging on each webnode. Usually people decide to go with NFSv3. This is what we do on drupal.org and most of my clients do at Tag1. Sadly, this is not really a decision on merit, but on a lack of other options. NFSv3 is pretty much like communicating with two cans and a string.

I've had the opportunity in the last few days to use quite a few cool little utilities that made my life considerably easier. I've known about most of them for awhile, but discovered some new tools or new uses for old tools and wanted to share two of them.

I recently joined Tag1 Consulting full time. My main project since I joined was building up our monitoring infrastructure. My personal goal being world domination, but first the best monitoring system I can build. Baby steps...baby steps. For quite awhile now, I've used the monitoring system we built at the Open Source Lab to detect and diagnose problems with drupal.org, apache.org, kerneltrap.org and many more Free Software projects hosted at the lab. These experiences convinced me of the absolute necessity of a robust monitoring system.

The following collection of patches are useful performance and scalability tweaks that can be applied to Drupal websites. This collection will continue to grow, and is being maintained as a reference page for our online performance and scalability book. As new versions of Drupal are released, updated version of these patches will be added to this page.

To learn more about how these patches work, where they came from, and if they've been merged upstream, you can click the readme link following each patch's brief description. We welcome all feedback, and suggestions for other patches that should be included in this collection.