ARM Cloud-Native Performance: Stress Testing Guide for Domestic Microservice Containerization

Core Challenges: Three Performance Transformation Difficulties

In the context of domestic substitution and cloud-native containerization convergence, performance testing faces systemic, low-level challenges. Most issues stem not from business code defects but from fundamental differences between x86 and domestic ARM hardware architectures. Table 1 compares the two architectures from a performance tuning perspective.

Differences in instruction sets, NUMA topology, and multi-core scaling mechanisms are continuously amplified in cloud-native dynamic scheduling scenarios, resulting in three core performance difficulties:

Lack of unified computing power conversion standard: Domestic Kunpeng, Phytium, and other ARM CPUs differ significantly from traditional x86 CPUs. No official unified performance conversion coefficient exists. Project resource allocation lacks scientific basis, relying only on experience, leading to either resource waste or insufficient computing power.

Non-linear multi-core scalability: Cloud-native elastic scheduling further amplifies hardware architecture differences. Domestic ARM NUMA node topology and cache coherence protocols differ greatly from x86, causing the same business code to exhibit concurrency performance fluctuations of several times under different core counts and scheduling strategies, making stable linear multi-core scaling difficult.

Frequent base software version iterations: The domestic substitution industry iterates rapidly. Domestic OS, middleware, databases, and other base components update frequently. Minor version upgrades can cause network throughput drops, query performance degradation, forcing test teams into continuous reactive re-testing.

Breakthrough: Quantitative Modeling and Tiered Stress Testing

The core value of performance testing lies in establishing a standardized measurement system, transforming subjective performance perception into quantifiable, actionable objective metrics to support resource allocation.

Strategy 1: Build Standardized Performance Baselines

Performance baselines are the core reference for computing power conversion and performance comparison. The x86 ecosystem is mature with predictable behavior; baselining there is essentially "verification" and can use multi-instance stepwise loading. ARM architecture is more sensitive to cross-NUMA penalties; baselining is "exploration"—must start from a single instance to probe the bottom, isolating cluster scheduling interference. Two test scenarios:

Single-instance low-load test: Under single concurrency, no-pressure ultra-low load, send requests to a single business scenario's independent Pod, precisely collecting TPS, response latency, CPU, memory, and other core resource metrics. This avoids cluster scheduling and multi-instance interference, obtaining baseline performance values in a pure environment as a unified reference for subsequent stress tests.

Single-instance extreme-load test: Fix a single Pod's CPU and memory quotas, continuously load until business throughput reaches a peak inflection point and response latency shows a step increase. Record maximum TPS/QPS and critical concurrency to precisely define the performance ceiling under a single Pod configuration.

The two tests complement each other: low-load establishes the performance baseline for normal business operation; extreme-load reveals the hardware environment's performance ceiling. Together they form the core data anchors for computing power evaluation, providing a basis for subsequent quantitative conversion and resource configuration.

Strategy 2: Implement Refined Computing Power Conversion Scheme

Based on standardized performance baselines, achieve quantitative, precise evaluation of business instance counts in two phases (as shown in Figure 1):

Phase 1: Single-transaction computing power initial assessment. Select core transaction scenarios with large traffic and high peak pressure. Using standard quota (e.g., 8C16G) single Pod extreme TPS as baseline T, and production peak max TPS as M, derive theoretical minimum Pod deployment count N = ceil(M/T). Introduce redundancy factor R based on business level considering production traffic fluctuations, node failures, cluster scheduling uncertainties. Final recommended instance count for single transaction is N × R.

Phase 2: Mixed-business computing power re-assessment. Single-transaction assessment only yields theoretical configuration. In production, multiple businesses run concurrently, contending for CPU and network bandwidth, causing natural performance decay. Therefore, build mixed-business stress test scenarios according to real production traffic ratios, deploy based on initial assessment instance counts, verify steady-state TPS, P90/P99 response latency against business SLA standards. If performance decay exceeds standards, compensate by scaling out corresponding businesses. Also simulate Pod eviction, instance abnormal exit, and other fault scenarios to verify cluster fault tolerance, dynamically optimizing redundancy factor R based on test results.

Deep Tuning: Multi-Core Scalability Analysis and Optimization

Multi-core scalability testing aims to verify application adaptation to domestic ARM multi-core architecture parallel processing capability, precisely judge computing power scaling benefits, and provide core decision basis for production horizontal and vertical scaling strategies.

Test Method: Stepwise Core Count Stress Testing

Adopt stepwise parameter adjustment, gradually increasing single Pod CPU cores (2 to 16 cores in gradient increments), continuously collecting business TPS for each core count, calculating TPS speedup ratio (TPS growth rate / core count growth rate) to determine whether system performance meets linear growth expectations and evaluate multi-core resource utilization efficiency.

Bottleneck Diagnosis: Locating Multi-Core Performance Blocking Points

If test speedup ratio is significantly below 1, performance growth cannot match core scaling magnitude, indicating parallel processing bottlenecks. In ARM environments, cross-cluster NUMA access latency is more sensitive than x86, and multi-core topology is more complex. Troubleshooting priority: scheduling affinity and cache false sharing first, then code-level lock analysis. Core issues concentrate in three categories:

Missing scheduling affinity: Pods not bound to cores cause frequent cross-NUMA node remote memory access, sharply increasing access latency. Especially in CPU-intensive transaction scenarios, if performance degrades significantly after domestic substitution, prioritize configuring core binding and NUMA affinity policies, then re-test after eliminating scheduling interference to compare performance improvement.

Cache false sharing: Struct members adjacent or array boundary elements adjacent cause frequently operated data by multiple cores to fall into the same cache line. That cache line is forced to migrate between different ARM core clusters. Inter-cluster consistency synchronization latency impacts performance more sensitively than x86, causing jitter and loss.

Severe lock contention: In high-concurrency multi-core scenarios, contention and waiting overhead of synchronization mechanisms like spinlocks may increase dramatically, blocking parallel business processing. This problem deteriorates more obviously in ARM environments with higher cross-cluster synchronization latency. In practice, use tools to capture hot locks, locate their hold time and contention frequency, then optimize high-frequency lock granularity and hold time.

Implementation Decision: Differentiated Scaling Strategies

Based on multi-core linearity test results, formulate targeted production resource scaling schemes to avoid architecture shortcomings and improve resource utilization:

Vertical scaling first: If multi-core speedup ratio approaches 1, the application efficiently utilizes multi-core computing resources. Prioritize scaling by increasing single Pod CPU cores, reducing cluster instance count, lowering scheduling and O&M management overhead.

Horizontal scaling first: If multi-core linearity is poor and speedup ratio is low, single-instance parallel processing capability has reached its limit. Prioritize distributed horizontal scaling by increasing Pod replicas, avoiding single-core and single-instance performance bottlenecks, ensuring business stability.

Continuous Governance: Building High-Frequency Change Performance Control System

Domestic base software versions iterate frequently; minor upgrades can introduce performance regression risks. This contrasts sharply with x86 systems where base software/hardware behavior is constant and performance degradation mostly stems from code changes. In domestic systems, domestic databases, OS, and other component upgrades may bring invisible internal logic "shifts"; even without business code changes, performance may plummet. The control core is preventing performance regression caused by base component upgrades. Therefore, a full-process control mechanism covering "change perception — impact assessment — baseline management" must be built, upgrading from passive re-testing to active prevention, establishing normalized quality gates.

Automated Performance Regression System

Encapsulate standardized, reusable performance regression test scripts adapting to various domestic base component change scenarios. After OS, middleware, database, and other component version upgrades, quickly trigger automated verification, collect core metrics such as TPS, response latency, resource usage, archive by "component + version + test time" dimension, achieving change traceability and performance comparability.

Performance Threshold Interception Mechanism

Collaborate with project R&D, O&M, and vendor teams to define clear performance fluctuation tolerance thresholds based on business SLA. If automated regression test results exceed threshold ranges, immediately trigger risk alerts, conduct root cause analysis and problem fixing; only after verification passes can they be admitted online, intercepting performance degradation issues at the source.

Layered Baseline Iteration Management

Establish differentiated baseline update rules. Routine minor version iterations use the previous stable version's test results as comparison baseline for incremental performance verification. Quarterly and annual major version upgrades use milestone stable baselines as ultimate reference, long-term tracking system performance evolution trends, preventing cumulative minor performance degradations from causing overall performance decay.

Conclusion

The deep integration of domestic substitution and cloud-native containerization is an inevitable trend for core system architecture upgrades in key industries, placing higher demands on traditional performance testing. In the domestic substitution process, the performance testing team's value has upgraded from single defect troubleshooting to core roles in system performance measurement, architecture decision support, and quality risk control.

Relying on the full set of practical solutions—quantitative modeling, tiered stress testing, specialized tuning, continuous governance—can effectively solve computing power assessment, multi-core scaling, and version iteration performance difficulties in ARM architecture containerization scenarios, transforming uncontrollable architecture difference risks into standardized, controllable engineering problems. The practical strategies summarized in this article provide reusable reference experience for industry domestic substitution projects, helping domestic software and hardware ecosystems upgrade from basic "usable" to efficient "user-friendly".