Radiology and Diagnosing CF Server Issues

I recently talked with Mike Brunt, CF Server tuning guru for TeraTech about how he approaches server issues. Heads up we are planning a webinar on server tuning on Thursday 1/31/08 1pm EST – more details coming soon.

For three years, from 1996 to 1999, I worked in the medical software world, in what is known as TeleRadiology, to be precise. This involved creating secured Wide Area Networks which spanned hospital groups and typically involved a central reading center where a group of Radiologists would read images which had been transmitted from each individual hospital. Radiologists would then send results back to the hospital which had sent the images to be read. As a point of interest, there are actually two main types of Radiology Images. The first are currently analog and are printed to physical film (x-rays are typical of that sort of Radiology Image) which then have to be scanned or digitized to high resolution images; a typical chest x-ray is around 12-14MB per image. The second overall kind of Radiology Image is already digital, MRI, CT, PET, Nuclear etc. I digressed a little there but thought that worthy of a little more explanation.

The Radiologists performed two main kinds of reads. The first was from the Emergency Room, where a quick response was imperative and where the Radiologist would be looking in the area of a known trauma or affliction, to deliver a targeted response to the ER Doctors. Very often, those were literally life and death situations. Afterwards, typically the following day, the Radiologist would go back to the image(s) and look for any other issues the patient might have. The other main place that Radiology holds in medicine is that of a major preventative discipline, often discovering ailments before they get too serious.

These principles could apply directly to server diagnostics; sadly, almost all server diagnostic issues stop in the “ER”. When I worked for Allaire and then Macromedia, we had a team of 37 engineers who were often called in when an application was in ER, regularly failing or running very slowly. It was interesting to note that the reaction of most client companies, when faced with a poorly performing application, was to “throw” more hardware at the situation. This literally never worked because typically the “disease” was in the application code or in the overall support mechanisms-network, etc. Adding hardware in this situation is a bit like trying to give someone a second heart whilst the first diseased heart is still there; it won't work and the result will likely be terminal!

So in our training with Allaire, we were taught to go in and prevent “death” as quickly as we could, and we did, and then to perform that second read, just like the Radiologist, so that we could give clients a clear path to server health. In addition, we would always hope to leave the client with the ability to self-diagnose issues so as to prevent applications from being “life-threatening” in the future. Server diagnostics are an essential tool in ensuring ongoing application health if, as happens with applications such as MySpace, mercurial growth occurs or if there is simply a need to support structured growth. Applied correctly, server diagnostics will always create stability with scalability.