Go Guerrill-R on Your Data

The Guerrilla Data Analysis Techniques training course (GDAT) will be held during the week of August 8-12 this year. As usual, the focus will be on applying R to your performance and capacity planning data, as well as how to use the PDQ-R modeling tool.


(Click on the image for details)
Classes are held at our Larkspur Landing location in Pleasanton, California; a 45-minute BART ride to downtown San Francisco. For those of you coming from international locations, here is a table of currency EXCHANGE rates. We look forward to seeing all of you in August!

Quantifying Scalability FTW (The Movie)

The video of my presentation at the Surge 2010 conference on scalability and performance has finally been posted. Since it doesn't seem to be a streaming server, it may take several minutes to download the video (depending on the speed of your pipe). Also, the audio is suboptimal because it seems to have been recorded from the ambient loudspeakers rather than a direct mic. I was too busy giving the talk to remember the setup they used.

Here's the abstract:

You probably already collect performance data, but data ain't information. Successfull scalability requires transforming your data so that you can quantify the cost-benefit of any architectural decisions. In other words:

measurement + models == information
So, measurement alone is only half the story; you need a method to transform your data. In this presentation I will show you a method that I have developed and applied successfully to large-scale web sites and stack applications to quantify the benefits of proposed scaling strategies. To the degree that you don't quantify your scalability, you run the risk of ending up with WTF rather than FTW.

May 2011 Guerrilla Classes: Light Bulb Moments

It's impossible to know what will constitute a light bulb moment for someone else. In the recent Guerrilla classes (GBoot and GCaP), we seemed to be having many more than our usual quota of such moments. So much so, that I decided to keep a list.

Applying PDQ in R to Load Testing

PDQ is a library of functions that helps you to express and solve performance questions about computer systems using the abstraction of queues. The queueing paradigm is a natural choice because, whether big (a web site) or small (a laptop), all computer systems can be represented as a network or circuit of buffers and a buffer is a type of queue.

Fundamental Performance Metrics

Baron Schwartz invited me to comment on his latest blog post entitled "The four fundamental performance metrics," which I did. Coincidentally, I happened to address this same topic in my presentation at CMG Atlanta last week. As the following slides shows, I claim there are really only 3 fundamental performance metrics (actually 2, if you want to get truly fundamental about it).

PC and Netbook Sales Drop

During my Guerrilla classes, I like to make a point of reminding people that it's not enough to just focus on speeds and feeds and examining performance data. It's also important to take time out to check what's happening in the marketplace because current events there can have a huge impact on your performance analysis and capacity plans later on.

Case in point:

Acer, the number-three PC maker in the world, told investors this morning that second-quarter sales will be down 10% from last year. That's more bad news for PC suppliers like Microsoft and Intel.
...
The company has been hammered as netbook sales dried up, replaced in part by Apple's iPad.

[Source: Business Insider]

The news about Netbooks didn't come as a complete surprise to me because I had already decided they were a losing proposition in 2009. The thing to track now is the impact on Intel and Microsoft.

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.

---