(This is Part 1. Part 2 is here.)
I don’t blog much, and when I do, they are pretty short and too the point. This post is different: feel free to put into the “ramble” category. I’m really just posting it here for myself as a thought exercise.
Some years ago, while drawing a network map for the site I was working at the time, something struck me about how our tiered architecture looked. My background before getting into this computer business was in mechanical engineering, so it’s not surprising that when looking at these webservers, databases, caching servers, storage, I imagined: mechanical devices.
Bear with me for a bit. When I did crashworthiness research for the gov’t, we ran mathematical models of car crashes on big honkin’ parallel computers. These simulations ran with the math and concepts that governs structural dynamics. Like, Newton stuff. In the simpler ‘rigid-body’ simulations, you have things like bumpers, frames, doors, engine blocks, and tires that are reduced to hunks of mass connected with springs and dampers, and when connected all together, can paint a pretty accurate picture of what happens when a vehicle slams into a rigid wall. In the more complex models, 3-dimensional elements were given the material properties of steel, rubber, glass, etc. so that forces (and strains due to those forces) could be used to calculate how crunched those components get during a crash.
In either case, you’ve got components that get strained based on the load placed on them, and the relationship between load and strain can be measured and used to predict future behavior. Sound familiar?
Here’s what a stress-strain diagram for steel looks like: 
As load increases, the material is strained. Up to a point (roughly, point 3 on the diagram), it can bounce back to pre-load conditions. MechEng dorks call this elastic deformation. After that point, it stays put after it’s strained, which is called plastic deformation. At some point, the steel fails completely and breaks in two.
Now here’s what a webserver looks like when load (busy apache processes) increases:
As the rate of hits increase, the CPU usage increases. (well, duh)
So, I’m saying (sort of) webservers can be imagined as components that have limited tolerances for load, and behave (for the most part) predictably as that load increases. Just like springs, dampers, and other mechanical components that make up a dynamically loaded structure. Do webservers have plastic parts of their stress/strain curve? Nah, they work fine right up until the point that CPU hits 100%, and while there might be swapping or other badness happening for sustained load > 95%, with most multicore machines, my experience is that they can mostly recover when load comes down.
This isn’t exactly an accurate analogy. There’s all sorts of ways how mechanical force is different than webserver traffic. Even if it was the same, it can’t be applied cleanly to the example of databases, which are a bit more complex in how they behave. Not to mention that it’s a pretty broad stroke. We’re ignoring all of the small connecting stuff that can make a big difference, like rivets, tie rods, bolts, welds (or: NICs, cables, switching, bus speeds, etc.).
But: for an old gearhead like myself, visualizing all our servers in terms of forces and strains is intuitive for me. Whether it’s springs and dampers connected to masses, materials bending under load, or even the tachometer of a running engine…anything that can help with the holistic view is good, IMHO. 🙂
If you’ve read this far, then I’m impressed that you have such a high tolerance for long-winded babbling.