Nginx 被放置在我们没有任何洞察力的微服务架构的前面。我们检索由http 存根状态公开的指标，并想计算平台性能的指标：我们不能在负载测试中使用延迟，因为我们想比较地理位置不同的站点。
到目前为止，我们尝试了什么：
- 计算每单位时间总请求的增量。问题：它不反映性能，所有站点处理相同的请求量（每 100 毫秒 100 个请求）
- 使用等待连接量规*
*使用此指标，我们观察到不同的行为。两个极端是：
2012服务器（E5-2620 v1，24线程）：平均每100ms有68,62个等待连接
2021 服务器（AMD EPYC 7642，96 线程）：平均每 100 毫秒 91,96 个等待连接
第一个问题。似乎应该将仪表读取为“越高越好”。为什么？该文档没有提供详细信息，但据我们所知，此处应出现等待答案的连接。或者这个量表是否仅由空闲连接组成（即已经服务的连接）？
第二个问题。在相同的负载测试中，最新服务器上接受/处理的连接指标要高得多（大约两倍）。为什么？两者都服务于由 100 个连接池发送的相同数量的请求。我们看到的是，处理的连接数量在开始时进展非常迅速，根据架构达到不同的上限，之后进展非常线性。我们无法在此图上找到对此行为的任何解释：已处理连接图
真的吗？请求的响应时间是一个指标，它实际上对应于事物对用户来说有多慢。当然，不同的地理区域可能会导致更复杂的统计分布，但它仍然有助于分析。
读写活动连接在做 I/O，做工作。等待是保持活动状态，等待客户端，在他们已经完成请求之后。
在每秒相同的请求级别下，较低的读取和写入是好的，因为这与快速服务的连接相关。可能这意味着更多的客户端等待，所以更高的等待数，但连接数是有限制的。
随着时间的推移，这两个连接的前几秒有点异常，几乎立即跳了起来。我不完全清楚为什么会发生这种情况，但也许 nginx 在测试之前运行了更长的时间，所以计数器更高。
我会忽略前几秒钟作为热身。并且可能随着时间的推移绘制每秒的请求数，因为可能更容易看到应该是直线的趋势。