Are you pushing a lot of transactions through the AX batch framework? Are you wondering if you've optimized the system for your workload? We recently did some testing in our lab to illustrate some of the performance and concurrency characteristics of the AX 2009 batch framework. Our goal was to show the impact of two commonly overlooked configuration options (batch groups & batch threads) that can greatly impact the throughput of your system. In this post we'll address the topic of batch groups. We'll address the topic of batch thread configuration in a subsequent post.
In our AX 2009 test environment we have 1 SQL Server hosting the AX database and 2 AOS servers configured for batch processing. Two separate companies were created within AX and each has 10,000 orders that need to be invoiced. A separate invoicing batch job was setup for each company to process the orders. In order to understand the results below it's important to note that the invoicing operation in AX is multi-threaded. This means it can leverage multiple batch threads for parallel processing. To illustrate how the batch group and batch server configuration affect batch job concurrency, we ran two different tests:
In scenario 1, a single batch group exists and all batch activity is configured to use it. Both AOS instances are assigned to this batch group and both are using the default of 8 batch threads.
In scenario 2, two batch groups exist. Company A is configured to use batch group A, and Company B is configured to use batch group B. 1 AOS instance is assigned only to batch group A and the other AOS instance is assigned only to batch group B. Both AOS instances are using the default of 8 batch threads.
Scenario 1: The red line represents the number of invoicing batch tasks completed each minute for company A. The blue line represents the number of invoicing batch tasks completed each minute for company B. Both jobs were started at the same time.
Scenario 2: The red line represents the number of invoicing batch tasks completed each minute for company A. The blue line represents the number of invoicing batch tasks completed each minute for company B. Both jobs were started at the same time.
Based on what we saw in the test results I think you'll agree it's important to consider the different workloads you have and how they interact. The test we did was meant to illustrate how tasks for multi-threaded jobs are scheduled and how that affects other jobs (multi-threaded or not). If both jobs were single-threaded, there wouldn't have been any contention because only 2 of the 16 available threads would have been consumed. With that in mind, here are a couple of points to consider for maximum batch concurrency:
In most cases this is a bit extreme, but the concept is important to understand. If all of your batch jobs have the same priority and it's acceptable for any of those jobs to queue up behind another one for a while, then a single pool of batch resources will likely meet your needs. But if you have a time sensitive batch job mixed in with everything else, you might not be able to guarantee that job will execute when you have it scheduled. If you use the two rules listed above, you can rest easy knowing that your jobs will execute on schedule regardless of the other activity on the system.
In the next post on batch performance we'll discuss the topic of batch threads. Stay tuned!
How can I tell which groups a batch job belongs to? The standard inquiry and the table do not contain this field.