Introduction to Programming for Performance in Microsoft Dynamics

WHITEPAPER

_______________________________________________________________________________________________________________________________________________________________________________________________________ ______________________

Junction Solutions documentation 2012

All material contained in this documentation is proprietary and confidential to Junction Solutions, Inc and subject to the nondisclosure provisions of the applicable Junction Solutions, Inc agreement. This material is for informational purposes only. Junction Solutions, Inc is not liable for any damages in connection with the use of this information. No part of this documentation may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, including, but not limited to, electronic, graphic, mechanical, photocopying, recording, or otherwise without the prior written permission of Junction Solutions, Inc. This documentation is subject to change without notice, and Junction Solutions, Inc does not warrant that the material contained in this documentation is free of errors. Any errors found in this document should be reported to Junction Solutions, Inc in writing.

Proprietary and Confidential Subject to Change

Page 2 of 18

2012

_______________________________________________________________________________________________________________________________________________________________________________________________________ ______________________

INTRODUCTION .......................................................................................................................4 RESOURCES ...........................................................................................................................4 AREAS THAT AFFECT PERFORMANCE .............................................................................................4 SYSTEM OF RECORD .................................................................................................................5 INDEXES IN MICROSOFT D YNAMICS AX .........................................................................................6 DATABASE MAINTENANCE .........................................................................................................7 DOS AND DONTS ...................................................................................................................7 TOOLS FOR UNDERSTANDING PERFORMANCE ................................................................................ 12

Proprietary and Confidential Subject to Change

Page 3 of 18

2012

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper

Introduction
This is the first article in a series of articles and webinars covering performance in Microsoft Dynamics AX. The performance of an enterprise application is a key factor in how users perceive that application. There are many things that can be done as a SQL administrator, systems administrator, or programmer to improve the performance of modifications in Microsoft Dynamics AX. Performance should be considered when designing, developing, and maintaining modifications in Microsoft Dynamics AX. Acceptable performance levels should be set for critical operations, and should be maintained with an understanding of the cost of that maintenance. If users are complaining about slow performance collect information about performance issues including reproduction steps, number of records, acceptable excitation times, current execution times, and number of times the process is performed.

Resources
There are many resources available to help understand performance in Microsoft Dynamics AX including: Dynamics AX Performance Team Blog blog from the Microsoft team. MSDN Best Practices: Performance Optimizations - page on optimizing Dynamics AX for performance

Areas that affect performance

Performance issues can originate from many places including: disk, ram, network, memory, settings, programming, SQL, and the complexity of the process in question. A system will generally perform as well as its weakest component, and it is important to understand how these concepts work together when diagnosing a performance issues. The following list gives a brief description of these components and how they affect performance. Disk Disks provide the long term storage medium for a system, similar to a file cabinet holding all of the paper records for a company. With Microsoft Dynamics AX, the area where disks affect performance the most is on the database server holding the data files. Advanced technologies are used to increase the performance of these disks including: Storage Area Networks (SAN), Redundant
Proprietary and Confidential Subject to Change Page 4 of 18 2012

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper Array of Inexpensive Disks (RAID), high speed hard drives, Solid State Drives (SSD), and more. RAM Random Access Memory is the short term workspace for a system, similar to having files open on your desk. RAM becomes a performance issue when there is not enough of it to adequately serve the system. For most servers suffering performance issues, a simple check to see if there is some ram available is enough to identify lack of ram as a performance bottleneck. This is not the case for SQL Server.

By default SQL Server uses all of the available ram in the system to store data. Whenever a page of data is needed, SQL Server first checks to see if the requested page is in ram. If it is not in ram, it will be retrieved from disk into ram and used there. High disk utilization and low buffer cache hit ratios are a couple of examples useful in determining if there is enough ram to adequately serve SQL Server. Network All of the servers in a Microsoft Dynamics AX environment should be in the same local area network (LAN) and ideally be on the same gigabit switch. The Microsoft Dynamics AX client should perform well when it is placed on the same LAN as the Microsoft Dynamics AX servers. If the client is in a remote location (in a Wide Area Network (WAN)) a technology similar to Terminal Server should be used to access the client. Settings There are many settings that can affect performance including: Maximum degree of parallelism, trace flags, SQL trace, and debugging. Programming Writing code is like writing in English. There are many ways to communicate the same concept, and some of them are better or more efficient than others. SQL When researching performance issues many times the core of the issue is an inefficient SQL statement. A poor performing SQL statement can be tuned by rewriting the code and adding indexes. Complex processes Complex processes take more effort to process than simple ones. When creating a modification it is important to weigh the cost of this modification. When analyzing the cost, be sure to include development time, test time, code merge time in upgrade, supportability, and the performance cost of a modification.

System of Record
The Application Object Tree (AOT) in Microsoft Dynamics AX is the owner of the database schema for Microsoft Dynamics AX not SQL Server. Any changes to tables in the database schema need to originate in the AOT. The synchronization process will
Proprietary and Confidential Subject to Change Page 5 of 18 2012

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper then move these changes to SQL Server. If changes to a table such as adding an index are performed in SQL Server directly, the synchronization process will fail the next time it is run.

Indexes in Microsoft Dynamics AX

An index makes it easier to find specific data from a table. There are three main types of indexes used by Microsoft Dynamics AX: primary, clustered, and non-clustered. Primary Index : A primary index provides a unique key to each record in a table. This index is the one used for record caching in Microsoft Dynamics AX. Clustered Index : A clustered index organizes the data for a table in the order of the index. A phone book is a good example of a clustered index. The data in a phone book is first sorted by last name and then by first name. For each last and first name listed in the phone book there is a corresponding phone number and address. The data for a table can only be organized one way and therefore there can only be one clustered index. Non-Clustered Index : A non-clustered index provides a way to quickly reference data found in the clustered index or heap (table without a clustered index) using a specified set of columns. An example of a non-clustered index is the index at the back of a text book. You can look up the topic you want, and the index provides a list of page numbers which have information on that topic. For example, you could add a phone number index to a phone book so you could more quickly find an address by searching for a phone number. With this index you could look up a phone number. This would provide a last name and first name (the key columns for the clustered index). Next, you can use these to look up the address. This process involves a second look up, but is much faster than looking at every phone number in the phone book and comparing with the one you are looking for, which is the alternative and known as a table scan.

The order of the columns in an index is very important. For efficiency, an index should be organized from the most granular column (highest number of unique values) to the least granular column with each column having data in a where clause. Using the phone book example again, it is easy to find all of the people in Denver with the last name Dragon, but would be incredibly difficult to find those with the first name Chris, because the phone book is organized by last name and then first name. Also, if the phone book were organized by first name and then last name, it would take less time to find Chris but more time to find the name Chris Dragon, because there are more people in the phone book with the first name Chris than there are with the last name of Dragon.

Proprietary and Confidential Subject to Change

Page 6 of 18

2012

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper

Important:

By default Microsoft Dynamics AX adds DataAreaId as the first column in an index, and adds DataAreaId to each query from Dynamics AX. Also, if a query is being made directly against the database make sure DataAreaId is included in the where clause for each table. If DataAreaId is not included in the where clause of a query made directly against the database , indexes will not be used, table scans will be performed, and performance will suffer.

The following index best practices should be followed: Always maintain indexes in the AOT Always specify a clustered index Always specify a primary index A RecId index is a good candidate for the primary index if the clustered index is not set to unique Limit the number of columns in an index, especially if it is a clustered or primary index Indexes on integers, or enums are better than those on strings, and indexes on small strings are better than those on large strings Do not create duplicate indexes Do not create left key subset indexes. If one index is contained in the same order as the left (first columns) in another index is it not useful. For example if there is an index on the phone book on last name, and another one on last name then first name. The one containing only last name does nothing. Add an index if the speed gained by adding the index is greater than the cost of updating that index. The speed gained by adding an index needs to include both the performance improvement of the query and the number of times it is executed

Note :

NOTE: When a record is inserted or updated all indexes related to that table also need to be updated

Database Maintenance
As data is added and removed from a table the indexes associated with that table become fragmented and therefore less efficient. A periodic process should be added to rebuild and reorganize indexes when they reach fragmentation thresholds.

Dos and Donts

The following is a list of programming concepts that should be understood to effectively develop fast modifications:
Proprietary and Confidential Subject to Change Page 7 of 18 2012

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper Find the number of a type of record o Description: perform as much work as possible in a single SQL statement. Reducing the number of calls to the database even if they are more complicated improves performance. Dont: loop over a set of records and use a counter variable to count the results
While select salesline where salesid == 123 { Counter++; }

Do: use keywords including count, avg, maxof, and minof.

Select count(RecId) from salesline where salesid == 123

Location of select filters o Description: sending data between the AOS and the database is slow, and should be avoided. Performing a select which returns only the data that is needed reduces unnecessary overhead. Dont: perform data filters in an if after the select statement
While select salesline { If (salesline.salesid == 123)

Do: perform all possible data filters in the where clause of a select statement
While select salesline where salesid == 123

Proprietary and Confidential Subject to Change

Page 8 of 18

2012

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper Nested loops o Description: Performing a query in SQL server with a join allows SQL to process this request once, and for it to send more data to the AOS at one time. Dont: use unnecessary nested loops
While select salestable { While select salesline where salestable.salesid == salesline.salesid

Do: use joins where possible to loop through records

While select salesline join salestable where salestable.salesid == salesline.salesid

Location of significant SQL calls o Description: For every SQL call made on the client that request needs to be sent client to AOS to SQL to AOS to client. If that request is made from the AOS the request is sent AOS to SQL to AOS. Reducing these Remote Procedure Calls (RPC) calls can have a significant effect on performance. To call a process from the server move the code to a class and change the run on property of the class to Server.

Note :

o o

Dont: Call complex processes with multiple SQL calls from the client. Do: Call complex processes with multiple SQL calls from the AOS.

Proprietary and Confidential Subject to Change

Page 9 of 18

2012

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper Cursor versus set based operations o Description: Using set based operations reduces the communication between servers required to accomplish a task. Programming with set based operators can be more difficult than using cursor (record by record) based operations, though the performance improvement can be dramatic. Additionally, if the insert, update, or delete method are overridden insert_recordset, recordinsertlist, update_recordset, or delete_from will revert to cursor based updates. Dont: Use while select and an insert, update, or delete statements when making changes to large numbers of records at once when possible. Do: Use insert_recordset, recordinsertlist, update_recordset, and delete_from when making changes to large numbers of records at once.

Transaction blocks o Description: A transaction block groups database modifications together so that if one fails the related modifications also fail. This is a good thing that preserves data integrity. At the same time the process of holding these records so they all commit to the database at the same time locks these records so other processes cant update these records. If a significant number for records is being modified these locks can escalate to table level locks which prevent any transaction from occurring on the locked table until the transaction has committed. Transaction blocks should be big enough to preserve data integrity while being small enough to allow adequate performance of the system. Additionally no user interaction should ever be placed in a transaction block, because then other processes have to wait for a user to respond (users respond slowly) before they can access the data they need. Dont: lock records for an extended period of time with large transaction blocks Dont: put any user interaction in a transaction block Do: limit the size of transaction blocks where possible

o o

Proprietary and Confidential Subject to Change

Page 10 of 18

2012

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper Cached display methods o Description: Display methods are called many times for a single record as a user interacts with the form that display method is on. If the display method is cached, then the logic behind this display method is called only once. Do: when possible cache display methods

Filter using * o Description: Even if there is an index on the sales order id field it will not be used if the search string entered is *123. This search is similar to trying to find all of the last name Dragon in the phone book by looking at all of the last names that end in ragon. The only way to do this is to look at every last name in the phone book. Dont: Train end users to search for the sales order so-00123 by entering *123. Do: T rain end users to search for the sales order so-000123 by entering SO-000123 .

Temporary table usage o Description: In memory temporary tables are responsive and effective for small data sets. When a temporary table exceeds 128 kb the table is moved from memory to disk, and it becomes extremely slow. Microsoft Dynamics AX 2012 features a new type of temporary table TempDB which addresses this size limitation, but these tables cannot be used on a form. Dont: Use in memory temporary tables with large number of records for processing. Do: Use in memory temporary tables for small calculations when appropriate.

Proprietary and Confidential Subject to Change

Page 11 of 18

2012

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper

Tools for understanding performance

There are many tools available to understand and diagnose performance issues in Microsoft Dynamics AX. This list will give a brief description of these tools. More information will be given in later articles. PerfMon - This is a Windows tool which tracks performance information. This can either be viewed real time, or tracked over time using Data Collector Sets.

Trace Cockpit (Trace Parser) In Microsoft Dynamics AX 2009 and 2012, a trace can be taken of any process. This trace includes all of the code that executes for the period of time traced. The Trace Cockpit helps navigate the trace to find the areas of code that run slowly. Performance Analyzer The Performance Analyzer is a SQL server based tool which captures key statistics on the database on a periodic basis and stores it in a database which can be queried later. The information collected includes long running queries, tables missing indexes, improper clustered indexes, missing clustered indexes, and more. http://archive.msdn.microsoft.com/DynamicsPerf Dynamics AX SQL Trace traces can be setup to show the SQL statements that are executed. This information is helpful because it includes both the SQL
Page 12 of 18 2012

Proprietary and Confidential Subject to Change

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper statement that the database will execute, as well as the X++ call stack.

SQL Server Profiler captures a configurable set of events from SQL server. The events that can be captured can include useful information such as logins,

Proprietary and Confidential Subject to Change

Page 13 of 18

2012

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper long running queries, locks, and deadlocks.

SQL Server Database Tuning Advisor (DTA) When given a long running query DTA produces a list of indexes and updates to statistics which would improve performance. The results of DTA should not be directly implemented, but rather they can be used as a starting point for tuning a query.

SQL Server Management Studio (SSMS) SSMS is the primary tool used to interact with the database. Some of the tasks that can be performed in SSMS in regard to tuning a query include:
Page 14 of 18 2012

Proprietary and Confidential Subject to Change

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper o Run SQL statements To effectively tune a long running query, the query needs to be brought into SSMS. Any parameters which the query uses must be filled in, and accurate execution times need to be found.

Include client statistics This option produces an additional tab with the results which capture key statistics like run time in milliseconds. Capturing accurate times is critical for determining if index fixes are effective. Also, any query should be run multiple times so caching does not affect the execution time of a query.

Proprietary and Confidential Subject to Change

Page 15 of 18

2012

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper o Review execution plans The execution plan of a query is the roadmap for how SQL server will internally process a query. SSMS can provide an estimated or actual execution plan. The estimated plan does not require the query to execute before it is generated, so you can access it faster, but the actual execution plan is more accurate. Through an execution plan a DBA can determine which parts of a query are slow, which helps to determine how to fix the performance issues.

Proprietary and Confidential Subject to Change

Page 16 of 18

2012

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper o Read logs Using SSMS a DBA can review the error logs for SQL as well as the operation system hosting SQL.

Check settings Show the settings such as max memory and maximum degree of parallelism that are set on the SQL Server.

Proprietary and Confidential Subject to Change

Page 17 of 18

2012

Introduction to Programming for Performance in Microsoft Dynamics Whitepaper o Review Maintenance Plans Review the maintenance being performed on a SQL server.

Proprietary and Confidential Subject to Change

Page 18 of 18

2012