This is the second part of a 3 part series on creating a performance engineering trajectory for yourself. In Part -I we looked at how to start shifting your approach towards performance engineering.
We all want to go down the path we talked about in Part 1. But there are several day-to-day challenges in actually being able to do so. And this can turn out to be a major impedance in your learning trajectory.
So lets address some of the tactical challenges that you may be facing in the field.
Every project poses certain challenges in terms of acquiring necessary information from the incumbent people. The reasons for lack of information sharing can range from customer-vendor barrier, onsite-offshore barrier, lack of documentation, lack of bandwidth and so on. A second major reason is also the fact that many a times performance testers don't ask the right questions. Whatever the reason may be you end up testing an application that you don't understand.
Solution - Go White Box!
At the very beginning, set the tone for a white box performance testing, not black box. Make application understanding a prerequisite for starting performance testing. Make sure everyone (including your client and seniors) understand that testing without understanding the application is a sin. It is the absolute wrong way of doing it. Your clients will love you for this later. (Your senior may hate you).
Following are areas you can target for asking questions to gather as much information as possible:
Agreement to Monitor: When I run a test I need to measure the health of transactions and systems. If I don't measure adequately how do I know if performance is good or bad(performance is not just response times). If response times turn out bad, without monitoring there is no next step for troubleshooting. We will end up repeating tests with monitoring anyways.
Agreement on System Understanding: In order to monitor, I need to identify the metrics. In order to know metrics I need to know the components in the application. In order to breakdown and trace a slow transaction I need to understand the call flow. And so on..
Agreement on Metrics: once you have the above agreements, list down exhaustive metrics that you want to monitor for each component, each layer etc. Just make sure you keep reasonable sampling frequency. Keep in mind that you may not even actually analyze all the metrics. But you can't know where your investigation will go before you run the test.
This discussion becomes very easy, when you are already actively trying to troubleshoot a performance issue.