Performance tuning specialist Kirk Pepperdine has shared one of his own approaches for starting to find the true cause of performance problems: "the box" - a little diagram that is an abstraction of a complete system. The box is a reminder of the true causes of performance bottlenecks.
Read The Box: A Shortcut to finding Performance Bottlenecks.
The has 4 layers: People, Application, Java Virtual Machine, and Hardware. Each of these layers has a role in systems performance, and Kirk talks about when The purpose of the box is to eliminate guessing by showing us how to sequence an investigation.
Kirk advocates a bottom to top investigative process, the goal of which is to eliminate as many potential sources for the bottlenecks as can possibly eliminated before we start looking at the code.
Community comments
So what's new?
by James Richardson,
Re: So what's new?
by Dmytro Dyachuk,
Re: So what's new?
by Kirk Pepperdine,
Re: So what's new?
by soorej mg,
The box is ok, but really you shouldn't be in this position
by Morten Udnæs,
Re: The box is ok, but really you shouldn't be in this position
by Kirk Pepperdine,
So what's new?
by James Richardson,
Your message is awaiting moderation. Thank you for participating in the discussion.
This chat doesn't really deserve its own nomenclature does it? "The Box" == "The box of obvious stuff".
- Look at system load
- Use some system tools
- Java has gc.
- creating zillions of threads can be harmful.
Re: So what's new?
by Dmytro Dyachuk,
Your message is awaiting moderation. Thank you for participating in the discussion.
The author did not mention that using synchronized methods locks the whole instance of the class and very often causes significant performance degradation.
WBR, Dmytro
The box is ok, but really you shouldn't be in this position
by Morten Udnæs,
Your message is awaiting moderation. Thank you for participating in the discussion.
Handling performance requirements is vital part of any software development effort. If you end up needing the "box" someone hasn't done their job properly.
In terms of fixing bad performance, I don't agree that you should go from bottom and upwards. It doesn't help to tune the hardware, VM and database of an application thats badly designed/constructed. Usually you have to work both ways (both at application level and infrastructure level) at the same time, and choose what gives most effect and lowest risk.
Final advice: Get real volumes of data and measure!
Re: The box is ok, but really you shouldn't be in this position
by Kirk Pepperdine,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think this comment is a bit unfair. It is like saying that bugs are because someone hasn't done their job properly. There are many reasons why performance problems creep into for many reasons. For example, concurrency issues often can't be found until you start integration testing. At that point you maybe into a full diagnostic effort on the application. This is a normal course of development in an imperfect world
The article isn't about tuning, it is about a process of diagnostics, understanding that you really do have a problem with the DB as well as determining if the problem is caused by your application or by the DB its self.
The process is about ensuring consistency of results in your tuning efforts so that you're not wasting time fixing phantom problems. This, IME is the lowest risk way to proceed.
Kind regards,
Kirk
Re: So what's new?
by Kirk Pepperdine,
Your message is awaiting moderation. Thank you for participating in the discussion.
At one time I might have agreed with this. However I have found that people have found this visualization of the *obviously* useful. It is a rough abstraction, it is flawed but even so....
Kind regards,
Kirk
Re: So what's new?
by soorej mg,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Kirk,
This article is really useful!!..