The ability to conduct effective performance testing has become a highly desired skillset within the IT industry. Unfortunately, these highly sought-after skills are consistently in short supply. "Front-end testers" can work with a tool to create a realistic load and although this is an important skillset, creating the load is just the beginning of any performance project. Understanding the load patterns and tuning the environment makes the unique talents of a "performance engineer" worth their weight in gold.

Performance engineers require skills in data analysis such as resource usage patterns, modeling, capacity planning, and tuning in order to detect, isolate, and alleviate saturation points within a deployment. Performance testing generates concurrency conditions and exposes resource competition at a server level. When the competition results in a resource (such as a thread pool) becoming over-utilized, this resource becomes a bottleneck or a saturation point. Performance engineers need to first understand the underlying architectures and develop a sense of where to look for potential scalability issues. Much of these "senses" or skills come from experience, working in many multi-tier environments and successfully tuning bottlenecks. Here are some tips to make the challenging but rewarding transition from a front-end tester to a performance engineer.

Wisdom, Determination, Patience, and Communication
Who said there isn't a whole lot of psychology in technology?  Whether you are determining the current capacity of a deployment or you are recreating a production problem, it's often a very complex task- so many moving parts within the infrastructure, so many numbers to analyze from so many sources, data sets of raw test results to turn into understandable formats, so many people to keep in the loop, so much technical coordination... I could go on and on. It's your professional soft skills which will keep you on the right course. It requires determination to unpeel the layers of an onion and investigate each tier of the deployment. It requires the wisdom to spot trends instead of pursuing the tangents of anomalies. It requires the dedication to keep an eye on many different metrics and isolate resource saturation. And it requires the patience to reproduce scenarios in order to make conclusions based on proof/evidence. And you need to accomplish all of this while being an excellent communicator!

Methodical Approach - The Constant
Spend your time wisely in the beginning and set up the most realistic test scenarios. Then "set" the performance scenario in stone. This means Do Not change even the most minute details in your test case: All transactions flows, all mixtures, all think times, all behaviors - no variations at this point. This is the "constant" in your experiment and it is the only way you can reproduce and compare results. Any deviation within the test case scenario will result in different throughputs which affect resource patterns. Not following this tip will surely lead you on a collision course with Analysis Paralysis!

Architectural Diagram - Identify Potential Bottlenecks by Visualization
Make sure you ask for and receive an architectural diagram of the entire deployment. Map out business transactions to resources utilized within the environment. Make sure you understand all the transaction flows, from front end load balancers down to the shared resource database. Study the deployment and hook up precise monitors, leaving no blind spots. Visualize where contentions or bottlenecks COULD occur. Each resource of the environment must be monitored for signs of saturation. In reality, it's in the identification of where to look for bottlenecks that is the more difficult task. Alleviating these bottlenecks is the easy (and most rewarding) part. But without an architectural map, your journey will easily end by the frustration of getting lost in the dark.

Tuning Hardware and Software Level Bottlenecks
"Tuning is an Art". "Tuning is a Science". Which is it? Hardware servers are restricted by the physical resources (disk io/memory, cpu). Software servers are much more configurable and this is where expertise in needed for tuning. Performance engineers must understand the workings of a "server" in thread pools, caching policies, memory allocations, connection pooling, etc. Tuning is a balancing act. It's the situation where you tune the software servers in order to take full advantage of hardware resources, without causing a flood. Simply opening up all the gates isn't going to help when the backend is saturated with requests. Tuning must be conservative, weighing all the benefits as well as the consequences.

Proof: Reproducible Results
Typically, a seasoned performance engineer will tune a layer of the environment only when the results are reproducible. Always use trends instead of points in time, mere spikes are not cause for architectural changes. As a rule of thumb, you should reproduce 3 times before you make a change. Sometimes this takes a while... So be prepared to be patient. For example, if you are emulating a production login rate of 3 users per second, but the performance deterioration doesn't occur until you have 2000 active users, it will take a while to see it. Making an unnecessary change simply muddies the waters, keep it clear and recreate those exact conditions.

Tune the First Occurring Bottleneck
Make sure you tune the layer which showed contention earliest in the performance test, not the first identified bottleneck. When monitoring a large complex system, there are many counters to keep in your sights. Don't jump the gun and tune a thread pool when you see it becomes saturated, this could actually be a symptom of the problem, not the root cause. Correlate (using graphing is easiest) the point of time of degradation of performance to the first saturation within the environment. Understandably, there is a ton of information to look at - keep it simpler by just looking at the free resources based on percentages (free threads, free cache, and free file descriptors) and this will allow you to spot a bottleneck quicker. When a free resource runs low, there's a possible bottleneck. Understand the resource utilization and free resources will allow you to understand a bottleneck before it affects the end-user response time. In other words, watch as the resource becomes utilized. When free gets low, keep it on your radar for a cause of performance degradation.

Iterative Tuning Process
Tuning is an iterative process. Know that once you have alleviated one bottleneck, you will surely encounter another one. But do not fret... All aspects of servers are limited and since nothing is infinite you will eventually reach the end. Tuning manipulates the gates, requests which don't have a resource are queued and must wait to be serviced. Tuning becomes a process you must repeat until the workload reaches target capacity with acceptable response times.

Validation
Validate, validate, validate. Just as important as recreating and tuning based upon proof is validating that the tuning change had the desired effect. Did it indeed impact scalability in a positive way? Often, performance engineers test out theories. And sometimes, the validation stage will cause a change to be reverted. It's ok that not every change will make it to production. The key is to use a very scientific approach in which you prove the result as well as the requirement.

I hope you gleaned some pearls of wisdom.

Creating the load and emulating production workload is a means to end - you obviously need to create the load before you can capacity plan or understand the scalability of the deployment. But it is the skills in performance analysis that are most valuable. The performance engineer who walks into a project, takes the lead, wastes no time in learning the environment, creates and/or executes the realistic tests, identifies current capacity, isolates and alleviates bottlenecks, documents results, mentors the juniors, and clearly and effectively communicates with everyone from developers on up to the CIO/CTO's, is truly a GOLD MINE.

Becoming a true performance engineer is no easy task, but it's well worth the effort!

• Learn 11 Tips to Make a Viral Video in a Free Report from Videomaker
• Leisure Specialist Tom Watson Offers Tips for Being a Good Dad in a Tough Economy
• From Grill to Table, Reinvent Thanksgiving Classics Outdoors