Introduction to Programming for Performance in Microsoft ...files.clickdimensions.com/junctionsolutionscom-alrj3/documents/... · Introduction to Programming for Performance in Microsoft

Introduction to Programming for Performance in Microsoft Dynamics

WHITEPAPER

_______________________________________________________________________________________________________________________________________________________________________________________________________ ______________________

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

_______________________________________________________________________________________________________________________________________________________________________________________________________ ______________________


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

DO’S AND DON’TS ...................................................................................................................7

TOOLS FOR UNDERSTANDING PERFORMANCE ................................................................................ 12

Introduction to Programming

for Performance in Microsoft Dynamics

Whitepaper


Subject to Change

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

http://blogs.msdn.com/b/axperf/

http://msdn.microsoft.com/en-us/library/aa597597.aspx



Whitepaper


Subject to Change

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



Whitepaper


Subject to Change

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



Whitepaper


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 table become fragmented and therefore less efficient. A periodic process should be added to rebuild and reorganize indexes when they reach fragmentation thresholds.

Do’s and Don’ts

The following is a list of programming concepts that should be understood to effectively develop fast modifications:



Whitepaper


Subject to Change

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.

o Don’t: 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 Don’t: 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”



Whitepaper


Subject to Change

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.

o Don’t: 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 Don’t: Call complex processes with multiple SQL calls from the client.

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



Whitepaper


Subject to Change

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.

o Don’t: 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, 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 can’t 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 Don’t: lock records for an extended period of time with large transaction

blocks

o Don’t: put any user interaction in a transaction block

o Do: limit the size of transaction blocks where possible



Whitepaper


Subject to Change

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.

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 Don’t: Train end users to search for the sales order “so-00123” by

entering “*123”.

o Do: Train 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.

o Don’t: Use in memory temporary tables with large number of records for

processing.

o Do: Use in memory temporary tables for small calculations when

appropriate.



Whitepaper


Subject to Change

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

http://archive.msdn.microsoft.com/DynamicsPerf



Whitepaper


Subject to Change

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,



Whitepaper


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:



Whitepaper


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



Whitepaper


Subject to Change

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.



Whitepaper


Subject to Change

o Read logs – Using SSMS a DBA can review the error logs for SQL as

well as the operation system hosting SQL.

o Check settings – Show the settings such as max memory and maximum

degree of parallelism that are set on the SQL Server.



Whitepaper


Subject to Change

o Review Maintenance Plans – Review the maintenance being performed

on a SQL server.

Documents

Introduction to Programming for Performance in Microsoft ...files.clickdimensions.com/junctionsolutionscom-alrj3/documents/... · Introduction to Programming for Performance in Microsoft