CMG Atlanta: Southbound for the Deep South

I will be at the CMG Greater Atlanta Spring conference on April 27, 2011. I was asked to cover something for both veterans and newcomers to capacity planning—along the lines of my Guerrilla Boot Camp classes. So, here's what I came up with.

Guerrilla CaP for Noobs and Nerds
Whether you're a newbie (noob) or a veteran (nerd) when it comes to capacity planning (CaP) and performance analysis, it never hurts to revisit the fundamentals. However, some CaP concepts that are touted as fundamental are actually myths. Here are some myths I hear all too often.

What's NOT:

1. We don't need no stinkin' CaP, just more cheap servers.
2. CPU utilization should never exceed 70% busy.
3. A well-consolidated server should have no idle cycles.
4. Throughput and latency are independent metrics that must be measured separately.
5. Optimal response time is achieved at the knee of the curve.
6. If you can measure it, you can manage it.

During my twin session I will take these myths apart to expose the facts in terms of

What's HOT^†:

1. If the app is single-threaded, a boat-load of cheap servers from China won't help.
2. A 64-way server running 70% busy is 25% underutilized.
3. A consolidated server may need to be under 10% busy to meet app SLAs.
4. Throughput and latency are inversely related ... always!
5. Response time knees are an optical illusion.
6. All performance measurements are wrong by definition.

Along the way, I'll offer some Guerrilla mantras, as seen in my Guerrilla book and generated automatically on Twitter. You can use them as weapons of mass instruction to bust any other myths held by your colleagues and managers, whether you're a noob or nerd.

---

† With apologies to Paris Hilton.

---

PDQ Models: Show Me the Code

The road to hell is paved with good intentions
During a recent exchange with a potential PDQ user, that occurred as a sequence of blog comments related to my earlier post about getting started wtih PDQ, I thought we were very close to converging on the appropriate queueing model for his problem, and that it would make a nice addition to the models discussed in my Perl::PDQ book. In fact, I thought the model looked like this

which involves a feedback flow of requests to the Authent-ification server.

Hotsos 2011: Brooks, Cooks, Delay and This Just In ...

Thanks to all those who attended my presentation and offered me their compliments afterwards. It was a bit rushed and went a bit wobbly when it came to the description of the repairman queueing model (the Apple Genius Bar), but I knew that might happen going in. Despite my best efforts to muddle it at times, it seems people were able to take away a coherent (pun!) message. That was also evident from the excellent audience questions, as well as some of the tweets I've seen. Thank you.

Hotsos 2011: Mine the GAPP

It's that time of year again so, here I am in Dallas to present "Brooks, Cooks, and Response Time Scalability," where I will be showing how my universal scalability law (USL) can be applied to quantifying response-time scaling; as opposed to the more typical throughput scaling.