Maximizing CRM Efficiency: Leveraging Atlas Analytics Tier Node in MongoDB
Tekion, a hyper-growth tech company, has embarked on a mission to transform the automotive retail ecosystem globally. One factor that sets us apart is our focus on customer-centricity and speed. This approach has allowed us to develop technology solutions that make the automotive retail experience more accessible, transparent, and efficient.
As Performance Engineers at Tekion, our role is crucial in delivering an exceptional customer experience by optimizing the performance of Tekion’s cloud-native platform. Recently, we faced a significant challenge when the CPU utilization of the Tekion’s CRM Application, which was built on MongoDB, was soaring. This was negatively affecting the user experience, causing slow response times. To mitigate this issue, we employed Atlas MongoDB Analytics Node, which significantly decreased CPU utilization in our Atlas MongoDB cluster, ultimately leading to improved performance of our CRM application. In this article, we will elaborate on how we achieved this feat.
We are running our CRM application on Atlas MongoDB cluster consisting of multiple nodes. Our application is read-heavy, involves frequent reads to customer records for Report ingestion jobs. We noticed that CPU utilization on our MongoDB’s primary node was consistently high, which was causing frequent failovers and high response time. This suggests that the system was struggling to handle the workload and was potentially in need of optimization or additional resources to improve performance
We needed a solution to reduce CPU utilization and enhance performance. Report ingestion can be resource-intensive and CPU-heavy because they typically involve processing large amounts of data and performing complex calculations. When reports are ingested, the data is analysed, processed, and transformed to create meaningful insights. The more complex the data and the more calculations required to generate insights; the more CPU resources will be required. Additionally, report ingestion is typically executed in batch mode, which can place a heavy load on the CPU causing it to become overloaded and slow down.
To address this issue, we decided to implement MongoDB Analytics Node. Atlas MongoDB Analytics Tier
Atlas provides an analytics tier that allows to separate analytical workloads from operational workloads. The analytics tier allows us to run analytical queries on a separate set of servers, which can improve performance and scalability.
The analytics tier consists of two components:
1. Analytical nodes: These are dedicated servers that are optimized for analytical workloads. They are separate from the operational nodes that are used for transactional workloads.
2. Connector nodes: These are nodes that connect the analytical nodes to the operational nodes. They are responsible for moving data from the operational nodes to the analytical nodes.
Analytics workload and operational workload are two different types of workloads that refer to distinct sets of tasks and processes in an organization.
Analytics workload involves the use of data analysis and modelling techniques to gain insights and understanding of business processes, customer behaviours, market trends, and other relevant information that can help organizations make informed decisions.
Operational workload refers to the day-to-day tasks and processes that are necessary to keep an organization running smoothly. This workload includes tasks such as order processing, inventory management, customer service, and financial reporting.
MongoDB Analytics Tier can improve several metrics in our MongoDB cluster, including:
• Analytical Query Performance are optimized for analytical workloads, which means they can be executed faster on dedicated analytics nodes. • Scalability, As the amount of data in our MongoDB cluster grows, it can become more challenging to scale our database. By using analytics nodes, we can improve the scalability of our MongoDB cluster. Analytics nodes can be scaled independently of operational nodes, allowing us to add additional resources to handle large analytical workloads.
• Availability In a MongoDB cluster, operational nodes are responsible for handling both operational and analytical workloads. This can lead to increased downtime if there is a failure on one of the operational nodes. By using analytics nodes, we can improve the availability of our MongoDB cluster. Analytics nodes can be configured to automatically failover in the event of a failure, ensuring that analytical workloads continue to be processed even if an operational node goes down.
• Resource Utilization By separating analytical workloads from operational workloads, we can optimize the resource utilization of our MongoDB cluster. Operational nodes can be optimized for write-heavy workloads, while analytics nodes can be optimized for read-heavy workloads. This allows us to use our resources more efficiently and improve the overall performance of our MongoDB cluster.
After implementing Analytics Node with read model for report ingestions, we noticed a significant improvement in CPU utilization. CPU utilization on operational nodes decreased by over 40%, and the performance of the entire cluster improved. As CPU is responsible for processing requests and performing operations, including executing queries. When the CPU is heavily utilized, it can cause contention and delays in processing requests. This can lead to longer query execution times and decreased application performance. However, by reducing CPU utilization, our applications were able to achieve faster query execution times and improved overall performance.
About the Author:
This blog is written by Yashwant Raju, Performance Engineer at Tekion Corp.
