Introduction to Programming for Performance in Microsoft...
Transcript of Introduction to Programming for Performance in Microsoft...
_______________________________________________________________________________________________________________________________________________________________________________________________________ ______________________
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.
_______________________________________________________________________________________________________________________________________________________________________________________________________ ______________________
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
DO’S AND DON’TS ...................................................................................................................7
TOOLS FOR UNDERSTANDING PERFORMANCE ................................................................................ 12
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 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
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.
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
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 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”.
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 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:
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 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”
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 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.
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 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
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 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.
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 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
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 Profiler – captures a configurable set of events from SQL server.
The events that can be captured can include useful information such as logins,
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:
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 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.
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 16 of 18 2012
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.
Introduction to Programming
for Performance in Microsoft Dynamics
Whitepaper
Proprietary and Confidential Page 17 of 18 2012
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.