What I want to talk about isn’t as complicated as it sounds. Basically, in collecting daily site specific metrics for the purposes of SEO, you sometimes get some bad data from your third-party sources.

These bad data points can skew your graphs and make it almost impossible to visually derive any useful information from them.

For example:

The graph above (click to expand) shows the number of pages for a 6 month date range. In early January the data spikes dramatically upwards. This is clearly an anomaly, as the day after, the data is back in its normal range. The trouble here is that this anomalous point skews the entire graph, making it impossible to derive any real insights from it. The above graph is rendered useless by that one piece of anomalous data.

Here is the same graph WITHOUT that one bad piece of data (click to expand)

It’s amazing how one bad data point can skew your entire graph, isn’t it? Now we have an image that is useful!

Here’s some (hackish & sketchy) code to identify these statistical anomalies and replace them:

So, today I learned that Amazon S3 limits the amount of buckets you are allowed to have at any one time. This was a HUGE pain in the ass for me, as I just rewrote my S3 caching libraries to separate my caching into daily buckets.

The idea I had was that I would keep 30 days worth of buckets before automatically shuffling all those buckets into long term archival at the end of each month.

You see, Amazon S3 doesn’t allow for folders within buckets (not technically, I’ll get to that later), and I think it’s bloody ridiculous for me to store the ~15 millions xml cache files I need daily access to in just one massive bucket. So, I thought my plan to create daily buckets was pretty damn good. Apparently Amazon disagrees, as hey have set a limit on the number of buckets I can have associated with my account (FYI, I have ~90 buckets right now and that’s where the limit is).

So, I’ve been looking into my options, and I have decided that I’m going to have to go back to my original set up of storing all 15 million (and growing) xml files in one bucket. As some of you may know, S3 GUIs like S3Fox are able to show sub-folders within buckets, so I figure I will go this route. My first step was to take a crack at the Ruby S3 library from Amazon (not the AWS gem, which is crap for multi threaded environments) to see how I can create folders within buckets. Turns out, you can’t. At least, not out of the box. You see, AmazonS3 doesn’t actually SUPPORT sub-folders within buckets.

Stupid, right? I know.

So, how does S3Fox do it? It turns out they create virtualized folders by creating a special object that acts as a folder, then you access your stored objects by appending that folder object name to the actual file key. For a directory named “/foo”, you would create an object with the key “foo_$folder$”. Then, to get a directory listing of all files stored under the foo path, you just query S3 for objects with keys that start with “/foo”, and you ignore any objects that end with “_$folder$”.

I’m about to waste my day setting this up, and I’m none to happy about it. It seems like a hackish and shitty work around for an obvious service flaw. I’m sure there is some technically-reasonable answer for why Amazon has set an arbitrary limit for buckets and also why they don’t allow you to create folders, but I don’t know what it is. Anyone have any answers?

Hat-Tip the Dead Programmer Society for the code to create virtualized folders in S3.

There are many of different reasons why this error can occur, and in my case, it was a reason that no one else has written about (that I could find), so I figured I’d post up the cause of my problem (and the solution).

This application was on a shared development server with a few other applications. They all used the same mySQL server. One of my other applications had a corruption in a few of its tables, and whenever this application was called, it would crash the mySQL server, triggering a “Mysql::Error: Lost connection” for all my other applications connected to the mySQL server at that same time.

I tracked down this issue by check the mysql logs, and then I simply reloaded last nights backup of the corrupt database, and everything was fine! It just goes to show you how important it is to always perform regular backups of your databases.

I hope this helps someone!