Replacing x86 with ARM isn't finished when the system boots. This guide lays out a repeatable benchmarking method: define metrics and baselines, load-test DM8, storage, and APIs with sysbench, fio, and wrk, and judge results against acceptance thresholds — with the common ARM pitfalls to avoid.
The classic xinchuang migration mistake is verifying only "it boots and I can log in" while skipping "it performs." You find out after go-live that queries are twice as slow and CPU pegs at peak, when rollback is expensive. The fix is to build a performance baseline before migrating and write the acceptance criteria into the plan itself, so the go/no-go decision is made on numbers, not vibes. This article is the method we use internally, and it works whether you're moving one database or an entire platform.
Baselines must be captured on the old x86 environment under realistic load — not against an empty database, but using production peak QPS, P95/P99 latency, CPU, and disk IO. Cover at least three areas: database (DM8/KingbaseES), storage IO, and business APIs. Record three values per metric: average, peak, and the maximum acceptable degradation. Agree with the business side up front on something like "10% degradation allowed" — otherwise there is no basis for acceptance and every downstream argument stalls. Capture baseline data over at least one full business cycle (a month, including month-start and month-end peaks), rather than trusting an idle-hour snapshot that flatters the new hardware. A useful trick is to record not just the aggregate but the distribution — a P95 of 40ms with a P99 of 900ms is a very different system from one where both sit under 60ms, and that P99 gap is exactly what breaks under load on ARM, so capture percentiles, not just averages.
For the database, use sysbench for OLTP. DM8's MySQL compatibility mode lets sysbench's MySQL driver run mostly unchanged:
sysbench oltp_read_write --db-driver=mysql --mysql-host=127.0.0.1 --mysql-port=5236 --mysql-user=SYSDBA --mysql-password=*** --tables=8 --table-size=200000 --threads=32 --time=300 runUse fio for random read/write IOPS and bandwidth, and wrk against real read-heavy URLs to capture P99. Run every benchmark twice: once idle, once with production load on top — otherwise you get "looks great under test, collapses in production." Database runs especially need enough time (at least 300 seconds) so cache hits and checkpoints stabilize before you trust the numbers. Skip short 30-second bursts; they measure cache warm-up, not steady state.
Compare ARM results against the x86 baseline item by item, and focus on P99 rather than average — tail latency tends to be worse on ARM. Three common pitfalls: DM8/KingbaseES defaults are conservative (buffer pool, connections) and must be tuned from test results, not shipped as-is; ARM NUMA topology differs from x86, and CPU pinning can swing results by over 15%; and domestic SSD IOPS specs are often inflated, so trust fio numbers over the datasheet. Also note that DM8 is compiled differently on ARM — some complex SQL may pick different execution plans, so regression-test your core queries explicitly rather than assuming identical behavior.
Acceptance should at least require: OLTP TPS no lower than 90% of baseline, API P99 degradation under 15%, storage random-read IOPS on target, and 30 minutes of steady-state testing with no jitter or memory growth. If the database's resident memory keeps creeping during the run, that is a leak or a badly sized cache, not a benchmark artifact — investigate before signing off. Save a report for each item as the justification for replacement. A baseline built up front gives the migration confidence — and gives rollback a clear standard to fall back on if the numbers come back red. One concrete example makes the method easier to trust: on a recent DM8 move from a 2-socket x86 box to a 2-socket Kunpeng, sysbench TPS came back at 92% of baseline and API P99 at +11%, both inside our 90%/15% thresholds — but only after we raised the DM8 buffer pool and pinned the database to a single NUMA node, which took TPS from 84% to 92%. That is the pattern to expect: the first run tells you where you stand, and the tuning that follows is what gets you across the line. Document each tuning change with its before-and-after number, so the acceptance report isn't a single green light but a trail of evidence showing why the platform is fit to replace the old one.