Lets all give it up for Comcast, come on now:

Go Comcast Go!
Ra Ra Ree!
Kick Em In The Knee!
Ra Ra Rass
Kick Em In...The Other Knee!

A couple weeks ago I got several disturbing reports from the midwest, mainly of the "drupal.org has been down for 6 hours" variety. My response to which was frantically going to drupal.org, watching it load perfectly and then enjoying a large steaming cup of wtf.

I admit that I'm feeling somewhat relieved today. I've had a large migration on my todo list for quite awhile now. Last Sunday I finally sat down for the 16 hours it required and got it done (with the help of several local coffee shops). First, a little back story.

Today, I got sent a draft of the slides I and several others will be working off of at DrupalCon in Boston on Tuesday. This session will cover Performance Tuning for Drupal deployments. It will cover pretty much every aspect, from Linux tuning to opcode caches to MySQL tuning. I am particularly looking forward to David Strauss's section on database design and Scott Mattoon's on DTrace.

It is a common practice to setup a web-server instance, either a cut down apache or something like lighthttpd, to serve the static files on your site and then have a dedicated apache with mod_php and such to do the actual dynamic page creation. This lets the dynamic apache focus on what it does and offload the static files to a server that takes up less resident memory. Its a good idea and keeps requests moving through the dynamic instance quickly. However, we don't do this on drupal.org. Why you ask? Squid does it for us.

Getting the subscriber counts for RSS feeds hosted on drupal.org is a bit tricky. There are basically two classes of subscribers, those fetching with a local client and those fetching through a web-based service. The first is easy enough, you just look for unique IPs. However, for the second you also need to look for the user agent string which reports the number of subscribers to the feed. To do this, I wrote the following script:

As a reference, here is an example squid log entry:

I was asked recently to figure out the total DB sizes across the OSL's database cluster. Like the good peon I am, I saluted and went to work. There are issues with getting this information, just using du would be wildly inaccurate as it would take into account a large portion of information that is not really the DB size for the MyISAM tables and for the InnoDB tables it would just measure the size of the Innodb Tablespace...which in no way has anything to do with the database size. The easiest of these problems to solve is getting the MyISAM db sizes.

Do you know where your children are?

I was requested to write a short (for me) description of my experiences and thoughts on how to split queries between a master/slave server setup, specifically for Drupal. I don't claim to be any sort of expert on this, but I do have some recent experience. I came up with a couple of ways to look at things:

A. Round-Robin

So, I have given in and sort of have a blog now. Except, its not really going to be a blog...I promise...really