May 5, 2020
Critical Path Analysis
Why should I read this?
I know it is hard to imagine your system running slowly. In fact, I will even go out on a limb and say there has never ever been a slow network or processor. One exception is for different classes of hardware; another is for one case I know in which the firmware altered the CPU clocking.
I know you are calling BS here but I stand by it.
Networks transmit bytes at the rate they are designed for without fail.
Processors execute instructions for a quantum without fail.
Your view of slowness is not due to the network or the processor, it is always due to hurdles and obstacles that your software must overcome in order to actually work.
Think of it like cruising down the highway going 65 MPH through Hazard County. Roscoe flips up a stop sign. You stop because you are a law abiding citizen. This little obstacle just altered your timing and caused you to take longer to get to the Boar’s Nest. Imagine numerous and unforeseen obstacles like this. For software and systems, this is what happens. The job of the programmer, implementer, and support engineer is to minimize the number of obstacles and shorten their effect thus ensuring your software or system runs to maximum potential. How?
Well, a Forensic engineer focuses on critical path analysis.
Time for a Definition
Before jumping head first into critical path analysis, we should probably define what it is.
The online Oxford dictionary doesn’t exactly hit the mark; a real world definition in project management, software analysis, or even driving to work is “the longest time that it takes to complete a specific activity”.
If you take any activity and break it down into compartmentalized steps that are measurable, then you can start to reduce times in a methodical approach.
In the example below, times T1, T2, and T3 are measurable items in an activity. If the lengths of the chevrons represent time, then which one would you want to reduce to improve the overall time? T2, correct.
The key is that T1, T2, and T3 are measurable in some meaningful metric like time, cpu usage, memory utilization or similar.
Lets say I am driving to work and my route takes me on three main roads. If the time I spend in traffic on the roads is T1, T2, and T3, then focusing on improving T2, then T3 are critical for reducing my time to get to work. The same is applied to computer software and algorithm analysis.
When you click on a new browsers tab, load your email, or click on an application button do you want it to be fast or slow? Dumb question, fast…as fast as possible.
Let’s Move Forward!
At Forensic IT, we pride ourselves in critical path analysis of basically everything. Well, everything related to computers and software. My goal over the next few blog posts is to help you fine tune your critical path analysis skills. We will tackle some simple examples and complex ones as well using real data and repeatable steps you can take and follow along.
With the critical path analysis skills you will develop, you can apply them to your own issues and finally get some of those slow issues resolved. Let’s face it, if you have worked anywhere around IT then you have heard something like “the network is slow” or “my system is slow”.
Statements like those always crack me up.
My good friend and colleague, Erick Harlow, loves when people say “the network is slow”. He is also a farmer and usually has a comment back that involves hogs or hay. I won’t do him justice here trying to duplicate it, but I will try. He would say something like
"Well slap my face to the side of a hog and paste my ears with jam, do electrons really flow slower for you than they do for me?".
Ha! No, electrons are consistent.
Stay with us over the next few blog posts and we will really dig in and do some Forensic troubleshooting.
Sign up to be notified of new posts!