StarBase Blog


At StarBase, we are called in to assure Dynamics AX implementations that need to scale, and to diagnose problems causing AX to slow down in ‘live’.

Here are the top five reasons we see for why your Dynamics AX implementation might not scale for hundreds or thousands of users…
1. Custom code…
Dynamics AX is a scalable platform, and if it is used without additional custom code then it performs very well. However it is rare that a ‘Commercial-Off-The-Shelf’ ERP platform is used without customisation to specific business requirements and processes.
Custom code often introduces performance defects because while programmers may be adept at writing the new functionality required, they tend to have much less appreciation of how their code will perform and scale. A custom process involving a lookup in a newly-designed table may run quickly at 50 or 100 users but be entirely unsuitable for 1,000 users.

2. … and interfaces
Chances are your AX system isn’t standalone – it probably has many upstream and downstream connections into other line-of-business and partner systems. 
We see interfaces to other systems frequently introducing performance bottlenecks and impacting overall solution performance. 
Performance problems of this type can be very tricky to diagnose: is it AX that’s slow, the interfaced system, the interface itself, the volume of data, the network or something else?
3. Security
If you are running a large AX deployment, the standard role-based and organisational security may not give you enough control over your data, and you may look to introduce record level security to limit access. On AX this is known as XDS (extensible data security) and it is extremely powerful and flexible. However, this increased data control comes at a price, and that is a hit on performance. Because of the way XDS works, depending on your organisation, team and address book setup, it can make your system very complex and resource hungry. This will have a significant performance impact on both the transactions you are protecting and on the system as a whole.
4. Access methods
The AX rich client hates slow networks! It is very “chatty” with the Application Object Server (i.e. the middleware), and the greater the latency the bigger the performance impact. Performance may be great for your support staff if they are in the same county and even the same building as the AOS, but your worldwide deployments may not give the same response to all your users.
We have seen that where there is more than minimal latency in your network, using Remote Desktop Services (RDS) or Citrix as your access method can address this issue. But you still need to plan your deployment carefully or the resource-hunger of the AX client will affect your RDS or Citrix environment. 

5. Infrastructure
Maybe this was the obvious one to lead with. After all, if you haven’t got enough tin, how can you expect it to perform as you increase the number of users and the workload on it? With enough budget it should be an easy problem to rectify, no?
However, you won’t necessarily know whether it’s definitely a lack of infrastructure that is the issue or whether it’s one of the points above.

For systems that have already gone live, StarBase’s Performance Engineering capability rapidly works out what combination of factors is at the root of an observed performance issue. Using a range of tools and techniques, our team diagnoses the issues in detail and works with your infrastructure team, your system architects, your developers or AX Partners to resolve them. 

For implementations that have not yet gone live, we suggest performance scalability testing where the required peak loads are simulated so that potential performance issues are surfaced. Larger implementations in particular are ill-advised to go live without confirming in advance that performance and responsiveness will be as required. 

Optimal is to bring Performance Engineering into your development cycle from the outset: that way defects that will affect performance can be identified early and remedied before they are baked into the system and become much more expensive to fix.

Understanding and being able to predict where performance will fail means you can throw expertise at the problems that require expertise and hardware only at those that require hardware.

To learn more about getting the most from your Dynamics AX investment click here or call 020 8236 7010

Posted by:alan
Technical Director, StarBase
Alan has worked for StarBase since 1997. He now has responsibility for identifying and formulating new products, services and solutions; and for evangelising StarBase’s solutions to existing and prospective clients. Alan architected StarBase’s Performance Testing Methodology. In addition to this being the foundation of many successful StarBase client projects, elements have also been adopted by blue chip organisations including companies in the financial sector and leading system integration specialists.

 Leave a Reply

Your email address will not be published. Required fields are marked *

Security code Cannot read the characters? Refresh

Client Testimonials