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
