IIS 日志需要很长时间才能显示请求条目

Question

有没有办法让 IIS 尽快将请求转储到其日志文件？

背景

我向 IIS 发出的请求与实际记录到 IIS 日志之间面临着很长的延迟。延迟范围可能在 20 秒到 60 秒之间。

一些要点：

• 一旦请求出现在日志文件中，它就会显示请求发生的实际时间，
• 请求报告的处理速度最快为 350 毫秒，
• 在 IIS 请求日志中，请求也没有“卡住”
• 请求被快速完全处理到浏览器
• 我可以注意到，在生产环境中，无论是稍忙还是根本不忙，Windows Server 2012（IIS 6.2 build 9200）
• 我的开发主机中的行为相同，不忙根本，Windows 10 (IIS 10.0.19041.1)
• 生产在亚马逊存储中（我无法说出他们使用的确切技术，我相信它源自SSD）
• 本地存储是SSD盘
• 如果我监视同一磁盘/文件系统中的文件，文件更新会立即反映到显示器上（最多，如果有的话，1秒延迟）

我尝试过的一些事情

我已经尝试过

tail -f

或继续重复

tail

命令，以及 Notepad++ 的 “查看 > 监控（tail -f）” 模式。所有文件内容同时更新，遵循有点随机但总是很长的延迟。

我找不到任何有关“日志文件缓冲区”的设置（因此 IIS 会在将日志条目“转储”到文件之前填充日志条目的缓冲区）。

底线

这正常吗？每个处理 IIS 日志的人都需要花时间检查日志中的请求，或者也许有一种方法（至少暂时）使 IIS 尽快将请求转储到日志文件？

Answer 1

这正常吗？每个处理 IIS 日志的人都需要花时间检查日志中的请求，或者也许有一种方法（至少暂时）使 IIS 尽快将请求转储到日志文件？

我认为这是正常的，因为有些条目缓冲在内存中，因此需要一段时间才能将它们写入文件日志。

其中，这个属性可能对你有帮助：

flushByEntryCountW3CLog

，其介绍如文档所示：

指定在将事件刷新到日志文件之前要存储在缓冲区中的事件数。较小的数字将导致事件刷新速度更快，但会因磁盘操作次数增多而导致性能下降。减小该值可实现更实时的故障排除，增加该值可提高性能。值 0 指定刷新将以默认最大值 64k 发生。

由于其默认值为0，日志记录与缓冲区绑定，因此它不是最实时的。尝试将其值更改为 1。这将使日志记录（磁盘写入）更加频繁。但同时也会降低性能。