A Funny Thing Happened on the Way to the Priority Queue

Suppose two workloads $W_a$ and $W_b$ access a common resource, e.g., the CPU. They each have response times $R_a$ and $R_b$, respectively. The response time $R_a$ is longer than you would like. A common way to try and improve $R_a$ is to give $W_a$ a higher priority at the CPU. That's what the Unix nice command is all about. For example, if $W_a$ were a Unix process then: nice -15 Wa, would give a higher priority than the default already assigned by the Unix scheduler. But how much better will it's response time be? Nice can't tell you that.

Towards a Cloud Capacity-Cost Formula

One of the (unscheduled) plenary sessions at Velocity 2009, was entitled: “Why elasticity, performance, and analytics will change how Webops is judged" (PDF), given by Alistair Croll. An earlier version of Alistair's ideas can be read on his blog. As I understand it, he's attempting to tie together the capacity-on-demand concept of cloud computing with the way a user is charged for resource consumption and how the provider counts revenue; a kind of dynamic capacity planning and chargeback association. Currently, for example, Amazon EC2, Google App Engine and Salesforce, all do this differently. This looks like a very important point, which I would like to understand more thoroughly. By slide 3 in his presentation, he refers to a simple capacity formula and that's what I want to discuss here, because that's what suddenly locked up my attention.

Starbucks Discovers Performance Analysis!

According to the WSJ, Starbucks "vice president of lean" (and apparently mean), has discovered performance analysis.

Heeellooooo! That would be The Principles of Scientific Management, developed by Frederick Winslow Taylor almost a century ago. Of course, it's uncool to be a prophet in your own land, so more notice was eventually taken in Japan then the USA, after WW-II. Baristas will probably be less than bullish on it, but they can take heart that this genius idea by the VP of Lean is totally pre-Toyota.

Remembering Mr. Erlang as a Unit

Not to be confused with Frank Zappa's daughter or a Coneheads spousal unit, is the Erlang unit. The number of Erlangs (E) is defined as:

E  =  λ S,

(1)

and is a well-known in the teletraffic industry, where it was first used as a measure of call capacity. For this reason, it's also called the traffic intensity.

Scalability in a Spreadsheet - Google Style

Speaking of spreadsheets, it's always nice when someone, who uses your ideas, takes the time to write to you about it. Case in point, Scott Roberts sent me the following email, telling me how he'd set up my USL model in Google Docs spreadsheets.

Ignite! San Jose 2009: The Afterburn

It's been over a month since I did the Ignite event in San Jose, but I have simply had so many things to do since then, that I'm only catching up on blogging about it now.

The title of my Ignite talk was "Scalability for Quantheads: How to Do It Between Spreadsheets" (a pitch for applying my Universal Scalability Law to Web 2.0 applications using Excel spreadsheets). Since scalability is about sustainable size, I used the theme of giants as a hook. Why are there no 30 ft (10 m) giants like the one in the "Jack and the Beanstalk" fairytale? Officially, there have been no human giants taller than 10 feet (3 m); and even they need leg supports. The reasons are given in my Chap. 4 of my Guerrilla Capacity Planning book.

A Thomas Jefferson Enigma for July 4th

This post isn't about computer performance per se, although see end, and I certainly have better things to do with my time, but when I read this slashdot item about a 200 year old cipher, I couldn't help wondering what it would look like as a modern computer algorithm.