Context and problem

Here’s the characteristics of the Architecture related to Dynamics 365 Servers :

• It’s a point-to-point integration architecture between the CRM Architecture (CRM System with multiple nodes) and external applications : point-to-point communication;

• No Messaging infrastructure connects the components and services : highly coupled;

• No local orchestration in CRM Architecture and all communication is synchronous;

• CRM Architecture does not include Caching Server; but, use of AppFabric Server as Caching Service (for external app);

• CRM Reporting Servers not in Frontend or Backend Servers;

• CRM Architecture has been scaled :

  • Vertical scaling has been done (CPU, RAM, …) : servers have been boosted

  • Horizontal scaling has been done (more node been added) : 6 nodes (4 nodes for the Frontend Services, 2 nodes for the backend Services, 2 nodes for SQL Servers including an CRM Always On Cluster)

• CRM Architecture uses Load Balancing (F5) - Round-Robin pattern is implemented.

...

• Number of applicative errors (timeoutexception, etc.) is increasing because the communication between the systems is growing : errors are related to CRM frontend and backend servers;

• CRM applicative errors impact the communication with the other servers (integration & other), getting for example timeoutexception…;

• Errors are related to performance issues;

• We know that CRM (frontend services) generate constantly dynamic variables and we absolutely need to catch them during our performance tests.

...

We need to dig into the performance issues and so, we need to measure the performance of CRM servers.

...

Solutions

Architecture Components - Our performance framework.

...

How does work our Architecture ?

...

Issues and considerations