My Updated CMG 2007 Schedule

Here is an updated list of my sessions.

1. Sunday Workshop
   
   "How to Move Beyond Monitoring, Pretty Damn Quick!"
   
   Session 191
   Sunday 1:00 PM - 4:30 PM
   Room: Elizabeth D/E
   
   
   
2. CMG-T
   
   "Capacity Planning Boot Camp"
   
   Three Sessions 431
   Wednesday 1:15 PM - 2:15 PM
   Wednesday 2:45 PM - 3:45 PM
   Wednesday 4:00 PM - 5:00 PM
   Room: Elizabeth D/E
   
   Introductory CaP class for newbies.
   
   
3. Apdex Alliance Meeting
   
   "Triangulating the Apdex Index with Barry-3"
   
   Sessions 45A
   Wednesday 4:00 PM - 5:00 PM
   
   This talk is part of the Apdex mini-conference at CMG and will be presented by Mario Jauvin, since it overlaps with my CMG-T classes.
   
   
4. Hot Topics Paper 7050
   
   "Seeing It All at Once with Barry"
   
   Session 511 (Advanced)
   Hot Topics
   Monday 4 pm - 5 pm
   Room: Elizabeth D/E
   
   Dr. Neil J. Gunther, Performance Dynamics
   Mario Jauvin, MFJ Associates
   

Complete abstracts were blogged previously.

Apdex Meets Apex

The Apdex Alliance has defined a performance metric, called the Apdex index, which rates the measured response times of distributed applications from an Internet user perspective. The Apdex index is constructed from three categories which are defined by partitioning the total number of sample counts (C) according to an agreed upon threshold time (τ):

1. Satisfied (0 < S < τ)
2. Tolerating (τ < T < 4τ)
3. Frustrated (F > 4τ)
   

Perl::PDQ Corrigenda Updated

It's been a while, but reader Peter Altevogt (Germany) spotted some numerical inconsistencies in Table D.2 on p. 403 of my Perl:PDQ book. This turns out to be the result of an Excel gotcha when copying cells and pasting them to a different spreadsheet location; the cell reference gets silently incremented. Sigh! The correct values are now available on the corrigenda page. Thank you, Peter!

Folsom: Not Just a Prison But A Cache

A nice update to my previous posts about the Intel Penryn microprocessor:

1. Moore at 45 nm
   
2. More on Penryn
   
3. More on Moore
   

appears on a Dutch blog (in English---damn good English, BTW). The blogger was apparently invited to Intel's geographical home for the development of Penryn; not HQ in Santa Clara, California but Folsom (pronounced: 'full sum'), California. Consistent with Intel's January 2007 announcement, he notes that November looks to be show time for their 45 nm technology.

Since the author was a visitor, he failed to appreciate certain local ironies in his report. He missed was the fact that Penryn is a small town due north of Folsom, just off Interstate 80 on the way to Lake Tahoe. He refers to the huge Intel campus at the edge of the town. At the other end of town is an even better known campus; one of the state's major prisons immortalized in this Johnny Cash (not Cache) song. So, not only are criminals cached there but so also are some of Intel's best microprocessor designers (not as an intended punishment for the latter, presumably). OK, I'll stop there because I'm having way too much fun with this. Read the blog.

Erlang's Collected Papers

In 1948, the collected papers of Agner Erlang (AKA the father of queueing theory) were translated from the original Danish and published in the Transactions of the Danish Academy of Technical Sciences. They were reissued as a book by Acta Polytechnica Scandinavica in 1960, but due its underwhelming popularity, that book is now out of print. However, I just discovered that the chapters of the book are now available on the web. Kudos to the Academy!

Streeeeeeetch!

The October 2007 Linux Magazine (no. 10, issue 83, p. 62) is carrying the English version of my original German article about converting load averages to stretch factors. Unfortunately, there is no direct URL (Sun Oct 28, 2007: As Metapost commented below, it is now available for viewing) but the cute visual hook has a picture of a stretch limo ... stretched across two pages.

I wish I'd thought of that.

SOA Scalability and Steady-State

Guerrilla alumnus Peter Lauterbach just brought to my attention an article in SOA World entitled "Load Testing Web Services". I have to commend these authors for performing their SOA load tests in steady state. Elsewhere, I've discussed how wrong things can go when you don't adhere to this procedure. In their online article, these authors show the response time (R) as a time-series plot, more or less as it would appear in a measurement tool like say, LoadRunner. Although they don't show it, the throughput measurements would also look similar when plotted as a function of time (t).