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