Merge branch '8.5.0-lts-perftest' of https://github.com/stevenayu/docs …

…into pr/19727

tidb-cloud/v8.5-performance-highlights.md

@@ -55,10 +55,10 @@ To address this issue, TiKV introduces [In-Memory Engine (IME)](https://docs.pin
 
 The query latency decreases by 50%, and the throughput increases by 100%.
 
-| Configurations | Duration | Threads | TPS | QPS | Average latency | P95 latency |
+| Configuration | Duration (s) | Threads | TPS | QPS | Average latency (ms) | P95 latency (ms) |
 | --- |  --- |  --- |  --- |  --- |  --- |  --- |
-| Disable IME | 3600 s | 10 | 123.8 | 1498.3 | 80.76 | 207.82 |
-| Enable IME | 3600 s | 10 | 238.2 | 2881.5 | 41.99 | 78.60 |
+| Disable IME | 3600 | 10 | 123.8 | 1498.3 | 80.76 | 207.82 |
+| Enable IME | 3600 | 10 | 238.2 | 2881.5 | 41.99 | 78.60 |
 
 ## IO latency jitter
 
@@ -117,11 +117,11 @@ Large-scale transactions, such as bulk data updates, system migrations, and ETL
 
 - Memory limits: in versions earlier than TiDB v8.1.0, all transaction mutations are held in memory throughout the transaction lifecycle, which strains resources and reduces performance. For operations involving millions of rows, this could lead to excessive memory usage and, in some cases, Out of Memory (OOM) errors when resources are insufficient.
 
-- Performance slowdowns: managing large in-memory buffers relies on red-black trees, which introduces computational overhead. As buffers grew, their operations slowed down due to the *O(N log N)* complexity inherent in these data structures.
+- Performance slowdowns: managing large in-memory buffers relies on red-black trees, which introduces computational overhead. As buffers grow, their operations slow down due to the *O(N log N)* complexity inherent in these data structures.
 
 ### Solution
 
-These challenges highlighted a clear opportunity to improve scalability, reduce complexity, and enhance reliability. With the rise of modern data workloads, TiDB introduces the [Pipelined DML](https://docs.pingcap.com/tidb/stable/system-variables#tidb_dml_type-new-in-v800) feature, designed to change how large transactions are handled and improve resource utilization and overall performance.
+These challenges highlight a clear opportunity to improve scalability, reduce complexity, and enhance reliability. With the rise of modern data workloads, TiDB introduces the [Pipelined DML](https://docs.pingcap.com/tidb/stable/system-variables#tidb_dml_type-new-in-v800) feature, designed to optimize the handling of large transactions, and improve resource utilization and overall performance.
 
 ### Test environment
 
@@ -172,7 +172,7 @@ To address this issue, TiDB v8.5.0 improves the performance of merging small Reg
 #### Scaling out TiKV nodes
 
 - Cluster topology: TiDB (16 vCPU, 32 GiB) \* 1 + TiKV (16 vCPU, 32 GiB) \* 4
-- Dataset: TPC-C dataset with 20k warehouses
+- Dataset: TPC-C dataset with 20,000 warehouses
 - Workload: scaling out TiKV nodes from 4 to 7
 
 ### Test results