User Review
( votes)
Nearly four years on from the launch of Dynamics 365 Finance and Operations (D365FO), Microsoft reports a steady flow of new go-lives. But for many, the initial scope of the implementation may have omitted a key item: system performance at scale. While a new system often runs well in the early days and weeks, degradation is not uncommon as time passes, usage grows, and the architecture experiences conditions not replicated before launch.
As customers and partners have been learning, managing performance in a cloud environment like D365FO has unique challenges compared to the on-premises world of Dynamics AX. From near-monthly updates to a new customization model to the public cloud architecture, maintaining stability over time is not a given. And customers can not take for granted that their service providers will account for the time and effort required for performance tuning in a typical project beyond a minimum amount of manual testing.
But trouble is not inevitable if teams responsible for the systems make performance a long term focus, says Brandon Ahmad, a freelance architect and trainer for Dynamics 365 Finance and Operations (D365FO), Azure, and SQL. He spoke with MSDW about the challenges facing large and growing deployments and what it takes to keep them in good health.
A different kind of migration
In a cloud-based world, large-scale D365FO implementations often run into trouble because partners and customers often leave out load testing and optimization from contract details. For example, a small amount of data is often infused into an otherwise empty database. At those levels, everything could run swiftly. But performance can change dramatically when the volume increases. Ahmad explained that customers tend to start with acceptable performance but can run into issues as data and user counts grow over time:
A lot of projects have recently gone live and on average about six months to a year in they start to have issues when the size [of the database] and number of users reaches a certain threshold. You’d think it would vary some, but it’s really surprising. [At about] 55 to 65 gigabytes of size you’ll start to see problems really show up. A lot of times, if you have a coding framework, then multiple different issues need to be fixed. It’s rarely one silver bullet, but [a need to] fix ten things with performance tuning.
From his base of operations in the Dallas-Fort Worth area, Ahmad’s projects often focus on automated performance testing and tuning. He explained:
