更正：响应时间（%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
答案1
这是数据中心的常见行为。响应时间缓慢的时间对应于通常所说的批处理窗口。这是一段预期用户活动较少且可以运行批处理过程的时间段。备份也在此期间进行。这些活动可能会给服务器和网络资源造成压力，从而导致您看到的性能问题。
有一些资源可能会导致问题：
- CPU 负载过高。这会导致 Apache 等待一段时间来处理请求。
- 内存使用率过高。这会导致缓冲区被刷新，从而使 Apache 无需从磁盘读取资源即可提供资源。它还会导致 Apache 工作进程的分页/交换。
- 磁盘活动量大。这会导致磁盘 I/O 活动排队，从而导致内容服务延迟。
- 网络活动频繁。这会导致数据包排队等待传输，增加重试次数，并降低服务质量。
我曾经sar调查过类似问题。 atsar可以将sar数据收集到每日数据文件中。可以检查这些数据，以了解白天性能正常时系统的行为情况，以及夜间性能不稳定时系统的行为情况。
如果你正在使用系统监控系统munin或其他收集和绘制资源利用率图表的系统，你可能会在那里找到一些指标。我仍然觉得sar更精确。
有nice和等工具ionice可以应用于批处理以尽量减少其影响。它们只对 CPU 或 I/O 问题有效。它们不太可能解决内存或网络活动问题。
将备份活动移至单独的网络可以减少网络争用。某些备份软件可以配置为限制将使用的带宽。这可以解决或减少网络争用问题。
根据批处理进程的触发方式，您可以限制并行运行的批处理进程的数量。这实际上可能会提高批处理进程的性能，因为它们可能会遇到相同的资源争用。
答案2
如果请求发送者等待前一个请求完成后再提交新请求，则这种关系可能反过来发生。在这种情况下，由于客户端排队，随着请求时间的增加（无论出于何种原因），流量会下降。
或者它可能是你测量的产物——如果上图显示已完成的请求，而不是到达请求，随着请求处理时间的增加，速率将下降（假设容量有限：D）。
答案3
尽管@BillThor的回答可能是正确的，低负载期似乎不太可能完全被备份过程占用（即周期完全匹配）。
另一种解释就是简单的缓存。如果某个脚本/数据库/任何东西最近没有使用，相关的缓存数据可能已被删除，以便为操作系统的其余部分释放内存。这可能是数据库上的索引，或与文件相关的 O/S 缓冲区，或任何其他类似的东西。如果距离上次查询已经有一段时间了，查询将不得不重建此信息。在繁忙时段，这种情况不会发生，因为上次查询会很频繁。这也解释了为什么您看到响应时间很短和繁忙时段的响应时间较高。
答案4
有谎言、弥天大谎和统计数据。
我的假设：您有三类不同的请求：
- 正常变量流包含大多数请求，这些请求都在 200-300 μs 内完成。
- 小流量以每分钟约 20 个请求的恒定速率（即使在晚上）。每个请求大约需要 2.500 μs 才能完成。
- 微小流以每分钟约 10 个请求的恒定速率（即使在晚上）进行。每个请求耗时远超过 4.000 μs。
晚上，每分钟 50 个请求对应为 20+20+10。因此，50% 百分位数的结果现在强烈依赖于流 2 的结果。而 95% 百分位数依赖于流 3，因此它永远不会显示在图表上。
白天，2+3 号溪流隐藏在 95% 百分位数以上。