views:

64

answers:

3

How do you isolate a performance issue to a specific component of the application infrastructure? Specifically, are there distinct markers in the result logs that distinguish between bottlenecks at web, application and/or database server levels?

I was asked this question in an interview and went blank on it. Seems this information is not available anywhere.

A: 

This type of information is usually not available by just looking at the standard results from a performance test.

Parts of the information you are looking for MAY be found by using SiteScope to monitor all the relevant servers in the test. SiteScope offers many counters to look at such as CPU, Memory, Disk I/O and Network I/O - as seen on each server.

This information perhaps gives clues as to where the bottleneck is, and the more counters you add to SiteScope, the bigger the change to pinpoint the bottleneck.

It is a very common misconception that AppServer and DBServer bottlenecks could be identified by just looking at the raw response times or hits, pages etc (web protocol), unless of course the URI accessed defines the exact component(s) in the system...

K.Sandell
that's exactly what I thought. I had already informed the interviewer that my experience with Sitescope is limited. Beyond that, I couldn't come up with anything better. Glad to know that I am not just losing it.
Bash
A: 

In addition to SiteScope and other agentless monitoring of system components, you need to make sure your scenario and scripts are working as expected. This includes proper error checking and use of transactions (and a host of other things). If the transactions are granular enough, this will give you insight into at least the requests that have performance issues. Once you have these indicators, work with the infrastructure team to review logs and other information. Being an iterative process, tests can be made to focus on a smaller and smaller section of the infrastructure.

In addition, loadrunner scripts don't have to be made strictly 'coming in through the frontdoor'. If you have a multi-tiered system, scripts can be made to hit the web/app/database servers directly.

For what to look for, focus on any measurements that have 'knees' or 'hockey stick' type of behaviour. You can hook into any of the server resource type measurements directly in the controller and integrate other team's stats in the analysis phase. Compare with benchmarks at lower virtual user levels to determine what is acceptable and unacceptable.

Good luck!

Edward Leno
"You can hook into any of the server resource type measurements directly in the controller and integrate other team's stats in the analysis phase"I have always wanted to do this, but am never sure of what to ask for from the server/network/dba teams. But, recently, I started to compile a list of KPIs. Hopefully, I will soon get the opportunity to use that list or even better, start using SiteScope.
Bash
A: 

Hi,

If the interview is focused on LoadRunner and SiteScope is considered - I'd come to conclusion that it's more focused on HP/Mercury solutions.. In that case I'd suggest you to look into HP Diagnostics and it's LoadRunner integration capabilities.

Sergey Stefurak
I think it is an industry-wide misbelieve that tools find solutions, or causes for problems. They don't. A good load tester can find out more using Windows' task manager than an idiot can find out using SiteScope or any other super-smart extra-expensive software. Maybe the interviewers wanted to check exactly for that...then sticking to enumerating software features will be a big minus.
TheBlastOne