timer_resolution无法降低Master与Worker间时间更新损耗，因其仅作用于单进程内部时钟读取频率，不涉及进程间通信或同步；Master默认不参与事件循环，Worker各自独立运行，无时间共享或校准机制。
timer_resolution 无法降低 Master 与 Worker 之间的时间更新损耗。它根本不涉及 Master 和 Worker 进程间的时间同步或通信，也不优化二者协作开销。该参数仅作用于单个 worker 进程（或主进程）内部，控制其自身读取高精度时钟的频率，与进程间通信完全无关。
timer_resolution 的实际影响范围
它只在启用它的那个进程内生效，且仅用于更频繁地调用 clock_gettime(CLOCK_MONOTONIC)，目的是让该进程内部的超时判断（如 keepalive_timeout、resolver timeout）更及时。Master 进程默认不参与事件循环，一般也不受 timer_resolution 影响；Worker 进程各自独立执行，彼此之间不共享时间缓存，也不存在“时间更新同步”这一环节。
Master-Worker 架构中真正的时间相关开销在哪
Master 与 Worker 之间的协调依赖信号（如 SIGUSR1、SIGWINCH）和共享内存（如状态统计），而非周期性时间同步。所谓“时间更新损耗”并不存在——它们不传递时间戳，也不校准彼此时钟。常见误解往往源于混淆了以下几点：
- Nginx 自身超时逻辑（单进程内） vs. 进程间协作机制（无时间同步）
- worker 内部 clock_gettime 调用（用户态→内核态切换） vs. master-worker 通信（信号或共享内存，几乎无时间开销）
- 系统级时钟分辨率（Windows 的 NtSetTimerResolution） vs. Nginx 的 timer_resolution 指令（后者不修改系统设置）
若观察到时间相关延迟，应排查这些方向
比如长连接断连慢、超时不准、日志时间跳变等现象，根源通常不在 timer_resolution，而在于：
- 未启用 epoll/kqueue：回退到 select/poll 会导致超时计算粗糙，日志中可见 “using select”
- keepalive_timeout 设置过大（如 300s），导致空闲连接堆积，超时检查负担重
- resolver timeout 配置不合理，DNS 查询阻塞未设上限
- 系统时钟被手动调整（如 ntpdate 强制校时），引发 Nginx 内部单调时钟异常
正确使用 timer_resolution 的前提与建议
仅当业务存在大量低流量长连接（如 WebSocket 服务），且实测发现空闲连接需远超配置值才断开（例如 keepalive_timeout 60s，但实际等待 65s+ 才释放），才考虑启用：
- 放在 main 块：
timer_resolution 100ms; - 避免设为 0 或低于 10ms，否则每毫秒一次 clock_gettime，徒增 CPU 切换开销
- 启动后检查 error log 是否出现 “using timer resolution”，确认生效
- 搭配精简超时参数（如 keepalive_timeout 30s; client_header_timeout 10s）效果更明显
