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.

Issues and problems : what do we know ?

• 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.

Question : what do we need ?

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