Performance tuning is a wide subject with far-reaching ramifications, and should not be limited to the performance testing and tuning exercise at the end of the project. Instead, careful consideration should be given to performance from the beginning of the project. We have talked about these considerations in the previous chapters. Let's review them once again at a higher level:
- Infrastructure planning: It's important to understand the underlying architecture and the peak workload as well as have the hardware sized appropriately; this planning should also consider the scenarios to scale for the expected future growth.
- Requirement gathering: Clarify and define the performance and peak-load requirements during the analysis phase.
- Design and development: Pay attention to scalability and the performance aspects during design. Follow the best practices and guidelines during the design and development phase for better performance.
In the end, we have to validate all the above considerations and make sure that the system is ready for production. Performance testing and tuning will help in defining a baseline and getting the system ready for the production workload.
In this chapter, we will cover the following topics:
- Planning performance testing and tuning
- Tools for performance monitoring
- Factors that impact performance
- Approaching performance issues
Performance tuning is a methodology of identifying performance issues and solving them. It is important to conduct performance and load testing and tuning before going live to eliminate the issues which can impact the business negatively. It does not matter whether you have high volumes or not; you still need performance testing. At this stage of the project, the infrastructure has been configured and reviewed to match the best practices. The development of custom features is complete and functional testing is in progress. This is the time to validate the overall performance of your Dynamics AX solution. The primary goal is to make sure that the solution will accept peak load without any major issue.
The key objective of this exercise is to establish a baseline for the key business scenarios and to test and execute performance tuning and optimization to achieve the following:
- Create a baseline of your core business scenarios.
- Simulate users and transactions in terms of concurrency and volume, and determine the load that the system can handle.
- Execute performance tuning and optimization.
The following flowchart illustrates the performance and load testing and tuning process:
Preparation is the key to the beginning of any process. Consider the following scenario to prepare for performance testing and tuning:
- Define scope: Identify the potential bottlenecks and important business scenarios for which you want to run the performance and load testing on, such as product search, order placement, shipment posting, invoice posting, and so on.
- Set goals: Define the acceptable benchmarks for a combination of processes to be run in parallel.
- Set expectations with the executives: Performance testing is a process for finding the known unknowns and for finding the obvious bottlenecks in the solution. However, there may still be some unknown-unknowns that would surface after the go-live. Good performance testing is like a flu vaccine—it would address the most commonly expected flu for the season. However, it does not guarantee that you won't get the flu.
- Identify the tools to be used: There are several different toolsets for performance monitoring. The following section discusses the tools that will help you to prepare for this.
- Identify the environment to be used: You need to use an environment that is as close to the production in size and configuration as possible, so that you don't have to make assumptions. In my experience, it pays off if you procure the production hardware early on so that it can be used for performance testing.
- Datasets: You should consider a good mix of scenarios from a data perspective, such as shipments from various warehouses, different types of customers, and so on. Identify the critical scenarios from the business perspective and use these for testing. For example, one of my customers had a line of credit from GE, and most of their vendor invoices were paid by GE. It was obvious to use GE as a sample vendor for performance testing of the AP module. Many times, the developers running the performance testing make up their own sample data which may defeat the purpose of testing.
This is an iterative process, so use the tools selected and the scripts developed to run the performance testing to easily repeat the process. Capture and analyze the performance results, make appropriate changes, and repeat the process to evaluate the results.
- Make sure that you are running performance testing on a set of completely migrated data so that your starting point is as close to production as possible.
- Get all of your latest customization code in order to see the performance along with the custom code.
- Run a performance test for individual areas. However, simulate multiple business processes together (that's the way the business will be using the system).
- Try to find the breaking point by loading the transaction volume to know the bottlenecks (AOS/DB or something else), and the point at which the system would max out.
- Analyze the DynamicsPerf (or the results of any other tools used for capturing the performance bottlenecks) results after every run, and make changes as necessary.
- Document the results from every run, such as the time taken, number of records, resource consumption, bottlenecks, and any other observations and changes made.
- Always make smaller changes at a time (like changing the trace flag on SQL, adding indexes, or any code changes) and get the results again. This way, you can see the impact of each individual change.
Prepare and document a summary of the performance testing to be presented to the stakeholders of the project.
- Benchmark the performance numbers for each area, like time taken to process the sales order, number of invoices posted per minute, and the orders created per minute through integration. Document the performance bottlenecks identified and fixed during this process. Review the report on what was found and fixed with the key executive and the project sponsor. If you haven't found issues in testing, most likely, the quality of your testing is questionable.
- This review would be a good time to remind them about the expectations. Otherwise, with the first performance issue in production, you will hear about concerns regarding money invested into the solution.
- They should have a good understanding of what the system can handle, and the system behavior under peak business hours.