Throughput query limitations
The throughput queries provides processing rates by counting the number of records created. If you run the throughput query against the YFS_ORDER_RELEASE_STATUS table, you get rates at which order lines move through the pipeline statuses.
Reprocessing
The throughput queries do not report "unsuccessful" work and as a result can appear skewed if you have a lot of order reprocessing. You can, however, augment these throughput queries with data from the Sterling Order Management System Software Statistics (see Statistics).
For example, assume there are 10,000 orders available for scheduling. When the Schedule agent processes the 10,000 orders, it finds that 9,000 orders cannot be scheduled because they are either awaiting authorization or items are backordered. The throughput query reports that the Schedule agent successfully scheduled 1,000 orders but does not indicate that it tried to but was unable to schedule the other 9,000 orders. In these extreme cases, the Schedule agents appear to consume a lot of computing resources for the amount of work (as reported by the throughput query) performed.
In addition to tracking the order flow, you should also track the number of exceptions using the exception query below (see Inbox).
Maximum potential throughput
The throughput query reports actual work done within each measurement or reporting period. The rates can be less than the maximum throughput when there are idle agent threads during the reporting period - for example, when there is not enough work for the agents to process.
To calculate your agent configuration's maximum throughput, you need to create a queue of work so that all agent threads are busy the entire reporting period and the amount of reprocessing is normal or representative of your peak day.