split into overview and guideline

performance/performance_tunine_overview.md

@@ -0,0 +1,92 @@
+---
+title:  性能优化概述
+---
+
+# TiDB 性能优化概述
+
+## 文本目标
+介绍性能优化的基本概念，比如用户响应时间、吞吐和数据库时间，以及性能优化的通用工作方法。
+
+
+## 用户响应时间和数据库时间
+### 用户响应时间
+用户响应时间是指应用系统为用户返回请求结果所花的时间。一个典型的用户请求的处理时序图如下，包含了用户和应用系统的网络延迟、应用的处理时间、应用和数据库的交互时的网络延迟和数据库的服务时间等。用户响应时间受到请求链路上所有子系统的影响，比如网络延迟和带宽，系统并发用户数和请求类型，服务器 CPU 和 IO 资源使用率等。只有知道用户响应时间的的瓶颈，才能对整个系统进行有效的优化。
+`ΔT` 时间内总的用户响应时间等于平均 TPS 乘以平均的用户响应时间乘以 `ΔT`
+```
+ΔT Total user response time = TPS × avg user reponse time × ΔT
+```
+![用户响应时间](/media/performance/performance-overview/user_response_time_cn.png)
+
+### 数据库时间
+`ΔT` 时间内数据库时间为数据库处理所有应用请求的时间总和。数据库时间可以通过多种方式求得：
+
+1. QPS 乘以 平均 query 延迟 乘以 ΔT
+2. 平均活跃会话数 乘以 ΔT
+3. 通过 TiDB 内部的 Promtheus 指标 TiDB_server_handle_query_duration_seconds_sum 求得
+
+以上三种方式对应以下三个公式：
+```
+ΔT DB Time = QPS × avg latency × ΔT
+ΔT DB Time = avg active connections × ΔT 
+ΔT DB Time = rate(TiDB_server_handle_query_duration_seconds_sum) × ΔT 
+```
+
+## 用户响应时间和系统吞吐的关系
+用户响应时间可以分成服务时间、排队时间和并发等待时间，公式如下：
+```
+User Response time = Service time + Queuing delay + Coherency deplay
+```
+
+- Service Time：完成用户请求的服务时间，通常指系统处理请求需要消耗某种资源的时间，比如数据库完成一次 SQL 请求需要消耗的 CPU 时间
+- Queuing Deplay：排队延迟指的是为了等待某种资源的服务，在队列中等待调度的时间。
+- Coherency Deplay： 并发等待延迟指的是为了访问共享资源，需要和其他并发的任务进行通信和协作的时间。
+
+系统吞吐指系统每秒完成的请求数量，用户响应时间和吞吐通常是反比倒数的关系。随着吞吐的上升，系统资源利用率上升，请求服务的排队延迟会随之上升，当资源利用率超过某个拐点，排队延迟会急剧上升。比如，对于运行 OLTP 负载的数据库系统，当 CPU 利用率超过 65% 之后，CPU 的排队调度延迟会明显上升。另一方面，因为系统的并发请求不是完全独立的，存在共享资源的协同和争用，如果不同的数据库请求可能对同样的数据有互斥的加锁操作。当资源利用率上升，排队和调度延迟上升，导致持有的共享资源无法及时释放，反过来延长了其他任务对共享资源的等待时间。
+
+## 性能优化的方法
+
+性能优化的完整流程包含以下 6 个步骤
+1. 定义优化目标
+2. 建立性能基线
+3. 定位用户响应时间的瓶颈
+4. 提出优化方案，预估每种方案的收益、风险和成本
+5. 实施优化
+6. 评估优化结果
+
+一个性能优化项目，经常需要对步骤 2 到 6 进行多次循环，才能达到优化的目标
+
+### 定义优化目标
+
+不同类型系统优化目标不同，比如对于一个金融核心的 OLTP 系统，优化目标可能是降低交易的长尾延迟；对于一个财务结算系统，优化目标可能是更充分利用硬件资源，缩短批量结算任务时间。一个好的优化目标应该是容易量化的，比如：
+
+- 好的优化目标，”业务高峰期上午 9 点到 10 点，转账交易的 p99 延迟需要小于 200 毫秒“
+- 差的优化目标，”系统太慢了没有响应，需要优化“
+
+一个清晰的优化目标有助于指导后续的性能优化工作。
+
+### 建立性能基线
+
+为了高效的进行性能优化，首先需要采集当前的性能数据建立性能基线，采集的性能数据通常包含以下内容：
+
+1. 用户响应时间的平均值和长尾值，应用系统的吞吐
+2. 数据库时间、Query 延迟和 QPS 等数据库性能数据。TiDB 的性能基线完整的存储在专门的时序数据 Prometheus 中，用户可以方便的进行历史回溯和对比
+3. 资源使用率，包含 CPU、IO 和网络等资源
+4. 配置信息，比如应用系统、数据库和操作系统的配置
+
+### 定位用户响应时间的瓶颈
+
+基于性能基线的数据，定位或者推测用户响应时间的瓶颈，因为实现中的应用程序，可能没有对用户请求的完整链路，进行完整的测量和记录，往往无法对用户响应时间进行自上而下有效的分解。与此相反的是，数据库内部对于 query 延迟和吞吐等性能指标记录非常完善，基于数据库时间，工程师可以判断用户响应时间的瓶颈是否在数据库中。
+- 如果瓶颈不在数据库中，需要借助数据库外部搜集的资源利用率，或者对应用程序进行 Profile，以确定数据库外部的瓶颈，常见场景比如应用程序或者代理服务器资源不足，应用程序存在串行点无法充分利用硬件资源等。
+- 如果瓶颈存在数据库中，工程师可以通过数据库完善的调优工具进行数据库内部性能分析和诊断，常见场景比如存在慢 SQL，应用程序使用数据库的方式不合理，数据库存在读写热点等。
+
+TiDB 用户可使用基于数据库时间的优化方法论，具体的分析诊断手册、TiDB 提供的工具和实际案例参考 [优化手册](/performance/performance_tuning_guideline.md) 和 [OLTP 负载优化案例](/performanc/real-world-tuning-case)
+
+### 提出优化方案，评估每种方案的收益、风险和成本
+
+通过性能分析确定系统瓶颈点之后，根据实际情况提出优化方案。根据 [阿姆达尔定律](https://zh.wikipedia.org/wiki/%E9%98%BF%E5%A7%86%E8%BE%BE%E5%B0%94%E5%AE%9A%E5%BE%8B), *性能优化的最大收益，取决于优化的部分在整个系统的占比*。需要根据性能数据，确认系统瓶颈和相应的占比，预估瓶颈解决或者优化之后的收益。虽然针对最大瓶颈点的优化潜在收益最大，也需要评估对应方案的风险和成本。比如资源过载的系统最直接的优化方案是扩容，但是实际中可能因为无法追加投资，因为成本太高可能无法被采纳。风险也是方案评估的重要考量，比如某个业务模块响应时间很慢，因为该模块存在一个慢 SQL，数据库新版本可以解决这个慢 SQL。但是升级数据库版本可能是一个潜在高风险的操作，版本的变更可能影响原来没有问题的模块。一个低风险的方案是不升级数据库版本，而且改写现有慢 SQL，在当前数据库版本中解决该问题。
+
+### 实施优化
+综合收益、风险和成本考量，选定一种或者多种优化进行实施，对系统的变更需要周全的准备和详细的记录。
+
+### 评估优化结果
+实施优化之后需要评估优化结果，如果结果达到优化目标，整个优化项目可以告一段落。如果达不到目标，需要重复步骤 2 到 6，直到达到优化优化目标。达到优化指标之后，可能还需要进一步做好系统的容量规划，以应对业务的增长。

performance/performance_overview.md → performance/performance_tuning_guideline.md

@@ -7,28 +7,6 @@ title: TiDB 性能分析和优化手册
 ## 目标
 对于分布式数据库 TiDB 用户来说, 数据库性能分析和优化是一件困难的事情。本文的目标是介绍基于数据库时间的系统优化方法论，使得 TiDB 用户可以从全局、自顶向下的角度看待用户响应时间和数据库时间，并进行可靠的性能分析和优化。
 
-## 用户响应时间和数据库时间
-### 用户响应时间
-用户响应时间是指应用系统为用户返回请求结果所花的时间。一个典型的用户请求的处理时序图如下，包含了用户和应用系统的网络延迟、应用的处理时间、应用和数据库的交互时的网络延迟和数据库的服务时间等。用户响应时间受到请求链路上所有子系统的影响，比如网络延迟和带宽，系统并发用户数和请求类型，服务器 CPU 和 IO 资源使用率等。只有知道用户响应时间的的瓶颈，才能对整个系统进行有效的优化。
-`ΔT` 时间内总的用户响应时间等于平均 TPS 乘以平均的用户响应时间乘以 `ΔT`
-```
-ΔT Total user response time = TPS × avg user reponse time × ΔT
-```
-![用户响应时间](/media/performance/performance-overview/user_response_time_cn.png)
-
-### 数据库时间
-`ΔT` 时间内数据库时间为数据库处理所有应用请求的时间总和。数据库时间可以通过多种方式求得：
-
-1. QPS 乘以 平均 query 延迟 乘以 ΔT
-2. 平均活跃会话数 乘以 ΔT
-3. 通过 TiDB 内部的 Promtheus 指标 TiDB_server_handle_query_duration_seconds_sum 求得
-
-以上三种方式对应以下三个公式：
-```
-ΔT DB Time = QPS × avg latency × ΔT
-ΔT DB Time = avg active connections × ΔT 
-ΔT DB Time = rate(TiDB_server_handle_query_duration_seconds_sum) × ΔT 
-```
 ## 基于数据库时间的性能优化方法论
 
 现实世界中，很少应用系统设计和实现时，能够对用户响应时间进行完整的测量，并提供用户响应时间全局视图，以方便工程师对系统进行性能分析和优化。幸运的是，TiDB 内部对 SQL 的处理路径和数据库时间进行了完善的测量和记录，方便用户定位数据库内部的性能瓶颈。即使在用户响应时间的性能数据缺失的情况下，基于 TiDB 数据库时间相关性能指标，工程师可以达到以下两个性能分析目标：
@@ -51,7 +29,7 @@ title: TiDB 性能分析和优化手册
 ```
 DB Time = Select Time + Insert Time + Update Time + Delete Time + Commit Time + ...
 DB Time = Get Token Time + Parse Time + Comiple Time + Execute Time
-Execute Time = TiDB Executor Time + KV Request Time + PD TSO Wait Time 
+Execute Time ~= TiDB Executor Time + KV Request Time + PD TSO Wait Time 
 ```
 
 ## 利用 Performance Overview 面板进行性能分析和优化
@@ -308,7 +286,7 @@ Store 线程的 Commit Log Duration 明显比 Apply Log Duration 高，并且 Ap
 ![Store](/media/performance/performance-overview/cloud_append_commit_apply.png)
 
 ## 总结
-本文介绍了用户响应时间和数据库时间的概念， 以及基于数据库时间进行系统优化的方法论。借助 TiDB Performance Overview 面板，TiDB 用户可以进行高效性能分析，确认用户响应时间的瓶颈是否在数据库中；如果数据库是整个系统的瓶颈，通过数据库时间概览和 SQL 延迟的分解， 定位数据库内部的瓶颈点，并进行针对性的优化。
+本文介绍了基于数据库时间进行系统优化的方法论。借助 TiDB Performance Overview 面板，TiDB 用户可以进行高效性能分析，确认用户响应时间的瓶颈是否在数据库中；如果数据库是整个系统的瓶颈，通过数据库时间概览和 SQL 延迟的分解， 定位数据库内部的瓶颈点，并进行针对性的优化。
 
 ## 老版本如何使用 Performance overview 面板
 Performance Overview 面板在 >= v6.0.0 版本内置。发版 <= v5.4.0 的集群，需要手工导入 [`performance_overview.json`](https://github.com/pingcap/tidb/blob/master/metrics/grafana/performance_overview.json)