为什么请求频率下降时响应时间会爆炸？

纠正：响应时间（%D）为μs而非ms！1个

这不会改变这种模式的怪异性，但这意味着它实际上没有那么多破坏性。

为什么响应时间与请求频率成反比？

当服务器不忙于处理请求时，服务器不应该更快地响应吗？

有什么建议如何使Apache“利用”较少的负载？

这种模式是周期性的。这意味着，如果展示次数每分钟降到大约200个请求以下，就会显示-这是由于深夜到清晨（由于自然的用户活动）。

这些请求是非常简单的POST，它发送少于1000个字符的JSON-此JSON已存储（附加到文本文件中）-就是这样。答复只是“-”。

图中显示的数据是使用Apache本身记录的：

LogFormat "%{%Y-%m-%d+%H:%M:%S}t %k %D %I %O" performance
CustomLog "/var/log/apache2/performance.log" performance

这是数据中心的常见行为。响应时间变慢的时间与通常所说的“批处理窗口”相对应。这是一段时间，预计用户活动较少并且可以运行批处理。在此期间也将进行备份。这些活动可能会使服务器和网络的资源紧张，从而导致性能问题，如您所见。

有一些资源可能会引起问题：

• 高CPU负载。这可能导致apache等待一个时间片来处理请求。
• 高内存使用率。这可以刷新使apache无需从磁盘读取资源即可提供资源的缓冲区。它还可能会导致apache worker的分页/交换。
• 高磁盘活动。这可能导致磁盘I / O活动与服务内容的相应延迟一起排队。
• 高网络活动。这可能会使数据包排队等待传输，增加重试次数，否则会降低服务质量。

我sar用来调查这样发出的。 atsar可用于将sar数据收集到日常数据文件中。在性能正常的白天，可以检查这些以查看系统行为，而在性能可变的情况下，则过分注意。

如果您正在监视具有munin资源利用率并对其进行图形化绘制的系统或其他系统，则可能会在此处找到一些指标。我仍然发现sar更精确。

有喜欢的工具nice，并ionice可以应用到批量处理，以尽量减少其影响。它们仅对CPU或I / O问题有效。他们不太可能解决内存或网络活动方面的问题。

将备份活动移至单独的网络并减少网络争用。可以配置某些备份软件以限制将使用的带宽。这可以解决网络争用。

根据触发批处理过程的方式，您可以限制并行运行的批处理过程的数量。实际上，这可能会提高批处理的性能，因为它们可能会遇到相同的资源争用。

如果请求发送者在提交新请求之前等待上一个请求完成，则可能在另一个方向发生这种关系。在这种情况下，由于客户端排队，流量随请求时间的增加而下降（无论出于何种原因）。

或它可能是您测量的结果-如果上图显示已完成的请求（而不是到达的请求），则速率将随着请求处理时间的增加而下降（假设有限容量：D）。

尽管@BillThor的答案可能是正确的，但似乎不太可能完全由备份进程占用低负载时间段（即，这些时间段完全匹配）。

另一种解释是简单地缓存。如果给定的脚本/数据库/最近未使用过任何内容，则可能已删除了相关的缓存数据，以便为其余操作系统释放内存。这可能是数据库上的索引，与文件有关的O / S缓冲区或其他类似内容。如果自上次查询以来已经过了一段时间，则查询将不得不重新构造该信息。在繁忙时期不会发生这种情况，因为上一次查询会很频繁。这也可以解释为什么您在忙碌期间看到低响应时间和高响应时间。

在我看来，您所看到的看起来像是一个统计问题。可能并非如此，@ BillThor的答案很可能是正确的，但出于完整性考虑，我将其发布。

响应时间图基于百分位数。对于此而言，一个800-1000个请求的样本池是一个很好的样本数，一个50-100个请求的池可能不是很多。

如果您认为慢速请求的数量不是请求数量的线性函数，以至于请求数量级的增加不会导致慢速请求数量级的增加，那么更高数量的请求将导致缩短平均请求时间。

有谎言，大谎言和统计数据。

我的假设：您有三种不同的请求类别：

1. 包含大多数请求的普通变量流，这些请求都在200-300μs内完成。
2. 小型流，每分钟大约20个请求的恒定速率（即使在晚上）。每个过程大约需要2.500μs。
3. 每分钟大约10个请求的恒定速率的微小流（即使在晚上）。每个时间都超过4.000μs。

在晚上，每分钟50个请求相应地为20 + 20 + 10。因此，现在50％百分位数的结果很大程度上取决于流2的结果。95％百分位数取决于流3的结果，因此它甚至无法显示在图形上。

白天，流2 + 3完全隐藏在95％百分位数以上。

我看得越多，就越倾向于认为数据收集存在问题。

首先，TPS确实有些不可思议。虽然总体模式看起来正常，但在晚上9点左右出现一个非常急剧的中断，然后在早上7点左右再次出现。在过渡到非高峰时间时，普通图表将更加平滑。

这表明配置文件有所更改，并且您可能有两种不同类型的客户端：

1. 仅在早上7点至晚上9点之间运行的大音量扬声器，并且
2. 另一个可能全天候工作的较小音量。

第二个提示是在18:00左右。前后大部分时间，我们都有很高的音量配置-高TPS和低延迟。但是在18:00左右，突然从800-1000 RPM下降到不足400 RPM。可能是什么原因造成的？

第三个提示是降低第5个百分点的响应时间。实际上，我更喜欢看最小响应时间（但是第5个百分位数可能更好）有两个原因：它告诉我服务时间（即响应时间减去排队），响应时间倾向于服从Weibull分布，这意味着该模式（或最常见的值）刚好高于最小值。

因此，第5个百分位的下降告诉我，该系列突然中断，即使方差和平均响应时间都大大增加了，维修时间实际上也减少了。

下一步

在此阶段，我将深入研究日志，以找出18:00低容量样本与之前和之后的高容量样本有何不同。

我会寻找：

• 地理位置上的差异（以防延迟影响了$ request_time）
• URL中的差异（应为无）
• HTTP方法（POST / GET）中的差异（应为无）
• 来自同一IP的重复请求
• 以及其他任何区别...

顺便说一句，18：00的“事件”足以证明我与数据中心的拥塞/活动无关。为做到这一点，交通拥堵将不得不导致TPS下降，这可能在18:00出现，但极不可能在晚上9点至早上7点之间连续10个小时使TPS持续平稳地下降。