Once Dynamics AX is operational with the appropriate setup and customizations, it is beneficial to optimize its performance. Performance can be tweaked either by upgrading hardware or by tweaking software to utilize its resources efficiently. Furthermore, you can scale-up or scale-out hardware or software as described in the section Phases of a Dynamics AX Implementation of Chapter 1, System Planning and Hardware Sizing. For example, to increase performance at the hardware level, you can add additional memory or processors to an AOS server. Or, you can increase performance at the software level by adding an additional AOS instance. Additionally, you can make tweaks within the operating system to improve performance. For example, increasing the processing priority level of the AOS service process may also increase the AOS performance.
Since Dynamics AX is extremely flexible, there is not a single setup for all deployment scenarios. It is also a very efficient and stable system due to its code base, which has matured over the years. However, with the addition of customizations, third-party modules or an increase in capacity levels, performance may degrade. Typically, a developer can tweak code or an administrator can tweak settings in the AOS, database, or extended server components. In some cases, simple modifications can alleviate large headaches in the future. Fortunately, there are tools available to ease this process.
In this chapter, we will cover the specific configuration settings that can be done on both the client and server components as well as go over various methods, tweaks, techniques, and tools that all assist you in tuning your setup to perform at its optimal level. Performance may also vary along different hardware configurations and no matter how many software configuration setting tweaks are made in Dynamics AX or the database; network and hardware will still be a limitation. Henceforth, also consider possible hardware or network limitations.
In this chapter, we will specifically look at the following:
Accessing the Application Object Server (AOS) configuration
Tuning an AOS for best performance
Accessing the client configuration
By default, the setup program performs all the labor necessary to get a fully functional Application Object Server (AOS) up and running. However, to actually provide specific parameters, configuration settings, or simply modifications for an AOS, this must be done in the Microsoft Dynamics AX 2009 Server Configuration application, which is automatically installed when you install an AOS. If you installed more than one AOS, as is the case in typically all implementations, one server configuration application is used for all AOSes. To access the server configuration application, follow these steps:
To run the Microsoft Dynamics AX 2009 Server Configuration application, simply go to Start | Administrative Tools | Microsoft Dynamics AX 2009 Server Configuration. Otherwise, access it by going to Start | Control Panel | Administrative Tools | Microsoft Dynamics AX 2009 Server Configuration.
Select the AOS that you want to modify the settings for from the Application Object Server Instance drop-down. As you may have noticed, you cannot make any modifications to the configuration settings for any AOS.
Once you have selected the AOS, you would like to make configuration modifications on, click on the Manage button and then click on the Create configuration... menu item to create a configuration for the selected AOS.
After clicking on the menu item, you will be prompted to provide a name for the configuration. Name it based on what the configuration settings will be for. For example, if you want to provide debugging tweaks, a good name for the configuration would be "Development". If you want to make a high-performance setup for a Production AOS, a good name would be "Production". If you wanted to speed the process of creating additional configuration files, you may base a new configuration file based on another configuration file. If that is the case, simply make sure Active configuration is selected. This will simply copy the current selected configuration file settings and duplicate them. If this is your first configuration file, selecting either Active configuration or Original configuration will make no difference. The Original configuration is synonymous to the default configurations, which are the default, out-of-the-box, settings.
Once you have created the configuration, you will notice that the fields are no longer read only and you can now modify the configuration settings. You should also notice that the Configuration drop-down now has the newly created configuration's name called Development.
The earlier mentioned steps provide the method for creating custom configurations for the Application Object Server (AOS). This is necessary if you want to modify any parameters or configuration settings shown throughout the rest of the chapter. This chapter provides what parameters and settings are available and recommendations of specific parameters to set for best performance.
The Application Object Server (AOS) configuration settings provide parameters to manipulate and control the AOS's performance, file locations, database location, and so forth. Any modifications performed on the settings should be approached with strict caution and should be well-tested before being set for a live, production environment.
The following table describes what each property in the Microsoft Dynamics AX 2009 Server Configuration application is for. Next to the parameter name, in parenthesis, is the command line parameter that can be used if running the server from the command line.
|
Application Object Server Tab | |
|---|---|
|
Application file location (-directory=<spath>) |
The location where all the Application Files and Label files are located. This should not have to be modified by default because the installation program automatically sets the Application File location. |
|
Alternate bin directory (-bindir=<path>) |
The directory where the AOS server can access kernel text data ( |
|
Application instance (-application=<applicationname>) |
The name of the Application instance to run as. This list is generated based on the file location specified for the Application File Directory setting above. |
|
Configuration command to run at kernel start up |
The command line parameters settings that can be used to run the AOS. |
|
TCP/IP port (-port=<portnumber>) |
The port in which the AOS will listen on, for clients to connect. The default is 2712 and each AOS that is installed thereafter will increment by one from this number. |
|
Allow clients to connect to printers on the server (-exposeserverprinters) |
This option allows clients to access the printers that the AOS server has access to. |
|
Enable breakpoints to debug X++ code running on the server (-xppdebug=<0,1>) |
For an AOS that a developer will be developing on, enable this option, so that a developer can set break points in X++ code for debugging purposes. |
|
Enable global breakpoints to debug X++ code running in batch jobs |
For an AOS that a developer will be developing on, enable this option, so that a developer can set break points in X++ code in batch jobs for debugging purposes. |
|
For all AOS instances running on this computer, automatically send reports about fatal errors to Microsoft. |
A global option, when marked, it will provide feedback on fatal errors that are sent through the Internet directly to Microsoft, so that they can assess the error and come up with fixes to prevent the error in the near future more quickly. |
|
Database Connection Tab | |
|---|---|
|
Microsoft SQL Server (-database=<databasename>) |
If using a Microsoft SQL Server database, you will be able to select the server and named instance from the drop-down and then select the database name. By default, when installing the database from the installation wizard, the database is automatically associated with the AOS. |
|
Oracle |
If using an Oracle database, simply select this option. For more information on the Oracle parameters, please consult the Oracle database documentation (http://www.oracle.com/technology/documentation/index.html). |
|
Database Tuning Tab | |
|---|---|
|
Maximum open cursors (-opencursors=<number>) |
The default value is 90. This parameter specifies the maximum number of database cursors to keep open, which will also be reused. |
|
Maximum buffer size (-sqlbuffer=<number>) |
The maximum size of the buffer of data that is received from a SQL query. The larger the buffer, the more data that can be received at one time. The default value is 24. If errors occur when Dynamics AX attempts to query SQL or Role Center web parts fail, in some cases, increasing the buffer size may alleviate the problem. It is recommended to only increment by 2 (2,000 bytes) each until the errors go away. As the value increases, the performance between the AOS and SQL Server decreases. Therefore, be very cautious and only change when necessary. |
|
Transaction retry interval (-retry=<time>) |
The default value is 5 seconds. This parameter controls the time, a re-execution on a transaction should occur after it has experienced a deadlock. |
|
Array fetch ahead (-fetchahead=<number>) |
The default value is 100. This parameter controls the number of records that the AOS fetches at the same time. |
|
Local ODBC log file location |
The location on the local drive of the AOS server computer in which errors, warnings, or important notifications from the ODBC connection can be stored. |
|
Allow INDEX hints in queries (-hint=<0,1>) |
The option, when marked, allows queries in X++ with custom specified index hints to override the default assigned by Database Management Systems (DBMS). |
|
Number of connection retries (-newconnectionretrycount=<number>) |
The number of times to retry connecting to a database before determining a connection failure. |
|
Connection retry interval (-newconnectionretrydelayms=<time>) |
The time interval (in milliseconds) in which to retry connection attempts to the database. |
|
Limit the number of inactive connections |
This allows or disallows concurrent inactive connections to the database to remain open. |
|
Maximum number of inactive connections |
This specifies the number of concurrent inactive connections to the database that should remain open. |
|
Use literals in join queries from forms and reports (-sqlformliterals=<0, 1>) |
If enabled, the AOS will use literals instead of parameters for complex joins to increase performance. Enable this if reports or forms take a long time to query data. |
|
Use literals in complex joins from X++ (-sqlcomplexliterals=<0,1>) |
If enabled, the AOS will use literals instead of parameters in complex joins, which can increase performance. |
|
Generate |
If enabled, the AOS will automatically generate |
|
Include LTRIM in all |
When enabled, the AOS will use LTRIM on all queries to the database. The benefit of using LTRIM is that it automatically performs a table scan to ensure data consistency and integrity. However, this will cause a performance decrease. |
|
Tracing Tab | |
|---|---|
|
Log directory location |
The location where logs are stored from tracing. |
|
RPC round trips on server (-TraceEventsEnabled=1) |
The Trace Remote Procedure Call (RPC) between the server and any client. |
|
X++ method calls (-TraceEventsEnabled=100) |
This traces all calls of X++ methods on the AOS. |
|
Number of nested calls (-TraceXppMethodCallDepth=<number>) |
The default is 3. This parameter controls the depth in X++ method calls. |
|
Function calls (-TraceEventsEnabled=101) |
This traces any function call in X++ on the AOS. |
|
Start trace (-TraceStart=1) |
This activates the trace. |
|
Stop trace (-TraceStart=0) |
This deactivates the trace. |
|
SQL Statements (-TraceEventsEnabled=202) |
These trace all SQL statements that are sent to the database from the AOS. |
|
Bind variables (-TraceEventsEnabled=203) |
The Trace columns in SQL that are used as input bind variables—variables that are passed as parameters instead of literal values in SQL statements. |
|
Row fetch (-TraceEventsEnabled=204) |
This traces all rows that are returned to the AOS from SQL. |
|
Row fetch summary (-TraceEventsEnabled=205) |
This traces the time it takes for the AOS to have a result set to return from SQL and the number of records contained in that result set. This is an excellent feature for determining, which queries are causing bottlenecks. |
|
Connect and disconnect (-TraceEventsEnabled=200) |
This traces the connections and disconnections between the AOS and database. |
|
Transactions: TTSBegin, TTSCommit, TTSAbort (-TraceEventsEnabled=201) |
This traces queries in the AOS that use the TTS statements. |
|
Allow client tracing on Application Object Server instance (-TraceAllowClient) |
When enabled, this allows Microsoft Dynamics AX 2009 to control tracing information. For more information, review the Client Configuration sections in this chapter. |
|
Performance Tab | |
|---|---|
|
Minimum packet size to compress (-compressionminsize=<number>) |
The smaller the packet size chosen, the greater the performance increases. Tweak this option to specify the smallest packet size that can be compressed. Compression will increase performance in slower networks. |
|
Processor Affinity |
When the default is selected, the AOS server operating system will determine how to balance load across CPUs. Otherwise, you can manually override this and specify which CPU will process the AOS functions on. Depending on your setup, this may improve server performance. |
Although the Microsoft Dynamics AX 2009 Server configuration application provides the most common parameters in which to manipulate the functions, performance, settings, and configuration of an AOS instance, there are additional parameters that have been left out and can only be accessed through the command line or configuration file interface. The following table lists the advanced AOS parameters:
|
Advanced AOS Parameters | |
|---|---|
|
Compression disabled (-compressiondisabled) |
When present, this will disable packet compression. It is recommended that you do not disable packet compression, as it will degrade the client and server performance communication. |
|
Code Access Security level (-caslevel=<enable/disable/trace>) |
By default, this is enabled. Code Access Security (CAS) in Dynamics AX controls access to specific APIs. |
|
Maximum concurrent sessions (-MaxConcurrentUISessions=<value>) |
The minimum value is 0 and the maximum value is 65535. Using this, you can control the number of users that can access the AOS. This is useful when an AOS is load balanced. For example, each AOS in a load-balanced cluster should allow roughly 60 users. |
|
Maximum concurrent guest sessions (-MaxConcurrentGuestSessions=<value>) |
The minimum value is 0 and the maximum value is 65535. Using this, you can control the number of anonymous users that can access the AOS. |
|
Maximum concurrent web sessions (-MaxConcurrentWebSessions=<value>) |
The minimum value is 0 and the maximum value is 65535. Using this, you can control the number of Enterprise Portal users that can access the AOS. |
|
Maximum concurrent Business Connector users (-MaxConcurrentBCSessions=<value>) |
The minimum value is 0 and the maximum value is 65535. Using this, you can control the number of Business Connector users (from Snap Ins or third-party integration software) that can access the AOS. |
|
Maximum memory load (-MaxMemLoad=<value>) |
The default is 0. When modified, this parameter determines the maximum percentage of physical memory that is allocated for the AOS to utilize. |
|
Advanced Database Parameters | |
|---|---|
|
Create DSN (createdsn=<microsoftsqlserver, oracle>) |
Creates a data source in the ODBC manager in the Windows. |
|
DSN (-dsn=<portnumber>) |
Connects to a specific DSN port. |
|
ODBC or OCI mode (-dbcli=<ODBC, OCI>) |
Runs Dynamics AX in either ODBC or Oracle's OCI mode. |
|
Database server (-dbserver=<servername>) |
Specifies the database server name. |
|
Advanced Tracing Parameters | |
|---|---|
|
Trace file size (-TraceMaxFileSize= <number>) |
The default is 10MB. Specifies the maximum size a trace file can be. |
|
Trace buffer size (-TraceBufferSize= <0:64>) |
The default is 20KB. Specifies the buffer size of the trace log. Maximum possible value is 64KB. |
Now that you are able to modify the server configuration, you may be wondering which settings it would make sense to modify? In the following process, we will modify the settings appropriate for a development environment. If we continued from the previous example, we should already have a Developer configuration file created without having the necessary configuration settings. By default, debugging is not enabled.
To set up a "developer friendly" AOS make sure you have the following parameters set:
Enable breakpoints to debug X++ running on this server
Enable global breakpoints to debug X++ code running in batch jobs
Optimizing an AOS depends on what the AOS is used for. For example, an AOS that is load balanced should only allocate a certain number of resources on the server it is running on. Similarly, an AOS that is only used for the Enterprise Portal may not want to allow access to rich client users. Therefore, before taking any steps to optimize the performance of an AOS, make sure you have properly defined a role that the AOS has.
There are two ways to distribute load in a Dynamics AX environment. They are the following:
A cluster of AOSes are simply a group of AOSes. It doesn't necessarily mean that they are load balanced. However, a load-balanced cluster does indeed mean that a group of AOSes in a cluster are load balanced. The following sections will describe in more detail what a non-load-balanced cluster and a load-balanced cluster are.
Note
Don't set up an AOS for load balancing if you are using third-party software or hardware to load balance an AOS. Consult the setup documentation of the third-party software or hardware.
A non-load-balanced cluster does not have a main AOS that is dedicated to delegating client connections to the appropriate AOS. Instead, each AOS in the cluster acts independently. Each AOS has to be provided in the client configuration file for the client to connect. Based on a list of provided AOS servers in the client configuration file, the client will attempt to access each server in the order listed to find an available server. If a server's workload has reached its maximum level, then the client will simply attempt to connect to the next AOS.
Microsoft Dynamics AX provides the option to load balance two or more AOS's together. This is similar to how a web farm works for a SharePoint site. Alternatively, you may opt to use hardware or another software solution to load balance AOS access. It is recommended to have one AOS for no more than 50-60 users. In a load-balanced cluster, one AOS is a dedicated load balancer, delegating client connections to the appropriate AOS. It is not directly used either for interactive purposes or for processing application code. Once a client is connected to the load balancer AOS, it will then determine which AOS it should connect to. If an AOS goes down, the load balancer AOS will automatically re-route clients to an active and available AOS without having to make any modifications to client configurations. Also, as a company grows and more users are needed, it is as simple as installing a new AOS and connecting it to the load balancer.
Note
If a load balancer AOS goes down, clients will connect to other AOS's listed in the client configuration in a round-robin fashion. This scenario is similar to a non-load-balanced cluster.
As previously mentioned, to set up load balancing, we must set up one AOS as the load balancer. Afterwards, each additional AOS in the load-balanced cluster will automatically listen for client connection requests from the Load Balancer AOS. However, in order for an AOS to be a load balancer, it must first satisfy the following criteria:
Cannot be a Batch Server
Must be an AOS that is active
The following steps describe the process of setting up load balancing in Microsoft Dynamics AX 2009:
Open the Cluster configuration form by going to Administration | Setup | Cluster configuration.
Once in the Cluster configuration form, click on the Map AOS instances to clusters tab.
In the Map AOS instances to clusters tab, select the AOS instance in which to act as the load balancer and mark the Load Balancer field.
As you can see, setting up a load-balanced cluster in Dynamics AX is quite simple and requires very little configuration or tweaking of settings. When load tends to increase and performance degrades, adding a new AOS into a load-balanced cluster greatly improves performance and is quite simple to do. You can add as many AOS's as desired to a cluster. The process is the same for every additional AOS that is added.
To summarize, a non-load-balanced cluster requires more administrative work to update the client configuration files with the available AOS's. However, with a load-balanced cluster, the AOS that acts as the load balancer, once setup with all the available AOS's will automatically delegate clients to an AOS in a cluster with the most available resources.
Certainly, having a load-balanced cluster may seem like a desired setup to go with, as it requires less administrative maintenance. It also provides a method for consolidating specific business functions. For example, one cluster of AOS's may be specifically dedicated to batch processing. Similarly, another cluster may be dedicated to an external Enterprise Portal site that can experience a significant load of external user access while a cluster for internal users may not experience as much load. Also consider that in a load-balanced cluster, at least three AOSes are required while in a similar non-load-balanced cluster, only two are required—to provide load distribution.
When installing a development environment, which includes installing all the client, base server components, and extended components on the same system, you can simply run the client and access the AOS without modifying any settings. However, when there is more than one AOS installed, typically in every implementation, there will at least be a Development (DEV), Testing (TEST), Staging (STAGE), and Production (PROD) environment. In this instance, configuration modifications will be necessary to access each AOS. If connecting to a Load Balanced Cluster, you will only have to connect to the Load Balancer AOS. The main AOS will take care of delegating the client access between the other environments.
Not only will there be a need to have configuration modifications done to access each individual AOS but also each individual application code layer (for example, CUS). Otherwise, by default, the layer is the User layer (USR). To do all the necessary modifications as well as provide start up parameters, client performance tweaks, and so forth, it will have to be done in the Microsoft Dynamics AX 2009 Client configuration form, which is installed along with the Microsoft Dynamics AX 2009 Client.
The following steps describe an example of the process for accessing and modifying the Dynamics AX 2009 Client configuration application for creating a development configuration, so that developers can perform modifications on a designated application layer:
To run the Microsoft Dynamics AX 2009 Client configuration application, simply go to Start | Administrative Tools | Microsoft Dynamics AX 2009 Configuration. Otherwise, access it by going to Start | Control Panel | Administrative Tools | Microsoft Dynamics AX 2009 Configuration.
Select which configuration to modify. For example, if you want to modify the configuration for the rich client, select Local client in the Configuration Target drop-down. If you want to modify the Business Connector configuration, select Business Connector from the Configuration Target drop-down.
Click on Manage | Create Configuration to create a new configuration.
Now that you have created a new configuration, you can edit the parameters.
Specify the following parameters, such as the default company account to open a custom message or any additional parameters when the client starts in the General tab.
Specify the Development AOS in the Available Application Object Server instances section.
Note
When setting up a client configuration for a non-load-balanced cluster, add all the available AOS's in the Available Application Object Server instances section; otherwise, users will only connect to the AOS listed. In a load-balanced cluster setup, the load balancer AOS should be added. For additional redundancy, it would also be beneficial to have all the AOS's in the load-balanced cluster listed, so that clients will still be able to connect to Dynamics AX, even if the load balancer AOS is unavailable.
In order to access specific layers and enable debugging options, specify the desired parameters listed in the Developer tab. The succeeding section lists the available parameter settings and their purposes. Make sure you specify which layer to develop on as well as provide the appropriate license code to access the layer.
Now you should have a solid grasp of how to create custom client configurations. Client configurations, in essence, are the doorway to access Dynamics AX either as a developer or basic user. In the following section, you will be provided with details on each available parameter and its capabilities.
The following table describes the fields in each tab of the Microsoft Dynamics AX 2009 Client configuration form. As stated earlier, this form is automatically installed into the Windows Server Administrative Tools when the Dynamics AX client is installed. Typically, during an implementation, administrators will want to create several configuration files. These configuration files should provide different levels of user access.
|
General Tab | |
|---|---|
|
Log directory (-log=<path>) |
The directory in which errors, warnings, and important notifications are logged to. |
|
Company (-company=<string>) |
This specifies a company in which to connect to once logging into Dynamics AX. |
|
Command to run at application startup (-startupCmd=<command>) |
This provides commands to run when the Dynamics AX rich client starts up. |
|
Configuration command run at kernel startup (-extracmd=<command>) |
This provides additional commands for the kernel to run when it starts up. |
|
Startup message (-startupmsg=<string>) |
This displays a message that prompts the user once he/she logs into Dynamics AX. |
|
Connection Tab | |
|---|---|
|
Add (-aos2=host:port) |
This adds an AOS to connect to. Specify the AOS server name, instance (optional), and port in which the AOS instance is running on. |
|
Edit |
This edits the selected AOS connection information. |
|
Delete |
This deletes the selected AOS connection. |
|
Connect to printers on the server (-useserverprinters) |
If enabled on the connected AOS, this allows the client to access printers on the AOS server. |
|
Encrypt client to server communication (-aosencryption=<0,1>) |
This encrypts data that is sent from the client to the AOS. |
|
Developer Tab | |
|---|---|
|
Enable user breakpoints to debug code in the Business Connector (-xppdebug=<0,1>) |
When enabled, developers can debug X++ code that is accessed by the Business Connector. |
|
Enable global breakpoints to debug code running in the Business Connector or client (-globalbreakpoints) |
When enabled, developers can debug X++ code that is accessed by the Business Connector and client. |
|
Application object layer to open (-aol=<string>) |
Layer in which to access when logging in to the AOS. |
|
Developer license code (-aolcode=<string>) |
Provides the license code in which to access the layer. |
|
Confirm license code |
Confirms the provided license code. |
|
Repair Client |
Fixes rich client if its files or setup has been corrupted. |
|
Tracing Tab | |
|---|---|
|
Start trace (-TraceStart=1) |
This starts the trace. |
|
Stop trace (-TraceStart=0) |
This stops the trace. |
|
RPC round trips to server (-TraceEventsEnabled=1) |
The Trace Remote Procedures Calls (RPC) from client to the server. |
|
X++ method calls (-TraceEventsEnabled=100) |
The Trace X++ code that is invoked on the AOS. |
|
Number of nested calls (-TraceXppMethodCallDepth=<number>) |
This is the maximum depth in which to trace X++ method calls. |
|
Function calls (-TraceEventsEnabled=101) |
This traces all functions that are called on the AOS. |
|
SQL Statements (-TraceEventsEnabled=202) |
This traces SQL server statements on the AOS server. |
|
Bind variables (-TraceEventsEnabled=203) |
This traces columns that are used as bind variables. |
|
Row fetch (-TraceEventsEnabled=204) |
This traces rows that are returned from the SQL server. |
|
Row fetch summary (-TraceEventsEnabled=205) |
This traces the number of rows and time elapsed during fetching those rows from the SQL server. |
|
Connect and disconnect (-TraceEventsEnabled=200) |
This traces the connection and disconnection between the AOS and the database. |
|
Transactions: TTSBegin, TTSCommit, TTSAbort (-TraceEventsEnabled=201) |
This traces all TTS commands called by the AOS. |
|
Performance Tab |
|---|
|
Select the appropriate setting that tweaks the best cache performance setting for the client. |
Although the Microsoft Dynamics AX 2009 configuration application provides the most common parameters in which to manipulate the functions, performance, settings, and configuration of a client, and AOS instance, there are additional parameters that have been left out and can only be accessed through the command line or configuration file interface. The following table lists the advanced additional configuration parameters:
|
Advanced client parameters | |
|---|---|
|
Help directory (-helpDir=<path>) |
Specifies the directory in which help files are stored. |
|
Language (-language=<string>) |
Specifies the language. |
|
AOT import file ( aotimportfile=<File.xpo>) |
Imports an XPO file and compiles once the client starts. This is handy for quickly promoting code modifications across multiple environments. |
|
Trace file size (-TraceMaxFileSize= <number>) |
The default is 10MB. This specifies the maximum size a trace file can be. |
|
Trace buffer size (-TraceBufferSize= <0:64>) |
The default is 20KB. This specifies the buffer size of the trace log. The maximum possible value is 64KB. |
After reading this chapter, you should have a better understanding of how the AOS can be configured. Different configuration settings help to optimize an AOS for greater performance. You should also realize that optimization of the AOS is in fact based on the purpose in which the AOS is optimized for. For example, an AOS that will be used by one or more developers will need to have debugging enabled. However, having debugging enabled is not suitable for a Production AOS since, debugging hampers performance considerably.
When determining the performance for an AOS, the key is to define the role it will play. For example, a production AOS should always perform at peak performance. Therefore, it is important to take the time to ensure that the hardware, network, and AOS parameters are setup and optimized for a Production AOS to provide the best performance possible. However, the same may not be necessary for a Development and Testing environment, which may need to have debugging, logging, or tracing enabled. All three put a strain on the performance. Repetitive testing, for bench marking purposes, will help determine if a production AOS is suitable for production use. The earlier mentioned parameters for the AOS configuration, in this chapter, will be a handy reference to tweak the performance of an AOS.
In the next chapter, we will cover the process of not only the proper recommendations for backing up a Dynamics AX environment, but also how to maintain a Dynamics AX environment once it is up and running.