This is an automated email from the ASF dual-hosted git repository.
liubao pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/servicecomb-docs.git
The following commit(s) were added to refs/heads/master by this push:
new b2c14da update metrics (#302)
b2c14da is described below
commit b2c14da4841bbd8ef7bd5bcc443a23a8f9327a96
Author: liubao68 <[email protected]>
AuthorDate: Tue Nov 28 10:41:50 2023 +0800
update metrics (#302)
---
.../zh_CN/docs/featured-topics/performance.md | 39 ++++++++++++++++++++--
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/java-chassis-reference/zh_CN/docs/featured-topics/performance.md
b/java-chassis-reference/zh_CN/docs/featured-topics/performance.md
index 4f5346b..9dac41a 100644
--- a/java-chassis-reference/zh_CN/docs/featured-topics/performance.md
+++ b/java-chassis-reference/zh_CN/docs/featured-topics/performance.md
@@ -25,9 +25,42 @@ servicecomb:
结合业务自己的日志系统，可以将性能统计日志存储到独立的日志文件，减少对业务日志查看的干扰。
+## 关键处理环节
+
+在 `RPC` 请求的处理过程中，有些处理环节非常重要，多数性能瓶颈都和这些环节有关。`Java Chassis` 核心处理环节可以简单概述为：
+
+* ***Provider流程*** : 接收请求 -> 创建 Producer Invocation -> 执行处理链 -> 执行业务逻辑 ->
执行处理链 -> 发送响应
+* ***Consumer流程*** : 创建 Producer Invocation -> 执行处理链 -> 发送请求 -> 等待响应 -> 执行处理链
+
+在`Provider流程`中，存在线程池资源，线程池竞争的时间通过 `queue` 来表示。 在
`Consumer流程`中，存在连接池资源，连接池竞争的时间通过 `connection` 来表示。 网路传输的时间在 `metrics`
里面未体现，一些性能优化问题，还需要结合平时的性能测试经验数据，来判断是否存在性能问题，比如，`Consumer流程`的`wait`表示等待响应时间，如果从`Provider`的
metrics 日志中，查询到总的处理时间为 100ms， `wait` 时间可能为 200ms， 中间的100ms时间是 metrics
统计不到的时间，这些时间通常用于网络资源的竞争，由操作系统等底层处理程序管理。
+
+需要详细了解 Java Chassis的处理环节，可以通过下载源码，查看 `InvocationStageTrace` 的各个方法被调用的情况。
通过此方法，能够快速了解 Java Chassis的代码结构和各个 metrics 环节的详细含义。
+
+## 时延波动
+
+任何处理环节的处理时间都可能存在波动，即使这个环节的处理逻辑非常简单，比如业务逻辑中只包含了一段 `a+b` 的计算，并返回结果。 在 Java
应用程序中，造成波动的因素大概有如下几种情况：
+
+* 并发请求。并发请求会竞争CPU资源，请求越多，逻辑被中断和延迟处理的概率就会增多，表现为整体处理时间变长。
+* 垃圾回收。Java 执行垃圾回收会中断处理过程，也会表现为逻辑处理变长。
+
+因此，当识别到 `metrics` 的某个非常简单的处理环节（没有IO、没有锁）的时延变长的时候，这通常是系统繁忙的一种表现，在分析性能瓶颈的过程中，
需要收集 CPU、内存使用率、TPS、垃圾回收时间等数据，来进一步判断触发性能问题的原因。
+
+## 初始化过程的时延
+
+应用程序接收的第一个请求，通常时延比较高，这是因为很多预处理过程需要在第一次请求的初始化。包括：加载服务元数据信息、初始化线程池、连接池、建立连接，以及业务逻辑的初始化数据库等操作。这些初始化操作通常都会使用锁，如果是并发请求，那么每个并发请求的处理时间都会变长。
+
+在应用程序运行过程中，也可能出现类似的初始化现象。比如系统在晚间很久没有用户使用，上班时间突然大量用户并发登录。
系统未使用期间，有些资源会被释放，比如线程池、连接池，用户会话信息等。
+
+初始化过程会影响到系统毛刺，初始化过程耗时，会影响到系统的错误率。特别是设置非常短的请求超时时间的条件下。
+
+## 其他重要环节的时延
+
+* 线程池排队(queue) :
提供者一般会通过线程池处理业务逻辑。如果线程池出现排队请求，即使排队请求很少，也意味着当前的请求频率超过了系统处理能力。首先可以查看CPU使用率，如果使用率高，这种情况就只能优化指令，或者提升处理能力；如果CPU使用率低，可以结合堆栈信息，进一步分析导致排队的具体逻辑是等待IO还是由于锁、资源竞争导致的。
+* 获取连接池(connection): 建立连接和连接池竞争是 `RPC` 常见的性能瓶颈。 建立连接是比较耗时的操作，以 `HTTP` 为例，
建立一次连接通常需要 `100ms` 左右的时间，服务端通常只能处理数百的并发连接。 如果并发过大，就会导致连接超时。
涉及连接耗时的情况，需要通过连接池设置，分析适合运行环境需要的最大连接数，进行合理的连接规划。
+
## 性能问题分析
-性能问题一般以超时的方式表现出来，当出现性能问题的时候，建议收集如下日志：
+综合上面的一些场景，可以发下性能问题分析不是简单的看某条耗时数据就可以进行准确的分析，这些数据通常只是给一个指示，用于判断性能分析的基本方向，然后结合方向，收集更多的信息去印证。
性能问题一般以超时的方式表现出来，当出现性能问题的时候，建议收集如下日志：
1. consumer调用出错日志（如果有的话，比如超时）；
2. provider调用出错日志（如果有的话，比如丢弃请求）；
@@ -35,9 +68,9 @@ servicecomb:
4. provider对应时间段的metrics日志，包括周期统计数据和慢调用日志；
通常结合上面的日志，就能够初步识别出性能瓶颈的位置了。metrics日志重点反映的是Java Chassis各个处理环节的耗时，
-对于线程排队的场景，需要进一步识别业务的性能瓶颈。
+对于线程排队的场景，需要进一步识别业务的性能瓶颈：
-1. 通过jstack采集堆栈信息。这个通常比较难于收集，需要在出现性能缓慢的时刻，抓取。建议每隔几秒钟，连续抓取3个以上堆栈，用于分析。
+1. 通过 `jstack` 采集堆栈信息。这个通常比较难于收集，需要在出现性能缓慢的时刻，抓取。建议每隔几秒钟，连续抓取3个以上堆栈，用于分析。
2. 对于涉及内存管理和垃圾回收的问题，需要收集GC的信息，和内存增长趋势。
收集性能数据是分析的第一步，理解性能数据需要熟悉Java Chassis的处理过程、线程池排队和执行原理、JVM线程堆栈和GC机制等，这里不详细
