Dynamics AX
  RSS Feed  LinkedIn  Twitter
Want to turn you're data into a true asset? Ready to break free from the report factory?
Ready to gain true insights that are action focused for truly data informed decisions?
Want to do all of this across mutliple companies, instances of Dynamics and your other investments?
Hillstar Business Intelligence is the answer then! (www.HillstarBI.com)

Hillstar Business Intelligence for Microsoft Dynamics AX and NAV on Mobile, Desktop, Tablet

Let us prove to you how we can take the complexity out of the schema and truly enable users to answer the needed questions to run your business! Visit Hillstar Business Solutions at: www.HillstarBI.com

Tuesday, October 25, 2005

Performance Tuning Axapta

In Axapta, there are a few things that can be used in order to tune for better performance. Before you jump right into performance tuning and tracing in Axapta itself, first you need to take a step back and review the entire picture. You see Axapta, in most cases, is an n-tier (aka: 3-tier) application. There is the Database <-> AOS (Business Logic) <-> Axapta Client (User / Presentation). These are the different major areas of Axapta. There is also two other ways to split this within these major area which are: Software and Hardware.

My approach to performance tuning and tracing is always start at the ground level, Database layer. Your database most likely is a SQL server v. 2000 (or 2k5 for the lucky ones!). Also hopefully it is running on a PC built to be ran as a Server, with at least 2 GB of RAM, and the Data and Logs seperate on different disks.

Some things that you can check here are:
- RAM: at least 2GB, I recommend 3GB with AWE turned on.
- CPU: at least 2x 2.4 GHz processors.
- Disk: Seperate Disk arrays for the OS, Data, and Logs.
*** If you can swing it, put your SQL server on a SAN with at least two clusters Win2k3 nodes, running SQL server as a Virtual Server.

Now that we have looked into the hardware, next is the software side to SQL server. One of the first things I would check is to make sure the SQL server is nothing But a SQL server. Have it be 100% dedicated to being a SQL server. Next thing I would do is run SQL profiler. Use this to indentify any queries, stored proc. that run to long, that are NON Axapta related. By addressing this first, you take some un forseen issues out of the picture. (please reference: SQL Performance Tips for further SQL performance Tips)

Next thing I would do is move on to the AOS server. Here basically the same process, make sure you have enough horse power to give to the AOS. Normally the AOS does not require much, so another big thing that will improve the AOS is making sure the server running it Only runs the AOS and nothing else. This will make sure that the only queued processing items for the CPU is AOS related.

After this, you can check the network between the AOS server, SQL server, and client machines. Between the SQL Server and AOS server a Gigabit ethernet connection would be desired. As for the Client machines LAN at least 100mb ethernet, and WAN no less than 1.54 megabits per second (T1, DSL, etc.) I think at this point a good review of what all you have tested would be recommended. Also make sure to document all your test findings, so that you can use them as bench marks for future fine tuning.

Now that we have looked at everything outside of Axapta, we can move to looking into the code, and application performance. This area there is always improvement, from making sure you have indices created, and you use them, to code profiling, and making sure unneeded database calls are not all over the place. I would recommend starting out here with a SQL trace enabled, to 1000 ms for long queries. Then run a bunch of code, and do some different steps like creating Sales Orders, etc. (note: make sure yo run every single piece of Custom code you can at this point). See if anything pops up, if not, then lower the threshold until things do. If 500 ms is where some of them pop-up I would not worry because most likely you will not get much wiggle room there. Next I would review any code that uses a lot of math, or trips back and forth from the database. Also, try to consolidate code by following true OOP protocols.

Well I hope that I have given enough tips for now when it comes to performance tuning and Axapta. There is still more that you can detail, and each one of the above has details that reach deep down into each section. If there are any sepcific questions please post them in the comments section and I will make sure to answer them on the blog!

Find a job at: www.DynamicsAXJobs.com


Anonymous Garion said...


We are facing some serious performance issues with AX and was wondering whether you would be able to help.

Our AX setup is pretty much similar to what you have described in this post:

- SQL 2005 server with 2 x Quad core processor, 4GB RAM - O/S, Database and Logs stored on separate physical RAID arrays

- AOS server with 1 x Quad core processor with 4GB RAM

- Terminal server with 1 x Quad core processor with 4GB RAM

- Gigabit connection between all servers

- 2M SHDSL WAN connection for users accessing via terminal server

- total around 50 users with a maximum of 20 at any one time

- currently running 7 instances within AX with more to be added in the next 12 months

- users of instances created earlier experienced slow processing speed as time goes by; but users of newly created instances do not experience the same problem

Would really appreciate if you could help shed some light on where the problem might lie and would be glad to provide additional information if required.

Thanks in advance

9:17 PM  
Blogger brandon said...


Please contact me through email at: info at fluidunion dot com

10:28 AM  

Post a Comment

<< Home

Copyright 2005-2011, J. Brandon George - All rights Reserved