性能

Envoy 的架构旨在通过在 少量线程 上运行事件循环来优化可扩展性和资源利用率。“主”线程负责控制平面处理，每个“工作”线程处理数据平面处理的一部分。Envoy 公开了两个统计信息来监控所有这些线程上事件循环的性能。

• 循环持续时间： 在事件循环的每次迭代中都会执行一定量的处理。此数量自然会随着负载的变化而变化。但是，如果一个或多个线程的循环持续时间异常长尾，则可能表明存在性能问题。例如，工作可能没有在工作线程之间公平分配，或者扩展中可能存在长时间的阻塞操作，阻碍了进度。

• 轮询延迟： 在事件循环的每次迭代中，事件调度程序会轮询 I/O 事件并“唤醒”，无论是在一些 I/O 事件准备好处理时还是在超时触发时，以先发生者为准。在超时的情况下，我们可以衡量预期唤醒时间与轮询后实际唤醒时间之间的差值；这个差异称为“轮询延迟”。看到一些小的轮询延迟是正常的，通常等于内核调度程序的“时间片”或“量子”——这取决于 Envoy 运行的特定操作系统——但是，如果此数字显着高于其正常观察到的基线，则可能表明内核调度程序延迟。

可以通过将 enable_dispatcher_stats 设置为 true 来启用这些统计信息。

警告

请注意，启用调度程序统计信息会记录每个线程上事件循环每次迭代的值。这通常应该只是最小的开销，但是当使用 statsd 时，它会单独发送每个观察到的值，因为 statsd 协议没有办法表示直方图摘要。请注意，这可能是非常大量的数据。

事件循环统计

主线程的事件调度程序有一个以 server.dispatcher. 为根的统计树，每个工作线程的事件调度程序都有一个以 listener_manager.worker_<id>.dispatcher. 为根的统计树，每个树都有以下统计信息

名称	类型	描述
loop_duration_us	直方图	以微秒为单位的事件循环持续时间
poll_delay_us	直方图	以微秒为单位的轮询延迟

请注意，此处不包括任何辅助线程。

看门狗

除了事件循环统计信息外，Envoy 还包括一个可配置的 看门狗 系统，当 Envoy 响应不及时时，该系统可以增加统计信息，并选择性地杀死服务器。该系统有两个独立的看门狗配置，一个用于主线程，一个用于工作线程；这很有帮助，因为不同的线程有不同的工作负载。该系统还具有一个扩展点，允许根据看门狗事件采取自定义操作。统计信息有助于从高层了解 Envoy 的事件循环是否响应不及时，是因为它做得太多、被阻塞还是没有被操作系统调度。

看门狗在 main_thread 和 workers 中都发出聚合的统计信息。此外，它还在 server.<thread_name>. 树下发出单个统计信息。<thread_name> 等于 main_thread、worker_0、worker_1 等。

名称	类型	描述
watchdog_miss	计数器	标准丢失次数
watchdog_mega_miss	计数器	兆级丢失次数