One of the most crucial time when implementing your Dynamics AX solution is the few weeks prior the Go Live. At that stage, the infrastructure has been configured with all components and all settings have been reviewed to match best practices. The functional team is running all test cases to sign off all design changes and the development team is fixing the remaining issues before Code Freeze.
It is the time when stakeholders ask you to validate the overall performance of your Dynamics AX solution. The primary goal is to make sure the solution will accept the future load and no major incident will occur. Load Testing is the right approach here to model the expected usage by simulating multiple users who access the application at the same time.
There are mainy objectives that can be achieved by running such Load Test, but here are the three major ones:
Figure 1 shows the number of records created during one run versus the target. Here is a great way to calculate the table growth per company.
Once the goals have been defined and clear expectations validated, you should make sure the following pre requisites are met:
Please note that the scope of the load testing should be targeted. It is key to ensure the stability of the test cases and reach high sucessful test case execution. For example, Disaster Recovery and High Availability should not be tested during this load testing.
A positive side effect of such a project is to deploy all the tools necessary to troubleshoot performance issue after Go Live. During the performance benchmark, these tools will collect detailed trace and the support team will get comfortable on their analysis:
Figure 2 shows an example of long running queries collected during one run.
Note: Trace Parser is only recommended for creating and optimizing the baseline of each business scenarios. Trace Parser analysis should be run prior to the Load Testing because it adds overhead on the execution and will impact the results.
There are several tools to capture the scenario and run them automatically:
Figure 3 shows one example of degradation statistics between baseline run and one stress run.
Remember that Performance Testing is all about iterations to fine tune your scenario and secure the code optimization until you reach an acceptable threshold. Therefore, the automated framework will only be beneficial if you can repeat several run. In the figure 4 below, we can see the load of concurrent users and number of transactions per scenarios during one run executed with Visual Studio Load Test, with a warm up of 10 minutes.
Another great post from Dave Froslie on the Coded UI with AX 2012:
What would a sample baseline be for a simple versus complex scenario, I know this depends on what you're trying to do exactly but I'm just looking for a best practice baseline.
The typical example is the sales order creation with the header and 2 lines. You can test the Baseline with only one user and analyze performance with Trace Parser (Client and Server calls). Then, after the optimization is completed, you are ready to test the concurrency model with several users creating sales order (with a mix of Customer and products of course).
Hope that makes sense, let me know.