Java Workload Characterization – Part 2. My 3, 5, 7, 10 Rule
I hope you had a chance to look at do you know where your java transactions are, my Java Workload Characterization – Part 1 blog. And I love to hear what else you can add or suggest to our audience.
Here in this part two, I like to cover some additional dimensions to my monitoring. Occasionally you end up working for one very large composite application. This in reality can be broken down into smaller sub components that are each an application by itself. So you are monitoring multiple separate applications, or sometimes you should. And there are times when you have a larger list of applications that one is responsible for. There was a time that I worked for a very large Bank and was responsible for 27 applications. Naturally I spent more time focusing on the most important composite application. But we still had to keep an eye on the rest and occasionally focus and work on others, as they needed attention. So we had to come up with creative ways of spreading my time on some of the more important applications. And my manager at the time, helped me with that. And I had couple of mentors in our team who would help, when I needed additional set of eyes, and ideas.
So I ended up coming up with this 3, 5, 7, 10 Rule. Initially they look as some random numbers. In reality it might have had something to do with 3 being Olympic Medal types, 5 being number of fingers on each hand or number of working days in a week, 7 being total number of days in a week, and 10 had a lot to do with late night comedy shows.
I had ended building dashboards and treating my applications as a group, monitoring Requests and Transactions by volume for each application, average response for each application, transaction rate per second for each application. We started focusing on 3 applications first, then extended this to 5, then 7 and ended up with the Top 10. Then for each application, we looked at top 3 Requests/Transactions with highest volume, and then moved to top 5, 7 and 10. Not only we had to monitor these on regular basis, I had to generate management reports on these. We knew, if we couldn’t measure it and document it, we couldn’t improve it.
There is nothing magic about 3, 5, 7, and 10. It just helped us build a process and a discipline that we could follow to improve response time and Quality of Service we delivered to our customers.
The biggest observation for us was the granularity of data that we were collecting changed. When focusing on application and spending a lot of time on it day in and day out, we would collect more granular details. When focusing on large number of applications, we would simplify and focus on the basics. The basics are Transaction Volume, Average Response Time and Transaction Rate per second.
On my next blog I would share what we come up with in terms of granularity of the information we were collecting. And how we were changing it.
Please provide your feedback as I like to hear your perspectives. I always learn from my customers and peers. More to follow soon. . .
