Microsoft Dynamics Ax 2012 Retail Performance

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


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


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


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


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


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.


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


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).


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


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.


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


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.


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


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

%


CPU usage for Publish assortment for 100,000 products


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


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.


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)


Create actions batch latency for 100,000 assorted products vs. the number of stores

19


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

%


CPU usage on AOS and Microsoft Dynamics AX database [Create actions running for 100,000 assorted products]


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)


HQ/Synch Service latency for 100,000 products vs. the number of stores

21


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]


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


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.



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.


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 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.


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


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]


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


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


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)


Synch Service latency vs. the number of stores [P-0001 job]

29


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]


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.


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


Inventory posting for end-of-day sales

Dataset

100 stores

10,000 transactions per store


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.


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


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


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


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 posting


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


Scenario: Trickle feed to import POS transactions and post inventory

Dataset

Create 1,000 retail transactions per store database for 100 stores:


10,000 products used across the 10,000 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.


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



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.


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


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


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 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


mode)

Windows 2008 R2 (x64) SQL Server Enterprise

2008 R2

2 cores 4 GB


Embedded POSReady

2009 and Windows 7


R2

1 core 2 GB

41


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.


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


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.


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


mode)


2008 R2

2 4 GB


Embedded POSReady 2009

and Windows 7


R2

1 2 GB

43


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


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



Topology

Retail topology

role

Operating system SQL Server version CPU cores Memory


mode)


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


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.


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



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)


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


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


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


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


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


client

VM 1 2 8 300


database

Physical 1 24 64 2,048

SharePoint database/CRT

database

Physical 1 24 64 2,048


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


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.


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


Appendix

VM configuration information (VMs used for preceding te

Documents

Microsoft Dynamics Ax 2012 Retail Performance