microsoft dynamics ax 2012 retail performance
TRANSCRIPT
-
Microsoft Dynamics
AX
Microsoft Dynamics AX 2012
retail performance
White Paper
This white paper provides an overview of a series of performance tests run by Microsoft to enable customers and partners to better size capacity for the infrastructure that they
require for an implementation of the Microsoft Dynamics AX 2012 Retail module.
May 2013
www.microsoft.com/dynamics/ax
-
2 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Copyright Microsoft Dynamics is a line of integrated, adaptable business management solutions that enables you and your people to make business decisions with greater confidence. Microsoft Dynamics works like and with familiar Microsoft software, automating and streamlining financial, customer relationship and supply chain processes in a way that helps you drive business success.
U.S. and Canada Toll Free 1-888-477-7989
Worldwide +1-701-281-6500
www.microsoft.com/dynamics
Disclaimer
This document is provided as-is. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product or service. You may copy and use this document for your internal, reference purposes.
Performance tests and ratings are measured using the computer systems and components specified in this
document and reflect the approximate performance of Microsoft Dynamics AX 2012 R2 as measured by those tests. Any difference in system hardware, software design or configuration, customizations, data composition, or indexes may affect actual performance of the software. Users should consult other sources of information to evaluate the performance of systems or components they are considering purchasing.
2013 Microsoft Corporation. All rights reserved.
Microsoft, Microsoft Dynamics, SharePoint, SQL Server, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
-
3
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Table of Contents
Copyright .................................................................................................... 2
Table of Contents ........................................................................................ 2
Introduction ................................................................................................ 6
Solution overview ....................................................................................... 7
Scenarios .................................................................................................... 7
Performance testing methodology .............................................................. 8
Synch Service design overview ................................................................... 9
Retail in-house performance topology ...................................................... 10 Topology details................................................................................................................11 Topology notes .................................................................................................................11 Configuration and setup ....................................................................................................12 Initial master dataset .......................................................................................................12 Test methodology and automation ....................................................................................12
Scenario: Publish product assortments ..................................................... 13 Results summary ..............................................................................................................13 Publish an assortment ......................................................................................................13
Overview ....................................................................................................................... 13 Results summary ........................................................................................................... 14 Suggested scale-out options .......................................................................................... 16
Create actions for 100,000 assorted products for 100 retail stores ..................................17 Create actions overview ................................................................................................ 17 Results summary ........................................................................................................... 18
A-1040 scheduler job ........................................................................................................20 Synch Service overview ................................................................................................. 20 Results summary ........................................................................................................... 20 HQ/Synch Service data package volume ........................................................................ 22 Resource usage on HQ/Synch Service ........................................................................... 22 Suggested scale-out options for HQ/Synch Service ....................................................... 22
Scenario: Send trade agreements to retail stores ..................................... 23 High-level results summary ..............................................................................................23 Post trade agreement .......................................................................................................23
Results summary ........................................................................................................... 23 Suggested scale-out option ........................................................................................... 23
Create actions ...................................................................................................................24 Results summary ........................................................................................................... 24 Suggested scale-out options .......................................................................................... 24
-
4 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
A-1040 ..............................................................................................................................24 Results summary ........................................................................................................... 24 System resource usage for Synch Service ...................................................................... 25 Suggested scale-out options for HQ/Synch Service ....................................................... 26
Scenario: End-of-day financial posting, including POS transaction import, inventory posting, statement calculation, and statement posting ............. 27
Dataset .............................................................................................................................27 End-to-end financial posting results .................................................................................27 P-0001 schedule job .........................................................................................................28
Results summary ........................................................................................................... 28 HQ/Synch Service data package volume ........................................................................ 30 System resource usage .................................................................................................. 30 Suggested scale-out options .......................................................................................... 30
Inventory posting for end-of-day sales .............................................................................31 Dataset .......................................................................................................................... 31 Results summary ........................................................................................................... 31 Resource usage ............................................................................................................. 31
Calculate and post statements ..........................................................................................32 Dataset .......................................................................................................................... 32 Results summary ........................................................................................................... 32
Additional end-of-day financial posting scenario and results ............................................33 Topology for this additional test only............................................................................. 33 Dataset .......................................................................................................................... 33 End-to-end financial posting results summary ............................................................... 34 Resource usage ............................................................................................................. 34
Scenario: Trickle feed to import POS transactions and post inventory ...... 35 Dataset .............................................................................................................................35 End-to-end trickle feed flow results summary ..................................................................35 Resource usage .................................................................................................................36 Suggested scale-out options .............................................................................................37
Scenario: Add a product to a retail POS transaction .................................. 38 Topology ...........................................................................................................................38 Results summary ..............................................................................................................38
Scenario: POS product search ................................................................... 40 Topology ...........................................................................................................................40 Results summary ..............................................................................................................41
Scenario: POS customer search................................................................. 42 Topology ...........................................................................................................................42 Results summary ..............................................................................................................43
Scenario: POS initial offline synchronization ............................................. 44 Topology ...........................................................................................................................44 Overview ..........................................................................................................................44 Results summary ..............................................................................................................45 Suggested scale-out options .............................................................................................46
-
5
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Scenario: Multiple concurrent calls to the Real-time Service APIs ............ 47 Dataset .............................................................................................................................47 Topology ...........................................................................................................................47 Results summary ..............................................................................................................48 Resource usage .................................................................................................................48
Scenario: Initial catalog publishing ........................................................... 49 End-to-end flow ................................................................................................................49 Dataset .............................................................................................................................49 Topology ...........................................................................................................................49 Overall results summary ...................................................................................................50 Result notes ......................................................................................................................50
Validate the catalog in Microsoft Dynamics AX .............................................................. 50 Publish the catalog in Microsoft Dynamics AX ................................................................ 50 Run the A-1075_OC job from Microsoft Dynamics AX .................................................... 50 Run SharePoint/RetailPublishingJob ............................................................................. 50
Resource usage .................................................................................................................51 Resource usage for AOS and HQ/Synch Service ............................................................. 51 Resource usage for SharePoint/catalog publishing ....................................................... 51
Scale-out option ................................................................................................................51
Conclusion ................................................................................................ 52
Appendix ................................................................................................... 53 VM configuration information (VMs used for preceding test) ............................................53 Physical SQL Server hardware information .......................................................................53 Microsoft Dynamics AX database SQL Server settings.......................................................54
Specific changes compared to standard SQL Server settings ......................................... 54 Microsoft Dynamics AX database SQL Server sp_configure output ................................ 55
Microsoft Dynamics AX table initial row count before the start of any of the preceding
tests..................................................................................................................................58
-
6 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Introduction
Todays retail landscape offers unprecedented opportunities alongside some daunting challenges. Economic factors, the increasing choice in products and shopping formats, and unparalleled access to information are fuelling todays empowered shoppers, who expect more from their retail experience. The focus of the retail experience has expanded well beyond the walls of the brick and mortar store, and now includes everything from a retailers website and call center, to marketplaces and social networks. Today, retail is connected seamlessly as one omni-channel experience.
To deliver on the needs for todays retail, the Microsoft Dynamics AX 2012 R2 Retail module relies on a robust interoperable architecture that scales to the needs of the enterprise. This white paper is intended for customers who have already implemented the Microsoft Dynamics AX 2012 R2 Retail
module and are looking for options to scale their infrastructure to support the growth of the business. This white paper is also intended for customers who are embarking on implementing the Microsoft Dynamics AX 2012 R2 Retail module and are evaluating topology options to implement a solution that will scale to their organization.
-
7
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Solution overview
As part of the release process for Microsoft Dynamics AX 2012 R2, Microsoft conducted a series of performance tests to enable customers and partners to better size capacity for the infrastructure that they require for their implementation. The performance tests showcase the ability of the solution to scale based on critical business scenarios that pertain to the retail industry.
Retail Headquarters Brick and Mortar Channel
Online Channel
AX client Commerce Data Exchange Synch
service
Offline database
SQL Server databases:AX, Synch
service
Enterprise Portal
AX client
Real-time service
POS terminals
SQL Server databases:
StoreSynch service
Commerce Data Exchange Synch service
AOS
SQL Server databases:
Commerce runtime, SharePoint,
Synch service
SharePoint FrontendCommerce Runtime
Commerce Data Exchange Synch service
SharePoint BackendCommerce Runtime
Based on need most components in the system support scale- out options of either clustering or multi-instance
SQL Server:SharePoint
(Enterprise Portal)
Retail SolutionServer Roles Overview
Microsoft Dynamics AX Retail module omni-channel logical topology
Scenarios
The performance tests include many functional scenarios across different client and integration technologies, providing a view of the core retail scenarios. The following scenarios were completed to evaluate performance:
Publishing assortments to retail stores
Posting trade agreements to retail stores
End-of-day financial posting from retail stores to headquarters (HQ)
The performance tests also include the following scenarios:
Trickle feed
Adding products to retail point of sale (POS) transactions by using the retail POS terminal
Product search using the retail POS terminal
Customer search using the retail POS terminal
-
8 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Initial offline synchronization between the store database and the offline database
Concurrent Commerce Data Exchange Real-time Service API calls
Initial catalog publishing
The following three primary scenarios are run as part of the performance testing to identify the scale
characteristics of Commerce Data Exchange: Synch Service:
1. Publishing assortments to retail stores:
Create an assortment of 100,000 products across 100 stores, and then publishing the assortment.
Run the Create actions periodic job.
Run the A-1040 job for all 100 stores.
Posting trade agreements through retail stores:
1. Create 10,000 product trade agreements, and then post the trade agreements.
Run the Create actions job to convert pre-actions to actions.
Run the A-1040 job for all 100 stores.
End-of-day financial posting flow:
2. Create 10,000 retail transactions in each store database, with five line items per transaction per store. Then run the P-0001 job for all 100 stores.
Run the Post inventory job for all 100 stores in batch processing mode.
Run the Calculate statement job for all 100 stores in batch processing mode.
Run the Statement posting job for all 100 stores in batch processing mode.
Performance testing methodology
All inbound and outbound transaction feeds are run through the servers that run Synch Service.
The Microsoft Dynamics AX client application is used to manage batch schedules.
Application Object Server (AOS) instances run as batch.
No Microsoft SQL Server replication is configured for the Microsoft Dynamics AX database SQL Server host.
-
9
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Synch Service design overview
The following diagram shows the logical flow of assortment publishing and trade agreement posting to the store through Synch Service. Publishing an assortment creates the corresponding channel-specific data in the RetailAssortmentExploded table in the Microsoft Dynamics AX database, and it also creates the pre-actions in the RetailConnPreaction table.
The Create actions periodic job reads the pre-actions and then uses table distribution settings in
Microsoft Dynamics AX to generate actions. When you run the A-1040 scheduler job, Microsoft Dynamics AX sends a query package for each channel to Synch Service. Synch Service uses this query package to extract the data and create the data package that will be sent to the stores.
If the Create actions periodic job is run in batch processing mode, it will use the Microsoft Dynamics AX batch processing framework to scale out processing by using multi-threaded logic. For this to work, you need to update the Retail Scheduler Number of documents in the batch task parameter to a
larger number. For example, the number must be in the thousands instead of 0 (zero).
-
10 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Retail in-house performance topology
POS/Commerce Data Exchange Synch
service
HQ/Commerce Data Exchange Synch
service
Store databases
AOS instances
AX client/ Test automation client
AX database
Real-time service
Store database
Real-time service Stress test clients
POS Terminal, Offline Sync
service, Offline
database
Databases: SharePoint, Commerce runtime
Online/Commerce Data Exchange Synch service
Microsoft Dynamics AX Retail in-house lab topology
-
11
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Topology details
Retail topology
role
Virtual
machine
(VM) or
physical
Number of
VMs for 100
stores
configuration
Number of
processors
Processor
speed
(GHz)
Memory
size
allocated
(GB)
Disk
capacity
(GB)
AOS VM 3 4 2.133 16 300
HQ/Synch Service VM 2 4 2.133 16 300
POS/Synch Service VM 6 8 2.133 32 500
Microsoft Dynamics
AX client
VM 1 2 2.133 8 300
Microsoft Dynamics
AX database
Physical 1 24 2.266 64 2,048
Store database (POS
online mode)
Physical 2 24 2.266 64 2,048
Real-time Service VM 2 4 2.133 16 300
Store database
(online mode)
VM 1 2 2.133 4 200
POS client, offline
service, offline
database
VM 1 1 2.133 2 150
Microsoft SharePoint
database/Commerce
Run-time (CRT)
database
Physical 1 24 2.266 64 2,048
SharePoint
application server
Physical 1 24 2.266 64 2,048
Topology notes
In each VM for POS/Synch Service, up to 17 instances are running at any given time. One POS/Synch Service instance is set up per store for 100 stores. One hundred POS/Synch Service instances are distributed among six VMs.
In each Synch Service VM, up to five instances are running at any given time.
In each VM, eight AOS threads per instance are running at any given time.
Two physical machines are hosting 100 store databases. The lab environment uses 10-GB network switches.
SQL Server 2008 R2 is used as the database server.
-
12 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Configuration and setup
100 stores
10 terminals per store
100 database profiles
10 AOS profiles
Initial master dataset
Create 100,000 non-variant products by using X++ code directly in 10 different product categories.
Create one assortment, include the 10 product categories, and assign the assortment to the 100 stores.
Test methodology and automation
For trickle feed flow, which is the periodic import throughout the day of POS transactions and updates to inventory in Microsoft Dynamics AX, retail POS transactions were created by using SQL Script across 100 store databases. For assortment publishing and trade agreement posting, item creation was automated in X++ functions by using the batch processing framework.
Performance counter measurements and collection are automated through Microsoft Windows PowerShell and C# code.
-
13
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Scenario: Publish product assortments
Deploy the initial test demo dataset. The demo data contains information for 1,000 products.
Create 100,000 products in Microsoft Dynamics AX, and assign the products among 10 product categories.
Truncate the RetailConnPreAction and RetailConnAction tables in Microsoft Dynamics AX.
Configure one AOS instance and eight AOS batch threads.
Assort 100,000 products:
Create a new assortment.
Add a retail assortment hierarchy node for 100 stores.
Add a parent retail product category node that includes all the products.
Publish the assortment.
Run the Create actions job by using a batch job.
Run the A-1040 job for all the following stores / HQ Synch Service combinations
Number of stores: 5, 10, 20, 50, 100
Number of HQ/Synch Service instances used: 1, 2, 5, 10
Results summary
The following table summarizes the results for an assortment of 100,000 products.
Assortment
publishing step
Latency for this number of retail stores
5
(1 HQ/Sync
h Service)
10
(1 HQ/Sync
h Service)
20
(1 HQ/Sync
h Service)
50
(1 HQ/Sync
h Service)
100
(2 HQ/Sync
h Service)
Publish an assortment 00:13:57 00:22:39 01:05:45 01:32:12 01:56:18
Create actions 00:00:20 00:00:22 00:00:34 00:01:01 00:01:23
A-1040 00:33:54 01:05:53 02:22:42 05:46:00 05:40:00
Total 00:48:12 01:28:54 03:29:01 07:19:13 07:37:41
Publish an assortment
Overview
Assortment publishing uses the batch processing framework in Microsoft Dynamics AX. Assortment publishing creates one batch task per store in Microsoft Dynamics AX, so that it can scale out parallel execution of assortment publishing by store. Each batch task creates one record per product, for each
store in the temp table. When the batch task has finished creating all the records for a store, the records are moved from the temp table to the RetailAssortmentExploded table. Each batch task also creates one pre-action in the RetailConnPreaction table. This pre-action is labeled as a packed query.
-
14 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Results summary
The following chart shows that the assortment publishing duration increases as the number of retail stores per assortment increases.
Retail assortment job batch latency vs. the number of retail stores with a single AOS instance and eight AOS
threads
5 10 20 50 100
Publish assortment for100,000 products
0:13:57 0:22:39 1:05:45 1:32:12 1:56:18
0:00:00
0:14:24
0:28:48
0:43:12
0:57:36
1:12:00
1:26:24
1:40:48
1:55:12
2:09:36
Ass
ort
men
t p
ub
lish
ing
late
ncy
(h
h:m
m:s
s)
Number of retail stores
"Retail assortment job" batch latency for 100,000 products vs. the number of stores
-
15
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
The following chart shows the CPU usage on a Microsoft Dynamics AX database and the CPU usage when the Retail assortment job batch processing task is running.
The calculations in the chart are based on the following factors:
A single AOS instance is running on a single VM configured with four processors, 16 GB of RAM, and
eight AOS threads.
The average CPU usage of the AOS instance is less than 26 percent across all variations from five to 100 stores.
The average CPU usage on the Microsoft Dynamics AX database grows as the number of stores increases to 100.
In the Microsoft Dynamics AX database, most of the time is spent creating records in the RetailAssortmentExploded table. One record per product per store is created.
Average CPU usage percentage on the AOS and Microsoft Dynamics AX database machines vs. the number of
retail stores during assortment publishing of 100,000 products with a single AOS instance and eight AOS
threads
5 10 20 50 100
Avg. CPU Usage [AOS] % 18.22 23.79 24.99 25.83 24.50
Avg. CPU Usage [AX DB] % 5.20 10.44 11.18 14.16 33.90
0.00
5.00
10.00
15.00
20.00
25.00
30.00
35.00
40.00
CP
U u
sage
%
Number of retail stores
CPU usage for Publish assortment for 100,000 products
-
16 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
The following table shows that, for publish assortment for 100,000 products and 100 stores, Microsoft Dynamics AX will insert 10 million records in the RetailAssortmentExploded table and 100 records in the RetailConnPreaction table.
Microsoft Dynamics AX table name Number of records inserted in table
RetailAssortmentExploded 10,000,000
RetailConnPreaction 100
Suggested scale-out options
Add more AOS instances and additional AOS batch threads to enable more assortment publishing tasks to run concurrently.
Avoid having the same retail product category in multiple retail assortments, because any changes in a specific retail product category can cause the corresponding assortments to be republished. This
will significantly slow down the Publishing assortment batch job.
-
17
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Create actions for 100,000 assorted products for 100 retail stores
Set the Retail Scheduler Number of documents in batch task parameter to 6,250. This will be referred to as the batch size).
Run the Create actions job in batch processing mode.
Create actions overview
Create actions batch processing uses the Retail Scheduler Number of documents in a batch task parameter. If this parameter is not defined, or if it has been set to 0 (zero), only one batch task is
created. The Create actions job starts processing all pre-actions and then converts them into actions.
If a batch size is defined, the Create actions job first reads the total number of pre-actions that have not been processed from RetailConnPreaction and then creates the RecID list for the batch tasks. One batch task is created and assigned N number of unprocessed pre-actions, where N is the number of
documents in a batch task. The main Create actions batch processing job will create more batch tasks until all the pre-actions are submitted for processing. When actions are being generated, each action is mapped to the individual table in the Microsoft Dynamics AX database. A job will process actions
and send actual data to the store database.
-
18 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Results summary
The following chart shows the Create actions latency for 100,000 assorted products for stores ranging in number from five to 100. The Create actions job for publish assortment for 100 stores with 100,000
assorted products is completed in 37 seconds.
Create actions latency vs. the number of retail stores with a single AOS instance and eight AOS threads
5 10 20 50 100
Create Actions of 100,000products across stores
0:00:20 0:00:22 0:00:34 0:01:01 0:01:23
0:00:00
0:00:17
0:00:35
0:00:52
0:01:09
0:01:26
0:01:44
Cre
ate
acti
on
s la
ten
cy (
hh
:mm
:ss)
Number of retail stores
Create actions batch latency for 100,000 assorted products vs. the number of stores
-
19
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Average CPU usage percentage on the AOS and Microsoft Dynamics AX database machines vs. the number of
retail stores during the Create action job for 100,000 assorted products with a single AOS instance and eight
AOS threads
5 10 20 50 100
Avg. CPU Usage [AOS] 10.10 11.00 15.55 17.09 25.93
Avg. CPU Usage [AX DB] SQLServer
0.01 0.94 0.02 0.13 0.45
0.00
5.00
10.00
15.00
20.00
25.00
30.00
CP
U u
sage
%
Number of retail stores
CPU usage on AOS and Microsoft Dynamics AX database [Create actions running for 100,000 assorted products]
-
20 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
A-1040 scheduler job
Synch Service overview
The A-1040 scheduler job sends a RecID with a packed query for each action in a package file. HQ/Synch Service reads the input package file and then sends X++ queries through .NET Business Connector (BC.NET) for one store. When all the business data is received before it is packaged in a compressed file, Synch Service forwards the business data to POS/Synch Service for processing.
Results summary
The following chart shows the latency of a single Synch Service instance for the A-1040 job as the number of stores increases from 5 to 50. You can see that, from stores 5 to 10, 10 to 20, and 10 to 50, there is an almost-linear projection.
Single HQ/Synch Service instance latency from A-1040 job execution vs. the number of stores for 100,000
assorted products
5 10 20 50
A-1040 for 100,000 productsper store
01:03:43.521 02:20:23.908 05:43:22.958 11:19:42.636
00:00:00.000
01:12:00.000
02:24:00.000
03:36:00.000
04:48:00.000
06:00:00.000
07:12:00.000
08:24:00.000
09:36:00.000
10:48:00.000
12:00:00.000
HQ
/Syn
ch S
ervi
ce la
ten
cy (
hh
:mm
:ss)
Number of retail stores
HQ/Synch Service latency for 100,000 products vs. the number of stores
-
21
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
The following chart shows that, if the A-1040 job was run to pull 10,000 transactions from 100 stores with one HQ/Synch Service instance, and then add two, five, and 10 Synch Service instances, the overall execution time is reduced, because all instances are running in parallel by running a separate A-1040 job per HQ/Synch Service instance. This chart shows that Synch Service can accommodate a
number of retail stores.
Average HQ/Synch Service latency of the A-1040 job for 100 stores vs. the number of HQ/Synch Service
instances
1 2 5 10
HQ/Synch service latency withdifferent number of HQ/Synchservice instances [A-1040 job
for 100 stores]
11:19:42.636 05:40:00.000 02:25:57.869 01:22:28.732
00:00:00.000
01:12:00.000
02:24:00.000
03:36:00.000
04:48:00.000
06:00:00.000
07:12:00.000
08:24:00.000
09:36:00.000
10:48:00.000
12:00:00.000
HQ
/Syn
ch S
ervi
ce la
ten
cy (
hh
:mm
:ss)
Number of HQ/Synch Service instances
HQ/Synch Service latency vs. the number of HQ/Synch Service instances [A-1040 job for 100 stores]
-
22 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
HQ/Synch Service data package volume
The HQ/Synch Service data package volume grows linearly with the number of stores. The same data size of 100,000 assorted products is sent to stores by using the A-1040 job. The results also show that
Synch Service creates compressed data files for 100,000 products for each store. For 100 stores, the data volume is 1.6 GB. For 10,000 products, the size of the store is 1.6 MB.
Resource usage on HQ/Synch Service
The average CPU usage is below 10 percent on a four-processor VM, with a maximum of 85 percent.
The average memory usage is 2.0 GB, with maximum of 2.75 GB.
The average disk queue length is 0.3, with a maximum of 3, which occurs only when a file is created.
The average network throughput is 300 KB per second, with a maximum of 675 MB per second while all data files are transferred from the HQ/Synch Service VM to POS/Synch Service VMs. With
smaller network bandwidth and a remote location for POS/Synch Service, you might notice more delay in sending packets from the HQ/Synch Service machine to the POS/Synch Service machine.
The Microsoft Dynamics AX database size after the A-1040 job was 33 GB, and the stores database size was 1.2 GB.
Suggested scale-out options for HQ/Synch Service
Add more HQ/Synch Service instances, so that when you use an A-1040 job, data is quickly sent to stores. From the preceding test results, you can see that a single instance of HQ/Synch Service takes 6 to 6.5 minutes to read 1.2 million records from the AOS instance per store. The same time is observed when 10 HQ/Synch Service instances are running concurrently.
Distribute stores among different distribution schedules:
Create a distribution list to divide the workload.
Schedule a distribution of the A-1040 job at different times, so that no two jobs run at the same
time. This will prevent a bottleneck, where all store information is being read at once for the A-1040 job.
-
23
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Scenario: Send trade agreements to retail stores
Create 100,000 products in Microsoft Dynamics AX, and assign those products to 10 different categories.
Truncate the RetailConnPreAction and RetailConnAction tables in Microsoft Dynamics AX.
Run one AOS instance, with eight AOS batch threads per AOS instance.
Post trade 1 million lines in the Trade Agreement Journal:
Create 10,000 lines in the Trade Agreement Journal.
Create 100 separate Trade Agreement Journals.
Post each journal.
Run the Create actions job in batch processing mode.
Run the A-1040 job for all 100 stores.
Variations:
Number of stores: 5, 10, 20, 50, 100
Number of HQ/Synch Service instances used: 1, 2, 5, 10
High-level results summary
The following table summarizes the results for 1 million trade agreements.
Post trade agreement step Latency for 100 retail stores (2 HQ/Synch
Service)
Post trade agreement 07:30:00
Create actions 03:07:49
A-1040 04:20:16
Total 14:58:05
Post trade agreement
Deploy the initial test demo dataset, which contains 1,000 products.
Truncate the RetailConnPreAction and RetailConnAction tables in Microsoft Dynamics AX to remove all pre-actions and actions before starting the scenario steps and performance measurements.
Create 100 journals with 10,000 item lines that include a change in the sales price.
Use the Microsoft Dynamics AX client to post all 100 journals one at a time.
Results summary
Each journal posting took 4 minutes, 30 seconds. The total time to post 100 journals was 7.5 hours.
No system resources (CPU usage, memory usage, disk I/O, or network) were a constraint or caused a bottleneck on the Microsoft Dynamics AX client, AOS, or the database machines.
Suggested scale-out option
Create more journals, each with a smaller number of products for example, 10,000 lines per journal. Because it takes longer to post a journal with a large number of lines, splitting journal lines between multiple journals will reduce the posting time.
-
24 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Create actions
Microsoft Dynamics AX, setting: Set the Retail Scheduler Number of documents in batch task parameter to 6,250, which will be referred to as the batch size. This setting is used by Create actions batch processing to scale out the processing of pre-actions.
Run the Create actions job in batch processing mode.
Run eight AOS threads per AOS instance.
Results summary
Processing 1 million pre-actions and generating 2 million actions took 3 hours, 7 minutes, 49 seconds. In the current execution, the batch size for one thread is 6,250, resulting in the creation of 160 batch threads. Because there are eight AOS threads, only eight threads were active at any given time. It took approximately 12 minutes for each thread to run and create 6,250 actions.
Suggested scale-out options
Ensure that all processed pre-actions and actions are deleted periodically.
Define the batch size to leverage the optimal processing of pre-actions.
Depending on the number of AOS instances and AOS threads per AOS instance that are assigned for Create actions batch processing, you can define the value for the Retail Scheduler Number of documents in batch task parameter. For example, if you will be processing 100,000 pre-actions every time by using eight AOS threads, set Number of documents in batch task to 10,0000/8 = 12,500.
Consider adding more AOS instances and, based on the average number of pre-actions to process,
consider increasing the value of the Number of documents in batch task parameter.
A-1040
Run the A-1040 job for 100 retail POS stores in batch processing mode.
Vary the number of HQ/Synch Service instances between one, two, five, and ten.
Results summary
The following chart shows that Synch Service can scale out with more instances of HQ/Synch Service, and that it can handle processing 1 million trade agreements to 100 stores in less than 1 hour with 10 HQ/Synch Service instances running.
-
25
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
The results also show that HQ/Synch Service creates compressed data files of 17.25 MB per store for 100,000 products.
Average HQ/Synch Service latency vs. the number of HQ/Synch Service instances where the A-1040 job is run
for 1 million trade agreements to 100 stores
System resource usage for Synch Service
The average CPU usage is below 10 percent on a four-processor VM, with a maximum of 100 percent for one to two HQ/Synch Service instances on the same VM. If five instances are hosted on the VM
with four processors, the average CPU usage goes to 65 percent. We recommend that the
maximum number of instances hosted on a machine equal the number of Synch Service instances to prevent excessive context switching.
The AOS CPU usage increases by 3 to 4 percent with the number of HQ/Synch Service instances; so for 10 HQ/Synch Service instances, the average CPU usage for a single AOS instance is 54 percent. One AOS instance can handle at least 10 more Synch Service instances.
The average memory usage is 2.0 GB, with a maximum of 2.75 GB.
The average disk queue length is less than 1, with maximum of 10 for 10 HQ/Synch Service instances.
1 2 5 10
A-1040 for 1 MillionTrade Agreement per
store09:16:29.317 04:05:31.344 01:46:43.343 00:58:37.773
00:00:00.000
01:12:00.000
02:24:00.000
03:36:00.000
04:48:00.000
06:00:00.000
07:12:00.000
08:24:00.000
09:36:00.000
10:48:00.000
Syn
ch S
ervi
ce la
ten
cy (
hh
:mm
:ss.
00
0)
Number of Synch Service instances
Average Synch Service latency vs. the number of Synch Service instances [A-1040 job for 1 million trade agreements to 100
stores]
-
26 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
The average network throughput is 1.3 MB per second, with a maximum of 176 MB per second while all data files are transferred from the HQ/Synch Service VM to a POS/Synch Service VM. With the bandwidth of a smaller network and a remote location for POS/Synch Service, you might notice more delay in sending packets from the HQ/Synch Service machine to the POS/Synch Service
machine.
The Microsoft Dynamics AX database size after A-1040 ran was 18 GB, and one stores database size was 1.2 GB
Suggested scale-out options for HQ/Synch Service
Add more HQ/Synch Service instances to reduce the time it takes to send data to stores by using the A-1040 job. The test results show that a single instance of Synch Service takes 6 to 6.5 minutes
to read 2 million records from the AOS instance per store. The same time is observed when 10 HQ/Synch Service instances are running concurrently. This leads to the conclusion that the time
will remain at 6 to 6.5 minutes, regardless of the number of Synch Service instances that are running.
Distribute stores among different distribution schedules:
Create a different distribution list to divide a workload.
Schedule a distribution of the A-1040 job at different times, so that no two jobs run at the same time. This will prevent a bottleneck, where all store information is being read at once for the A-1040 job.
-
27
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Scenario: End-of-day financial posting, including POS transaction import, inventory posting, statement calculation, and statement posting
Dataset
For each store database for 100 stores, create 10,000 retail transactions that contain the following:
5 line items per transaction
10,000 products used across the 10,000 transactions
Anonymous customers for all transactions
Run two AOS instances.
Run eight AOS threads for each AOS instance.
Apply the following index:
create index CustInvoiceTrans_perfIdx on CustInvoiceTrans (PARTITION, DATAAREAID, INVOICEID) with (online = on)
Run the P-0001 job for all 100 stores.
Variations:
Number of stores: 5, 10, 20, 50, 100
Number of HQ/Synch Service instances used: 1, 2, 5, 10, which are connected to one AOS instance
Run the following posting flow for 100 stores and 10,000 transactions per store, with five product lines per transaction per store. This batch job will run in batch processing mode with a total of 24 AOS
threads.
Post inventory
Statement calculation
Statement posting
End-to-end financial posting results
The following table shows the results for the financial posting in 100 stores. Financial posting included
pulling 10,000 transactions from each store, running through the inventory posting, and calculating and posting the statements in one full end-to-end flow. In the following table, the P-0001 job results are displayed for 2 HQ/Synch Service instances.
Financial posting step Latency
P-0001 (two Synch Service instances) 00:59:51
Post inventory 02:25:05
Statement calculation 00:50:59
Statement posting 06:30:14
Total 10:46:09
-
28 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
P-0001 schedule job
Results summary
The following chart shows the latency of HQ/Synch Service for the P-0001 job with a single HQ/Synch Service instance as the number of stores increases from five to 100.
With one HQ/Synch Service instance, the P-0001 job latency increases linearly with the increase in the number of stores. On average, it takes one second to process 200 transactions from one store, with five lines per transaction.
Single HQ/Synch Service instance latency from P-0001 job execution vs. the number of stores for 10,000
transactions
5 10 20 50 100
P-0001 (10KTransactions/Store)
00:04:41.236 00:09:44.000 00:18:06.460 00:50:25.443 01:48:09.334
00:00:00.000
00:14:24.000
00:28:48.000
00:43:12.000
00:57:36.000
01:12:00.000
01:26:24.000
01:40:48.000
01:55:12.000
Syn
ch S
ervi
ce la
ten
cy (
hh
:mm
:ss.
00
0)
Number of retail stores
Synch Service latency vs. the number of stores [P-0001 job]
-
29
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
The following chart shows the latency of HQ/Synch Service for the P-0001 job for 100 stores as the number of HQ/Synch Service instances increases from one to 10.
The results show that, if you add more HQ/Synch Service instances in parallel, the P-0001 job can scale out evenly. This information can be useful for planning as the number of stores or the number of
transactions increases.
For 100 stores, the average HQ/Synch Service latency of P-0001 vs. the number of HQ/Synch Service instances
for 10,000 transactions
1 2 5 10
P-0001 (10KTransactions/Store)
01:48:09.334 00:59:18.986 00:35:19.854 00:22:17.520
00:00:00.000
00:14:24.000
00:28:48.000
00:43:12.000
00:57:36.000
01:12:00.000
01:26:24.000
01:40:48.000
01:55:12.000
Syn
ch S
ervi
ce la
ten
cy (
hh
:mm
:ss.
00
0)
Number of Synch Service instances
Average Synch Service latency vs. the number of Synch Service instances [P-0001 job]
-
30 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
HQ/Synch Service data package volume
HQ/Synch Service creates 3.75-MB compressed data files per store for a dataset of 10,000 transactions where there are five lines per transaction.
For a single store and 1,000 transactions, the data package size is .375 MB.
For 100 stores, the data package size is 375 MB.
The current results also show that the data volume grows linearly as the number of stores and transactions increases for a single HQ/Synch service instance. This data can be used to determine how much data can be transferred with every P-0001 job pull to HQ/Synch Service.
System resource usage
The average CPU usage is below 15 percent on a four-processor VM, with a maximum of 100 percent.
The average memory usage is 2 GB, with a maximum of 3.75 GB.
The average disk queue length is 0.7, with a maximum of 4.
The average network throughput is 450 KB per second, with a maximum of 25 MB per second while all the data files are transferred from the POS/Synch Service VM to the HQ/Synch Service VM. With smaller network bandwidth and a remote location for POS/Synch Service, you might notice more
delay in sending packets from the POS/Synch Service machine to the HQ/Synch Service machine.
Suggested scale-out options
Add more HQ/Synch Service instances to decrease the overall processing time.
Run the P-0001 job and then post the inventory at regular, frequent intervals to minimize the overall processing time for end-of-day financial posting.
Distribute stores among multiple distribution schedules:
Create a different distribution list to divide the workload for different stores.
Schedule the P-0001 job for different stores at different times, so that system isnt overloaded. This will prevent a bottleneck, where all store information is being read at once for the P-0001 job.
Regularly archive processed transactions in HQ/Synch Service from the RetailTransactionTable, RetailTransactionSalesTrans, RetailTransactionPaymentTrans, and RetailTransactionTaxTrans tables to prevent performance issues.
-
31
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Inventory posting for end-of-day sales
Dataset
100 stores
10,000 transactions per store
5 line items per transaction
10,000 total products distributed across all transactions
Microsoft Dynamics AX configuration setting: In Retail parameters > Aggregation, select the
Voucher transactions check box. This will turn on aggregation for statement posting.
2 AOS instances
8 AOS threads per AOS instance
Results summary
Updating the inventory of 10,000 products from 100 stores took 2 hours, 25 minutes. Posting the inventory resulted in the update and insertion of records in the InventSum, InventSumLogtts,
InventTrans, and InvenTransOrigin tables.
Resource usage
The average AOS CPU usage is 78 percent, with a maximum of 100 percent for short durations.
The memory usage on AOS is 11 GB out of 16 GB when eight AOS threads were running per AOS instance.
The average CPU usage on the Microsoft Dynamics AX database SQL Server instance is 11 percent,
with a maximum of 80 percent.
The memory usage on the Microsoft Dynamics AX database is 42 GB out of 64 GB.
-
32 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Calculate and post statements
Dataset
100 stores
10,000 transactions per store
5 line items(products) per transaction
10,000 products used across all transactions
2 AOS instances
8 AOS threads per AOS instance
Results summary
Statement calculation
It took 50 minutes, 59 seconds to create statements for 100 stores, where each store had 10,000 transactions with five lines per transaction.
Resource usage
The average AOS CPU usage is 29 percent, with a maximum of 86 percent.
The memory usage on AOS is 11 GB out of 16 GB when eight AOS threads were running for each AOS instance.
The average CPU usage on the Microsoft Dynamics AX database SQL Server instance is 15 percent, with a maximum of 40 percent.
The memory usage on the Microsoft Dynamics AX database is 46 GB out of 64 GB when a total of
16 AOS threads were connected to the Microsoft Dynamics AX database. There was no cap on
SQL Server memory, so SQL Server allocates whatever memory is available and attempts to use it. This means that the usage listed here may not reflect the real usage of SQL Server.
Statement posting
Posting the statements for 100 stores, where each store had 10,000 transactions with five lines per transaction, and where 10,000 products were used across each store, took 6 hours, 30
minutes, 14 seconds.
On average, it is taking between 55 minutes and one hour to process one statement and then generate the sales order invoice with 10,000 lines.
Resource usage
The average AOS CPU usage is 58 percent, with a maximum of 100 percent.
The memory usage on AOS is 12 GB out of 16 GB when eight AOS threads were running per AOS
instance
The average CPU usage on the Microsoft Dynamics AX database SQL Server instance is 28 percent, with a maximum of 60 percent.
The memory usage on a Microsoft Dynamics AX database is 44 GB out of 64 GB when a total of 16 AOS threads were connected to the Microsoft Dynamics AX database. There was no cap on SQL Server memory, so SQL Server allocates whatever memory is available and attempts to use it. This means that the usage listed here might not reflect the real usage of SQL Server.
The Microsoft Dynamics AX database size after statement posting was 48 GB, and the store database size was 1 GB for 100,000 products and 10,000 transactions per store
-
33
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Additional end-of-day financial posting scenario and results
An additional performance test was run on the end-of-day financial posting with a different hardware configuration and using a different dataset for performance testing purposes only. The following table summarizes the test results.
Topology for this additional test only
Retail topology
role
Number of
machines for
800-store
configuration
Number of
processors
Processor
speed (GHz)
Memory
size
allocated
(GB)
Disk
capacity
(GB)
AOS 5 8 2.300 16 500
HQ/Synch Service 1 8 2.300 16 500
POS/Synch Service 1 8 2.300 16 500
Microsoft Dynamics AX
database
1 16 2.310 32 500 GB+ 4 TB
of SAN storage
Store databases,
Synch Service
databases
1 16 2.310 32 500 GB+ 4 TB
of SAN storage
Topology notes
All the preceding topology roles are running on physical machines.
The store databases and the Synch Service database are located on same physical machine.
Five store databases are created on a database server machine, and each database simulates a transaction load of 160 stores.
Five instances of Synch Service are hosted on a single physical machine.
Five instances of POS/Synch Service are hosted on a single physical machine.
This topology and the machines are in a different lab and on different hardware machines than in earlier scenarios.
Dataset
Create 1,000 retail transactions per store database for 800 stores:
An average of 1.5 line products per transaction
1,000 products used across 10,000 transactions
Anonymous customers for all transactions
Run 8 AOS threads per AOS instance.
Run the P-0001 job for all 800 stores, using trickle feed of 20 iterations.
For 800 stores, run the following three steps in batch processing mode:
Post inventory
Statement calculation
Statement posting
-
34 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
End-to-end financial posting results summary
The following table shows the results of the end-of-day financial posting for 800 stores. The end-of-day posting for each store includes a dataset of 1,000 transactions with 1.5 lines per transaction. This
dataset is used to post the inventory, calculate the statement, and then post the statements in an end-to-end process. The end-of-day financial posting took 3 hours, 58 minutes, 51 seconds to complete using 40 AOS threads concurrently. These test results provide insight into running AOS on physical machines. If you add more AOS instances, the end-of-day financial posting for 800 stores can be completed.
Financial posting step Latency
Post inventory 01:09:00
Statement calculation 00:13:51
Statement posting 02:36:00
Total 03:58:51
Resource usage
CPU usage
The average CPU usage on a Microsoft Dynamics AX database machine was between 30 and 45
percent during the batch job processing.
The average CPU usage on the AOS machines was between 12 and 41 percent during the batch job processing.
Memory usage
The memory usage on the AOS machines was no more than 50 percent.
On the Microsoft Dynamics AX database machines, no more than 28 GB was used by SQL Server, because the maximum server memory was set at 28 GB on the SQL Server machine.
-
35
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Scenario: Trickle feed to import POS transactions and post inventory
Dataset
Create 1,000 retail transactions per store database for 100 stores:
5 line items per transaction
10,000 products used across the 10,000 transactions
Anonymous customers for all transactions
Run two AOS instances.
Run eight AOS threads per AOS instance.
Run two HQ/Synch Service instances, where each Synch Service instance refers to a single AOS instance.
Run the following set of steps 10 times in a back-to-back iteration:
Run the P-0001 job for 100 stores.
Run the Post inventory batch job for 100 stores.
End-to-end trickle feed flow results summary
The following chart shows the results for the trickle feed inventory posting of 1,000 transactions and updating that inventory by using the inventory posting for 100 stores in an end-to-end process
flow. Trickle feed is the import of POS transactions into Microsoft Dynamics AX and the periodic update of inventory in Microsoft Dynamics AX throughout the day.
In this test, you will see that the latency is increasing for the P-0001 job and inventory posting as the number of data transfers, or pulls from stores to HQ, increases over time:
The P-0001 job latency increase is due to the increase in the number of records in the RetailTransactionSalesTrans table in Microsoft Dynamics AX as Synch Service bulk inserts 5,000 records per store.
The number of inventory transactions per day has a direct correlation to the latency on the Post inventory job.
-
36 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Trickle feed latency for 100 stores, with 1,000 transactions per store and five product lines per transaction,
with two Synch Service instances and two AOS instances
Resource usage
The AOS CPU usage is approximately 10 percent overall, and the HQ/Synch Service CPU usage is
approximately 40 percent during the P-0001 job execution. The CPU usage on the Microsoft Dynamics AX database SQL Server instance was approximately 35 percent during inventory posting and the P-0001 job execution.
The memory usage for Synch Service and AOS is less than 3 GB, and the memory usage for the Microsoft Dynamics AX database is 30 GB.
The maximum network throughput was 560 kbps on AOS, with an average network usage of 800 kbps
on AOS.
1 2 3 4 5 6 7 8 9 10
Post Inventory 00:13:43 00:14:04 00:15:29 00:16:34 00:16:34 00:16:54 00:17:40 00:20:17 00:20:51 00:24:13
P-0001 Job 00:06:58 00:07:20 00:07:35 00:07:46 00:07:54 00:08:05 00:08:16 00:08:28 00:08:49 00:09:05
00:00:00
00:02:53
00:05:46
00:08:38
00:11:31
00:14:24
00:17:17
00:20:10
00:23:02
00:25:55
Late
ncy
Number of iterations
Trickle feed for 100 stores with 1,000 transactions per store with two AOS instances, eight AOS threads per AOS instance,
and Synch Service
-
37
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Suggested scale-out options
Regularly archive processed transactions in Microsoft Dynamics AX from the RetailTransactionTable, RetailTransactionSalesTrans, RetailTransactionPaymentTrans, and RetailTransactionTaxTrans tables to prevent performance issues. There is no standard for archiving processed transactions, so archiving must be gauged on individual business requirements and the associated risks.
Frequently pull a smaller number of transactions throughout the day to reduce the latency of inventory posting. The overall latency will be distributed throughout the day to reduce the blockage of updates at the end of the day.
-
38 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Scenario: Add a product to a retail POS transaction
Add 1 to 10 products to a retail POS transaction.
The measurement is the average of 10 POS retail transactions, excluding the first transaction.
The first transaction after the POS startup is measured separately as Cold start 1st item add.
The POS client is connected to the store database in online mode.
The following data variation is used in the test:
100,000 products
200,000 products
500,000 products
Topology
Retail topology role Operating system SQL Server version CPU
cores
Memory
Store database (online
mode)
Microsoft Windows 2008 R2
(x64)
SQL Server Enterprise
2008 R2
2 4 GB
POS clients Microsoft Windows
Embedded POSReady 2009
and Windows 7
SQL Server Express 2008
R2
1 2 GB
Results summary
The following chart shows the results of adding a product to a POS retail transaction at different volumes of products in the store database:
The first item add (cold) that is measured after the POS client is started is the first item that was added in the first transaction. This measurement shows a higher latency compared to the first item add from the second transaction, because the POS client started on the system as a terminal in a store. This latency increases as the number of products in the store database increases.
Adding additional transactions takes less than one second per transaction. The CPU usage of the POS client is approximately 90 percent, with a maximum of 95 percent. The memory usage is 1.5 GB.
The size of the POS store database (online mode) with 500,000 customers and 500,000 products was 3 GB.
-
39
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Latency for the first item add (cold start), first item add (warm), and second, fifth, and tenth item adds in a
POS retail transaction. The measurements include different product volumes in an online POS store database.
100K 200K 500K
1st Item Add [Cold] 00:00:02.274 00:00:07.054 00:00:09.277
1st Item Add [Warm] 00:00:00.728 00:00:00.735 00:00:00.736
2nd Item Add [Warm] 00:00:00.628 00:00:00.518 00:00:00.597
5th Item Add [Warm] 00:00:00.636 00:00:00.509 00:00:00.598
10th Item Add [Warm] 00:00:00.635 00:00:00.524 00:00:00.601
00:00:00.000
00:00:01.728
00:00:03.456
00:00:05.184
00:00:06.912
00:00:08.640
00:00:10.368
Late
ncy
[h
h:m
m:s
s.0
00
]
Number of assorted products in a store
Add item to a POS retail transaction latency at different product volumes
-
40 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Scenario: POS product search
Search products by the complete product name from the Item search form. This data is stored in the online POS store database.
Products dont have discounts added to them in this test.
The measurement is an average of 10 variations, excluding the first cold measurement.
The POS client is connected to the store database in online mode.
The following variations in the volume of products in the store database are used in this test:
100,000 products
200,000 products
500,000 products
Topology
Retail topology role Operating system SQL Server version Memory/
CPU
Memory
Store database (online
mode)
Windows 2008 R2 (x64) SQL Server Enterprise
2008 R2
2 cores 4 GB
POS clients Microsoft Windows
Embedded POSReady
2009 and Windows 7
SQL Server Express 2008
R2
1 core 2 GB
-
41
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Results summary
The following chart shows that latency for the product search increases with an increase in the number of products in the store database.
When the volume of the products in the store database increases, CPU usage of the POS database and POS client will briefly swing between 50 and 70 percent during the execution and measurement of the test.
The size of the POS store database (online mode) with 500,000 customers and 500,000 products was 3 GB.
Single product search latency at different product volumes
100K Products 200K Products 500K Products
Product Search 00:00:05 00:00:08 00:00:11
00:00:00
00:00:02
00:00:03
00:00:05
00:00:07
00:00:09
00:00:10
00:00:12
Late
ncy
[h
h:m
m:s
s.0
00
]
Number of products
Product search latency for different data volumes
-
42 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Scenario: POS customer search
Search for a specific customer from the Customer search form. This data is stored and available in the online store database.
The measurement is an average of 10 variations, excluding the first cold measurement.
The POS client is connected to the store database in online mode.
Hotfix #KB2828151 is applied, because the tests were run on Microsoft Dynamics AX 2012 RC2 CU1.
This hotfix is available for customers through the usual support channels.
The following data variations are used in the test:
100,000 customers
200,000 customers
500,000 customers
Topology
Retail topology role Operating system SQL Server version CPU
cores
Memory
Store database (online
mode)
Windows 2008 R2 (x64) SQL Server Enterprise
2008 R2
2 4 GB
POS clients Microsoft Windows
Embedded POSReady 2009
and Windows 7
SQL Server Express 2008
R2
1 2 GB
-
43
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Results summary
When the customer volume increases in the store database, the CPU usage of the POS database and POS client will briefly go up between 20 and 30 percent for few seconds during the execution and measurement of the test.
There is an almost 70-percent performance improvement when the hotfix is applied, so it is recommended that customers apply this hotfix if its not already included at install time.
The size of the POS store database (online mode) for 500,000 customers and 500,000 products was 3 GB.
Single customer search latency at different customer volumes
100K Customers 200K Customers 500K Customers
Customer Search 00:00:00.950 00:00:01.480 00:00:02.128
00:00:00.000
00:00:00.432
00:00:00.864
00:00:01.296
00:00:01.728
00:00:02.160
00:00:02.592
Late
ncy
[h
h:m
m:s
s.0
00
]
Number of customers in store database
Customer search Latency for different data volumes
-
44 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Scenario: POS initial offline synchronization
No change to the default offline synchronization scopes
No change to the default settings in the application configuration
Data volume variations used during the initial offline synchronization:
100,000 products and 100,000 customers
200,000 products and 200,000 customers
500,000 products and 500,000 customers
Topology
Retail topology
role
Operating system SQL Server version CPU cores Memory
Store database (online
mode)
Windows 2008 R2 (x64) SQL Server Enterprise
2008 R2
2 4 GB
POS clients, POS offline
database, offline
synchronization service
Microsoft Windows
Embedded POSReady
2009 and Windows 7
SQL Server Express
2008 R2
1 2 GB
Overview
The offline service profile is set up with the following 15 default scopes:
Currency
Customers
Discount
Reason code information
Products, prices, and bar codes
Staff
Stores and tenders
Tax
Registers
Modes of delivery
POS transactions
Seed values
Suspended transactions
Serialized transactions
POS batch staging
Each scope will have a list of tables to move from online mode to the offline database.
The offline synchronization service runs on the POS client and is used to sync the store database to the POS offline database that is located locally on the same machine as the POS client. The offline synchronization service uses the Microsoft Sync Framework with database synchronization provider to start all scope synchronization in parallel.
-
45
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Results summary
The following chart shows a dataset of the number of records in the store tables. The synchronization latency increases slightly more than linearly. For 100,000 products and customers, it took approximately 30 minutes. For 500,000 products and customers, it took approximately 3 hours, 54 minutes.
After the offline synchronization service starts, it starts all fifteen default scopes. All the scopes are run in parallel by using the Microsoft Sync Framework with database synchronization provider. The Microsoft Sync Framework with database synchronization provider uses 25MB for MemoryDataCache
size in SyncServiceConfig.Config and has observed that offline Service bulk inserts 80 records to the offline database.
The size of the POS store database (online mode) with 500,000 customers and 500,000 products was 3 GB.
While the initial synchronization was in progress, the CPU usage was at approximately 98 to 100 percent. The memory usage was between 90 and 100 percent, and the network usage was raised to 3 GB per second. The Ethernet bandwidth for this test was 10 GB.
POS database offline synchronization latency vs. the number of different master datasets of products and
customers
100K Product,100K Customers
200K Product,200K Customers
500K Product,500K Customers
POSDB Offline Sync Latency 00:29:50.072 01:03:45.767 03:54:06.736
00:00:00.000
00:28:48.000
00:57:36.000
01:26:24.000
01:55:12.000
02:24:00.000
02:52:48.000
03:21:36.000
03:50:24.000
04:19:12.000
Off
line
PO
S d
atab
ase
syn
chro
niz
atio
n la
ten
cy
(hh
:mm
.ss)
Number of products and number of customers
POS database offline synchronization latency for variation in master dataset (products and customers)
-
46 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
The following chart shows the CPU consumption of the offline database machine for 100,000 products and customers.
CPU usage on the POS client machine during the initial offline synchronization of 100,000 products and
customers
Suggested scale-out options
Because the CPU and memory usage is 100 percent on an offline synchronization database machine, one scale-out option is to increase the memory and processor capacity of the offline database
machine.
Evaluate the offline scopes listed earlier that you want to sync, and plan out time to sync a larger
volume of data up front. For example, you can turn on the scopes for customers, products, prices, and bar codes. Sync those scopes first, and then sync the remaining scopes.
Use the server edition of SQL Server instead of SQL Server Express. For a comparison of the various editions of SQL Server, see http://msdn.microsoft.com/en-us/library/cc645993(v=SQL.110).aspx.
0
20
40
60
80
100
120
10
:28
:37
10
:29
:34
10
:30
:30
10
:31
:26
10
:32
:23
10
:33
:19
10
:34
:15
10
:35
:12
10
:36
:08
10
:37
:04
10
:38
:00
10
:38
:56
10
:39
:53
10
:40
:49
10
:41
:45
10
:42
:42
10
:43
:38
10
:44
:34
10
:45
:30
10
:46
:27
10
:47
:23
10
:48
:19
10
:49
:15
10
:50
:11
10
:51
:08
10
:52
:04
10
:53
:00
10
:53
:56
10
:54
:52
10
:55
:49
10
:56
:45
10
:57
:41
CP
U u
sage
%
Offline synchronization duration [hh:mm:ss]
CPU usage on POS client machine during initial offline synchronization [Volume: 100,000 products, 100,000
customers]
CPUUsageonOfflineSyncMachine
-
47
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Scenario: Multiple concurrent calls to the Real-time Service APIs
Dataset
The Real-time Service API gets tested as part of this scenario:
Create a customer order with two line items.
Issue a gift card.
Look up inventory.
Staff log in.
Staff log out.
Products: 100,000
Stores: 100
Terminals: 10 terminals per store
Test automation is run from two test clients, each with 50 threads that directly call Real-time Service
APIs.
Load the test dataset with a set of 50 concurrent sessions and a set of 100 concurrent sessions:
50 concurrent API tests with one Real-time Service instance and one AOS instance
100 concurrent API tests with two Real-time Service instances and two AOS instances
Topology
Retail
topology role
VM or
physical
Number of
VMs for 100-
store
configuration
Number of
processors
Memory size
allocated
(GB)
Disk capacity
(GB)
AOS VM 2 4 16 300
Microsoft
Dynamics AX
database
Physical 1 24 cores 64 2,048
Real-time
Service
VM 2 4 16 500
Test client to
load Real-time
Service
VM 2 8 32 500
-
48 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Results summary
In the following chart, there are five Real-time Service API latencies for 50 and 100 concurrent calls at any given time
For the 50 concurrent calls test, the test was run with one Real-time Service instance and one AOS instance. For the 100 concurrent calls test, two Real-time Service instances and two AOS instances were used.
For 100 concurrent API calls, the latency per Real-time Service API has increased by approximately 25 percent, even when more AOS and Real-time Service instances are added, so the load does not
linearly increase.
Real-time Service APIs latency for different concurrent loads
Resource usage
The AOS CPU usage is approximately 60 percent. The Real-time Service CPU usage is approximately 36 percent for both variations of 50 and 100 concurrent calls. The CPU usage of the Microsoft Dynamics AX database was approximately 5 percent for 50 concurrent calls and 10 percent for 100 concurrent calls.
The memory usage was below 2.2 GB for Real-time Service and below 4.25 GB for AOS.
The maximum network throughput was 8 mbps on the AOS instance, and the average network usage on AOS was 4 mbps.
CreateCustomer
OrderStaff Log In Staff log Out
InventoryLook Up
Issue GiftCard
50 Concurrent API TransactionService API Request
0:00:01.828 0:00:01.230 0:00:01.303 0:00:01.771 0:00:01.269
100 Concurrent TransactionService API Transaction Service
API Request0:00:02.418 0:00:01.678 0:00:01.744 0:00:02.534 0:00:01.730
0:00:00.000
0:00:00.432
0:00:00.864
0:00:01.296
0:00:01.728
0:00:02.160
0:00:02.592
0:00:03.024
AP
I lat
ency
(h
h:m
m:s
s.0
00
)
Transaction service APIs
Real-time Service APIs latency for different concurrent loads
-
49
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Scenario: Initial catalog publishing
End-to-end flow
Validate the catalog in Microsoft Dynamics AX.
Publish the catalog in Microsoft Dynamics AX.
Run the A-1075_OC distribution schedule job in Microsoft Dynamics AX.
Run the SharePoint/RetailPublishingJob job to perform the initial publication and synchronization for the catalog by using SharePoint.
Dataset
The catalog has 1 million non-variant products, with 8 million category attributes and 10 million channel attributes.
Each product is distributed under 256 leaf nodes of a category hierarchy.
There are 251 category trees that measure 4 wide 4 deep, and that have a total of 341 nodes.
Six hundred distinct category attributes are distributed across 256 category attribute groups.
Ten channel attribute groups are assigned to all products through the channel.
There are one to 17 category attributes, with an average of eight category attributes per product.
All products get two discounts. The first discount is a 10-percent line item discount for all products. The second discount is selected from one of the following discounts, which are distributed evenly:
Multi-buy discount with 20 percent off two products
Mix and match discounts
Promotion lines
Quantity discounts
Note: The default values in the configuration parameters for the SharePoint/RetailPublishingJob job are used.
Topology
Retail topology role VM or
physical
Number of
VMs
Number of
processors
Memory
size
allocated
(GB)
Disk
capacity
(GB)
AOS VM 1 4 16 300
HQ/Synch Service VM 1 4 16 300
Online store/Synch Service VM 1 8 32 500
Microsoft Dynamics AX
client
VM 1 2 8 300
Microsoft Dynamics AX
database
Physical 1 24 64 2,048
SharePoint database/CRT
database
Physical 1 24 64 2,048
-
50 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Retail topology role VM or
physical
Number of
VMs
Number of
processors
Memory
size
allocated
(GB)
Disk
capacity
(GB)
SharePoint application
server
Physical 1 24 64 2,048
Note: The Commerce Run-time (CRT) database and SharePoint databases are located on the same physical machine, but they are on separate physical disks to separate the disk I/O activities.
Overall results summary
The following table summarizes the results of publishing the product catalog from Microsoft Dynamics
AX to the SharePoint Retail online channel.
Publish product catalog step Latency for a product catalog of this size
500,000 products 1 million products
Validate the catalog in Microsoft Dynamics AX 00:39:50 01:15:51
Publish the catalog in Microsoft Dynamics AX 00:22:27 00:55:46
Run the A-1075_OC job from Microsoft
Dynamics AX to the CRT database
01:23:18 02:42:21
Run SharePoint/RetailPublishingJob to publish
the catalog in SharePoint
02:51:43 06:28:19
Total 05:17:18 11:22:17
Result notes
Validate the catalog in Microsoft Dynamics AX
Validate catalog in Microsoft Dynamics AX checks the validity of the catalog and also creates the catalog listing. In the preceding summary, the validation of the catalog takes 1 hour, 15 minutes. The validation creates a total of 8 million product attribute listings and 10 million product channel attribute
listings.
Publish the catalog in Microsoft Dynamics AX
The Publish catalog batch processing job creates one action with a packed query to send 1 million catalogs to the online store.
Run the A-1075_OC job from Microsoft Dynamics AX
Synch Service reads 52 million records from Microsoft Dynamics AX, resulting in 52 records per product being sent from Microsoft Dynamics AX to CRT.
Run SharePoint/RetailPublishingJob
SharePoint/RetailPublishingJob took 6 hours, 28 minutes, 19 seconds to be completed. This job uses multi-thread logic to read 52 million retail listings from the CRT database in 2 hours, 28 minutes. In addition, the job takes 3 hours, 40 minutes to create a SharePoint list for 1 million products. The
SharePoint Server Side Object Model API is used to create the list.
-
51
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Resource usage
Resource usage for AOS and HQ/Synch Service
The average CPU consumption on AOS, the Microsoft Dynamics AX database, and Synch Service was between 10 and 20 percent across all server roles.
The memory consumption was as follows:
AOS: 4 GB
HQ/Synch Service: 3 GB
Microsoft Dynamics AX database: 42 GB
Resource usage for SharePoint/catalog publishing
The average CPU usage of the SharePoint application server was approximately 60 percent. During catalog publishing, the CPU usage varied from the retrieval of the retail listing from the CRT database to the creation of the SharePoint listing.
The memory consumption on the SharePoint application server is 45 GB, with about 24 GB being used
by the publishing process itself. Consumption scales up linearly over several hours and then stays flat after the retrieval phase.
The size of the CRT database is 12 GB.
Scale-out option
Split a large catalog into smaller catalogs:
A smaller catalog takes less time to publish end-to-end.
Though all four steps (validate catalog, publish catalog in Microsoft Dynamics AX, run the A-1075_OC
job, and run SharePoint/RetailPublishingJob) need to be completed in sequence for a given catalog, the Microsoft Dynamics AX steps and the SharePoint step can be completed in parallel.
The parallel completion of steps on a smaller catalog can speed up the overall end-to-end publishing time for over 1 million products.
-
52 MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Conclusion
The information provided in this white paper can be used as a guideline to help assess the infrastructure needs for Microsoft Dynamics AX retail implementations. These performance tests were run and measured in a controlled lab environment, with no other applications running. They were specifically targeted for retail scenarios. This white paper reflects our experience working with customers, ongoing scale testing, and performance tests that are run on a regular basis, and also
scenario-specific performance tests that represent typical retail environments. Use this information as a starting point to evaluate the options for configuring topologies that simulate implementation-specific environments before making any decision to appropriately size the topologies for production use.
For example, the following baseline parameters could be considered for a typical workload for a headquarter location/store location set of scenarios:
1 headquarter location
50 store locations 10,000 POS transactions per store, with an average of five line items (products) per
transaction 100,000 products in an assortment 1 million products
This is just a representative example, and based on the preceding information, the following topology would be an option to consider, based on the test results.
Retail topology role for 50
stores
Number of service
instances
Number of
processors
RAM
AOS service 1 4 16 GB
HQ/Synch Service 1 4 8 GB
Real-time Service 1 4 8 GB
For a change in any of the previously mentioned baseline parameters, the infrastructure would change accordingly. For example, 100 stores with similar baseline dataset for each store, as mentioned earlier, would require twice the number of processors and RAM capacity, thereby doubling the
infrastructure required to deliver on the same scale. However, do no use this example as a guideline for configuring or sizing your specific implementation, because actual sizing should take into account various factors, such as the system configuration (processor, RAM, and so on), other applications that are running, the state of other Microsoft Dynamics AX modules that are configured, network bandwidth, and also the overall transaction volumes. The actual transaction mix and data composition affect sizing and hardware requirements. To determine the topology and sizing, you must perform proper validation on any combination of the preceding factors through performance and benchmark
tests that closely resemble the specific implementation characteristics.
-
53
MICROSOFT DYNAMICS AX 2012 RETAIL PERFORMANCE
Appendix
VM configuration information (VMs used for preceding te