我在aspnet核心应用程序中使用Serilog进行日志记录。而且我需要非常频繁地编写日志事件以进行控制台（每秒300-500个事件）。我在Docker容器中运行我的应用程序，并使用Orchestrator工具处理控制台日志。
所以我的问题是：我应该为我的Async接收器使用Console包装器吗？我会从中得到任何好处吗？
我已经阅读了文档（https://github.com/serilog/serilog-sinks-async），但无法理解Console接收器是否实际。
答案 0 :(得分：5)
Async接收器接收已捕获的LogEvent项，并使用ConcurrentQueue Producer / Consumer集合将它们从多个前台线程转移到单个后台处理器。通常，对于具有事件吞吐量的稳定吞吐量esp来说是一件好事。
如果发送到> 1个接收器，那么如果您有足够的可用核心和/或接收器，那么转移到后台线程将是很好的选择，该线程将在必要时着眼于该工作负载（即，传播到接收器的路径在缓存中）甚至会瞬间阻塞。
已经说过，将所有这些信息作为基础是过早的优化。
如果不将Async放在前面，控制台接收器及其有效接收而不阻塞的能力始终取决于很多情况-例如，托管环境通常会合成一个有效缓冲的stdout。如果效果良好，那么在控制台接收器前面添加一个Async只会延长对象生存期，而与允许每个线程直接提交到控制台接收器相比没有太大的好处。
因此，这取决于-IME将所有内容都馈送到Async并在那里进行所有处理（例如，写入缓冲的文件，发出每个.5s（可能是转发到日志存储的sidecar进程） ）可以很好地工作。最重要的是，对于任何高吞吐量应用程序而言，良好的负载生成器设备都是非常有用的东西。一旦有了一个，您就可以进行试验-我已经看到了通过重组完全相同的输出以及如何计划其输出可以提高30％的吞吐量（诚然，在过渡期间，我也切换到了Serilog-您不太可能看到该顺序的任何内容）。