(Originally posted 2012-11-20.)
Once in a while there comes along a simple coding enhancement that really kicks the story forwards. This post is about just such a simple thing, as I think customer Performance people would benefit from it.
Consider the following perfectly ordinary graph heading (and ignore the grottiness of the font if you can). 🙂
 |
I’d like to draw your attention to the portion if it in the brown box. That’s the new bit.
The whole heading is automatically generated by my REXX code – and you’ll recognise some of my parameterisation. But let me zoom out somewhat and start the story proper…
Originally the tooling I now maintain "only" 🙂 processed RMF-originated SMF (record types 70 through to 79). In particular the finest detail in CPU and memory terms was down to the WLM service class level.
But then I took the plunge and extended the charting down to the "Top 15" address spaces in the service class. (Any more than 15 and the graphs get very confusing.) The way my code works is a sequence of two queries, the first finding the Top CPU / Memory address spaces averaged over the entire shift and the second using that list of names to generate an hour-by-hour graph. CPU and memory are done separately.
As you can see from this example 15 doesn’t completely describe the service class (SYSSTC in this case), there being 50 address spaces in all.
The questions I had to "hand wave" and verbalise before were twofold:
- How many address spaces are there in this service class?
- What proportion of the CPU or memory does this represent?
On a bad day I won’t even remember to ask myself those questions. 🙂
In recent client engagements I’ve taken to hand annotating the graphs with some special HTML5 Canvas tooling I’ve developed. I’d rather not be doing that – and I guess you’d rather not have to annotate your graphs and reports by hand either.
So I was pleased it was remarkably simple to change my code to generate this piece of the title. In fact the calculations had already been done and sent to SYSOUT when I wrote the original Type 30 code.
I think it is an interesting fact that the memory for SYSSTC – as this heading shows – is overwhelmingly dominated by 15 address spaces out of 50. (And in fact it turns out the real big hitters are much fewer in number.)
I’ve deliberately avoided choosing an "Application" service class as that’s much closer to who the client is and what they’re doing. I tend to avoid exposing that. Suffice it to say they have many more IMS MPRs than 15 and so it’s interesting what proportion of the total the top ones are.
On and off over the years I’ve considered showing how the 80/20 rule plays out for address spaces in a service class: I could graph "contour lines" for groups of, say, 5 address spaces – sorted by overall CPU time. It’s a similar but different thing to trying to figure out which address spaces in a service class are clones of each other.
But the real point of this post is to urge people to automate those little things on graphs you frequently have to explain. Maybe the title’s not the right place – but for me it’s codewise the easiest thing to annotate. Maybe a graph note is – and GDDM (my graphing engine) allows for that if you drive it deeply enough. (But chart notes have their own problem: placement.)
Mainframe, Performance, Topics 