Introduction to Programming for Performance in Microsoft Dynamics Ax
Transcript of Introduction to Programming for Performance in Microsoft Dynamics Ax
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
1/18
Introduction to Programming for Performance inMicrosoft Dynamics
WHITEPAPER
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
2/18
_____________________________________________________________________________________________________________________________________________________________________________________________________________________________
Proprietary and Confidential Page 2 of 18 2012
Subject to Change
Junction Solutions documentation 2012
All material contained in this documentation is proprietary and confidential to JunctionSolutions, Inc and subject to the nondisclosure provisions of the applicable Junction
Solutions, Inc agreement. This material is for informational purposes only. JunctionSolutions, 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, ortransmitted in any form or by any means, including, but not limited to, electronic, graphic,mechanical, photocopying, recording, or otherwise without the prior written permission ofJunction Solutions, Inc.
This documentation is subject to change without notice, and Junction Solutions, Inc doesnot 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 inwriting.
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
3/18
_____________________________________________________________________________________________________________________________________________________________________________________________________________________________
Proprietary and Confidential Page 3 of 18 2012
Subject to Change
INTRODUCTION.......................................... ................................................. ............................4
RESOURCES ...........................................................................................................................4
AREAS THAT AFFECT PERFORMANCE .............................................................................................4
SYSTEM OF RECORD.................................................................................................................5
INDEXES IN MICROSOFT DYNAMICS AX .........................................................................................6
DATABASE MAINTENANCE.........................................................................................................7
DOS AND DONTS............................................... ................................................. ...................7
TOOLS FOR UNDERSTANDING PERFORMANCE................................ ........................................... ..... 12
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
4/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 4 of 18 2012
Subject to Change
Introduction
This is the first article in a series of articles and webinars covering performance inMicrosoft Dynamics AX. The performance of an enterprise application is a key factor inhow users perceive that application. There are many things that can be done as a SQL
administrator, systems administrator, or programmer to improve the performance ofmodifications in Microsoft Dynamics AX.
Performance should be considered when designing, developing, and maintainingmodifications in Microsoft Dynamics AX. Acceptable performance levels should be setfor critical operations, and should be maintained with an understanding of the cost of thatmaintenance. If users are complaining about slow performance collect information aboutperformance issues including reproduction steps, number of records, acceptableexcitation times, current execution times, and number of times the process is performed.
Resources
There are many resources available to help understand performance in MicrosoftDynamics AX including:
Dynamics AX Performance Team Blogblog 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. Asystem will generally perform as well as its weakest component, and it is important tounderstand 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.
DiskDisks 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
http://blogs.msdn.com/b/axperf/http://blogs.msdn.com/b/axperf/http://msdn.microsoft.com/en-us/library/aa597597.aspxhttp://msdn.microsoft.com/en-us/library/aa597597.aspxhttp://msdn.microsoft.com/en-us/library/aa597597.aspxhttp://blogs.msdn.com/b/axperf/ -
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
5/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 5 of 18 2012
Subject to Change
Array of Inexpensive Disks (RAID), high speed hard drives, Solid State Drives
(SSD), and more.
RAMRandom 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 indetermining if there is enough ram to adequately serve SQL Server.
NetworkAll 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.
SettingsThere are many settings that can affect performance including:
Maximum degree of parallelism, trace flags, SQL trace, and debugging.
ProgrammingWriting 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.
SQLWhen 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 processesComplex processes take more effort to process than
simple ones. When creating a modification it is important to weigh the cost of thismodification. 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 thedatabase schema for Microsoft Dynamics AX not SQL Server. Any changes to tables inthe database schema need to originate in the AOT. The synchronization process will
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
6/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 6 of 18 2012
Subject to Change
then move these changes to SQL Server. If changes to a table such as adding an indexare 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 ofindexes 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 theleast 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 nameDragon, 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 thephone book were organized by first name and then last name, it would take less time tofind Chris but more time to find the name Chris Dragon, because there are morepeople in the phone book with the first name Chris than there are with the last name ofDragon.
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
7/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 7 of 18 2012
Subject to Change
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 tablebecome fragmented and therefore less efficient. A periodic process should be added torebuild and reorganize indexes when they reach fragmentation thresholds.
Dos and Donts
The following is a list of programming concepts that should be understood to effectivelydevelop fast modifications:
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
8/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 8 of 18 2012
Subject to Change
Find the number of a type of record
o Description: perform as much work as possible in a single SQLstatement. Reducing the number of calls to the database even if they are
more complicated improves performance.
o Dont: loop over a set of records and use a counter variable to count the
results
While select salesline where salesid == 123
{
Counter++;
}
o 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.
o Dont: perform data filters in an if after the select statement
While select salesline
{
If (salesline.salesid == 123)
o Do: perform all possible data filters in the where clause of a select
statement
While select salesline where salesid == 123
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
9/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 9 of 18 2012
Subject to Change
Nested loops
o Description: Performing a query in SQL server with a join allows SQL toprocess this request once, and for it to send more data to the AOS at one
time.
o Dont: use unnecessary nested loops
While select salestable
{
While select salesline where salestable.salesid
== salesline.salesid
o 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.
Note:
To call a process from the server move the code to a class and change the
run on property of the class to Server.
o Dont: Call complex processes with multiple SQL calls from the client.
o Do: Call complex processes with multiple SQL calls from the AOS.
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
10/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 10 of 18 2012
Subject to Change
Cursor versus set based operations
o Description: Using set based operations reduces the communicationbetween 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.
o Dont: Use while select and an insert, update, or delete statements when
making changes to large numbers of records at once when possible.
o Do: Use insert_recordset, recordinsertlist, update_recordset, anddelete_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.
o Dont: lock records for an extended period of time with large transaction
blocks
o Dont: put any user interaction in a transaction block
o Do: limit the size of transaction blocks where possible
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
11/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 11 of 18 2012
Subject to Change
Cached display methods
o Description: Display methods are called many times for a single recordas 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.
o 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.
o Dont: Train end users to search for the sales order so -00123 by
entering *123.
o 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 effectivefor 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.
o Dont: Use in memory temporary tables with large number of records for
processing.
o Do: Use in memory temporary tables for small calculations when
appropriate.
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
12/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 12 of 18 2012
Subject to Change
Tools for understanding performance
There are many tools available to understand and diagnose performance issues inMicrosoft Dynamics AX. This list will give a brief description of these tools. Moreinformation 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 Tracetraces can be setup to show the SQL statements that
are executed. This information is helpful because it includes both the SQL
http://archive.msdn.microsoft.com/DynamicsPerfhttp://archive.msdn.microsoft.com/DynamicsPerfhttp://archive.msdn.microsoft.com/DynamicsPerf -
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
13/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 13 of 18 2012
Subject to Change
statement that the database will execute, as well as the X++ call stack.
SQL Server Profilercaptures a configurable set of events from SQL server.
The events that can be captured can include useful information such as logins,
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
14/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 14 of 18 2012
Subject to Change
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:
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
15/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 15 of 18 2012
Subject to Change
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.
o Include client statisticsThis 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 theexecution time of a query.
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
16/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 16 of 18 2012
Subject to Change
o Review execution plansThe 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 requirethe 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.
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
17/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 17 of 18 2012
Subject to Change
o Read logsUsing SSMS a DBA can review the error logs for SQL as
well as the operation system hosting SQL.
o Check settingsShow the settings such as max memory and maximum
degree of parallelism that are set on the SQL Server.
-
8/12/2019 Introduction to Programming for Performance in Microsoft Dynamics Ax
18/18
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 18 of 18 2012
o Review Maintenance PlansReview the maintenance being performed
on a SQL server.