From 24c14f922c5e2543732f402bb98c17e5d79cd8a8 Mon Sep 17 00:00:00 2001 From: Ti Chi Robot Date: Wed, 16 Oct 2024 08:44:59 +0800 Subject: [PATCH] performance-tuning-practices: fix wrong number (#19125) (#19143) --- performance-tuning-practices.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index 4e6e77272d755..1704b228e6f9d 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -413,13 +413,13 @@ The following table lists the performance of seven different scenarios. | Metrics | Scenario 1 | Scenario 2 | Scenario 3 | Scenario 4 | Scenario 5 | Scenario 6 | Scenario 7 | Comparing Scenario 5 with Scenario 2 (%) | Comparing Scenario 7 with Scenario 3 (%) | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| query duration | 479μs | 1120μs | 528μs | 426μs |690μs | 533μs | 313μs | -38% | -51% | +| query duration | 479μs | 1120μs | 528μs | 426μs |690μs | 533μs | 313μs | -38% | -41% | | QPS | 56.3k | 24.2k | 19.7k | 22.1k | 30.9k | 34.9k | 40.9k | +28% | +108% | In these scenarios, Scenario 2 is a common scenario where applications use the Query interface, and Scenario 5 is an ideal scenario where applications use the Prepared Statement interface. -- Comparing Scenario 2 with Scenario 5, you can see that by using best practices for Java application development and caching Prepared Statement objects on the client side, each SQL statement requires only one command and database interaction to hit the execution plan cache, which results in a 38% drop in query latency and a 28% increase in QPS, while the average TiDB CPU utilization drops from 936% to 577%. -- Comparing Scenario 2 with Scenario 7, you can see that with the latest TiDB optimization features such as RC Read and small table cache on top of Scenario 5, latency is reduced by 51% and QPS is increased by 108%, while the average TiDB CPU utilization drops from 936% to 478%. +- Comparing Scenario 5 with Scenario 2, you can see that by using best practices for Java application development and caching Prepared Statement objects on the client side, each SQL statement requires only one command and database interaction to hit the execution plan cache, which results in a 38% drop in query latency and a 28% increase in QPS, while the average TiDB CPU utilization drops from 936% to 577%. +- Comparing Scenario 7 with Scenario 3, you can see that with the latest TiDB optimization features such as RC Read and small table cache on top of Scenario 5, latency is reduced by 41% and QPS is increased by 108%, while the average TiDB CPU utilization drops from 936% to 478%. By comparing the performance of each scenario, we can draw the following conclusions: