timer_resolution不能减少系统调用，反而会提高时钟读取频率、增加epoll_wait唤醒次数和cpu开销；它仅在长连接场景（如http/2、websocket）中提升超时灵敏度，属有意识权衡。
不能。timer_resolution 的作用恰恰相反：它会提高事件循环中对系统时钟的读取频率，而不是降低系统调用次数。
timer_resolution 不减少系统调用，反而可能增加开销
该指令不会减少 epoll_wait()、kqueue() 等 I/O 多路复用系统调用的次数；相反，它会让 Nginx 更频繁地唤醒并检查定时器，从而可能导致更多次的系统调用：
- 未配置 timer_resolution 时，Nginx 在无事件情况下可长期阻塞（epoll_wait timeout = -1），仅在有 I/O 或信号时才被唤醒
- 配置为 timer_resolution 100ms 后，Nginx 每 100ms 就主动调用一次 epoll_wait(timeout = 100)，即使没有网络事件也会定期返回用户态
- 若设为 1ms，就会每毫秒强制唤醒一次，显著增加上下文切换和 clock_gettime() 调用次数
真正影响系统调用频率的关键配置
若目标是降低事件循环中的系统调用频次，应关注以下更直接有效的设置：
- 保持 timer_resolution 未配置（默认）：这是低负载或高吞吐短连接场景下的最优选择，让 epoll_wait 尽可能长时间阻塞
- 合理设置 worker_connections 和 multi_accept：避免因连接积压导致反复调用 accept()
- 启用 reuseport（Linux 3.9+）：由内核分发连接到多个 worker，减少单个 worker 的 epoll_wait 唤醒争抢
- 确认使用 epoll/kqueue：避免回退到低效的 select/poll，后者本身就需要更频繁的轮询
什么场景下 timer_resolution 才有意义
它适用于需要快速感知空闲连接超时的长连接服务，例如：
- HTTP/2 或 WebSocket 服务中大量 keepalive 连接处于空闲状态
- resolver 超时需更灵敏响应（如 DNS 查询失败后快速重试）
- 自定义模块中依赖精确定时回调的逻辑
此时牺牲少量 CPU 换取更及时的超时清理，属于有意识的权衡，而非“优化性能”的通用手段。
