(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.
And I bet at the fundamental level, the same set of differential equations could be used to describe that functionality! I had an E.E. prof that used to teach a class with M.E.’s in it, because he proved that mechanical & electrical systems behaved similarly enough at the diff.EQ level that conceptually the systems were identical (springs & masses versus coils of wire & voltage).
Running engines is a very good analogy. Especially, when considering the amount of engineering required when comparing a high-performance motorcycle engine to a lawn mower engine. Internal IT web applications can be built like a lawn mower engine, while large internet sites require more serious engineering effort devoted to non-functional/infrastructure requirements because the tolerances for error are very slim. High load will test the correctness of your currency and graceful degradation similarly to how high rpms will test the precision of your engine components.
Pingback: Mechanical Analogies To Web Stuff, Part 2.
I’m no engineer, but I totally agree with the analogy. Perhaps (dumbed-down for my benefit), a web server *farm* could be compared – simply – with the weight bearing axles on any 18-wheeler. I just implemented Network Load Balancing in my makeshift web server farm to accommodate my website traffic as well as the web services traffic for our Web 2.0 beta.
Whether the balancing model cascades, round-robins or drops new sessions to the least-used box, the (long-term) results are similar to adding axles on the trailer to allow additional weight.
New questions arise if this comparison is worth its weight (sorry):
What about weight shifts? (overbearing multi-threaded sessions sitting on one server?)
What if the trailer grows unmanageable? (session timeouts to keep farm load overhead down?)
How to manage flats? (seamless transfer of running sessions from one server to another?)
And if the tractor fails? (seamless fail over of NLB server to another?)
When I designed databases in a prior life, I used to LOVE to “visualize” the relational models and figure out the weakest links in a design by running the (imagined) simulation through to final reports… I can think of no better way to address computing issues than to draw direct comparisons to nature (i.e. physics, biology, anthropology).
I was looking for the possibility a mechanical model I’ve devised for some functions I’m writing had a name already. I found this, and enjoyed it 🙂 I think, computers are advancements, simply because the knee from the stress-strain diagram has been moved past the operational parameters of the system.
I must have done a little of this in school too (for QA at least), but my electrical engineering background makes me wonder if you are familiar with BH diagrams? Very similiar, and–let’s be frank here–very cool.
Not long winded at all, btw!
Pingback: Stress, Strain, and Reminders | Kitchen Soap