Test №3

Introduction: The Baseline MCPT Environment configuration was applied, the instance type was changed to x2gd.xlarge, the number of instances was changed to 6, and CPU=0 was set for all services.

Objective: The objective of this test is to assess the impact of using fewer, more memory-optimized instances (from m6g.2xlarge to x2gd.xlarge) on the performance of the MCPT environment. By reducing the number of instances while selecting a different instance type with a higher memory-to-vCPU ratio, this test aims to observe how the system handles workloads under these conditions and whether the overall efficiency and performance improve.

Results: This configuration led to a significant performance degradation, with performance being four times worse compared to the Baseline Test №1. The reduced number of instances in this setup was clearly insufficient to maintain the required performance levels.

Test №4

Introduction: The Baseline MCPT Environment configuration was applied, the instance type was changed to x2gd.xlarge, the number of instances was changed to 8, and CPU=0 was set for all services.

Objective: The goal of this test is to evaluate whether increasing the number of instances from 6 to 8, while maintaining the instance type as x2gd.xlarge and setting CPU=0 for all services, can mitigate the performance degradation observed in Test №3. This test aims to determine the optimal instance count needed to maintain stable performance in the MCPT environment under these conditions

Results: As a result, there was a 3x improvement in overall average duration for all workflows compared to Test №3. However, performance still lagged by more than 30% when compared to the Baseline Test №1.

Test №5

Introduction: The Baseline MCPT Environment configuration was applied, the instance type was changed to x2gd.large, the number of instances was changed to 10, and CPU=0 was set for all services.

Objective: The goal of this test is to evaluate the impact of switching to a smaller instance type, x2gd.large, with a slightly increased instance count of 10, while keeping CPU reservations at 0 for all services. This test aims to find a balance between instance size and count that could potentially optimize performance while reducing costs. We seek to observe how these changes affect the overall system performance compared to previous tests.

Results: The test resulted in a significant performance degradation, with a 7x reduction in performance compared to Baseline Test №1. The change to the x2gd.large instance type and the increased number of instances did not mitigate the performance issues, leading to a much worse overall performance compared to previous configurations in Test №4.

Test №6

Introduction: The Baseline MCPT Environment configuration was applied, the instance type was changed to r6g.xlarge, the number of instances was changed to 14 but 12 were used, and CPU=2 was set for all services.

Objective: To assess the performance and behavior of the MCPT environment with a different instance type (r6g.xlarge) and increased CPU allocation (CPU=2 for all services), while using a similar number of instances (12 out of 14). The goal is to determine the impact of these changes on overall system performance, responsiveness, and stability compared to the Baseline configuration.

Results: The  The test revealed a minor performance degradation of approximately 15-20% in the total duration of all workflows compared to the Baseline Test №1. Additionally, we observed that uneven distribution of CPU utilization across instances was unevenly distributed. Some instances experienced high CPU load, reaching loads of up to 80%, while others had significantly lower utilization, around 5%. This imbalance appears to be due to two main factors: firstly, some modules had only a few tasks concentrated on single instances, and secondly, there were instances with 15 or more tasks, while others had only 0-2 tasks.

Service CPU Utilization

Here we can see that okapi used 44000% of the unit CPU power.

Service Memory Utilization

Here we can't see any sign of memory leaks on every module. Memory shows stable trend.

Kafka metrics

DB CPU Utilization

DB CPU was 98%.

DB Connections

Max number of DB connections was 5150.

DB load

Top SQL-queries