Wednesday, November 13, 2013

Is it the Hardware or the Application ?

     As I am currently job hunting , I am being asked a small collection of baseline questions. The kind of technical questions that separate the real from the would be real. One of my favorites is how to tell whether a bottleneck is in the application or hardware resources.
      The interviewer is looking for what specific strategies you would take to determine the source. How do you prove to a developer that a slowness or locking issue is caused by the application ? How do you show your system administrator that the server memory or drive specifications are not cutting it with the high transaction order entry and billing systems ?
     I assume the process in question is some sort of data call. You need to find the latency. I like to break it down; either something is doing more than it should or something is just taking longer than it should to do it. The client makes the request. The application talks to the database. The database responds to the application. The application notifies the client. Hopefully your set up is comparable or this is merely a simplification of it.
      My network guys are infamous for saying "It's never the network.". I usually take that at face value. Looking to disprove it only after all other possibilities have been exhausted.
      The hardware guys have one of two opinions. The more common is denial. They'll tell you the hardware is more than sufficient to handle everything that is asked of it. The second opinion is an admission of guilt. Of course the hardware is insufficient; Its old and wasn't spec'd out right.
      The database guy , that's my normal role, is the most suspicious. If he can acquit his hardware of guilt , he still has a few other possible problems. Server settings such as memory allocation, File sizes and growth settings, database maintenance and poor indexing are all things that can cause performance issues. He needs to make sure the data call is only asking for what is truly needed at the time. He may have a lot of ground to cover to find the true source of the issue.
      The developer will also normally deny any responsibility. The internal developer is trying to protect the perceived quality of his work , and therefore his job. The vendor's developers are protecting the company product. You will be the only customer with this issue and they will not be able to recreate it.
      Getting back to the fact that this is an interview question, you can assume that the issue is happening under close to ideal conditions. You may want to clarify that with the interviewer, but the question makes more sense when the obvious has been confirmed.
      The first step is to find where the wait(s) are in the process. Running the process and a profiler will separate the application waits from the database waits.
      If the wait is determined to be in the database, then the activity monitor will show the kinds of waits that are impacting the process. The wait will narrow down is the issue is blocking , file contention , poorly written sql or a number of other causes.
      If the wait appears to be in the application you need to decide if it is hardware or code. The simplest way to look at it if the hardware resources are above recommended percentages then the issue can be addressed there . If there is no such elevated use of CPU or memory than the code is likely an issue.
      This may be too general to quote as an answer in an interview. Hopefully you can expand on it some and make the point. I hope to revisit some of these ideas in the future.

No comments:

Post a Comment