将Serilog.Sinks.Console接收器包装到Serilog.Sinks.Async接收器后，是否可以获得任何好处？

Question

我Serilog在aspnet核心应用程序内部使用日志记录。而且我需要非常频繁地编写日志事件以进行控制台（每秒300-500个事件）。我在Docker容器中运行我的应用程序，并使用Orchestrator工具处理控制台日志。

所以我的问题是：我应该Async为我的Console水槽使用包装纸吗，我会从中得到任何好处吗？我阅读了文档（https://github.com/serilog/serilog-sinks-async），但是不知道它是否适用于接收Console器。

Answer 1

所述Async水槽取已经捕获的LogEvent项并将它们从使用多个前景线程转移到一个单一的背景处理器ConcurrentQueue生产者/消费者集合。通常，对于具有事件吞吐量的稳定吞吐量尤其是好事。

同样，如果发送到> 1个接收器，则如果您有足够的可用内核和/或接收器即使暂时中断，则转移到将在必要时着眼于该工作负载（即，传播到接收器的路径在高速缓存中）进行调度的后台线程可能会很好。 。

话虽这么说，将所有这些信息作为基础是过早的优化。

控制台接收器及其有效接收而不阻塞的能力Async始终取决于很多方面，例如，托管环境通常会合成stdout高效缓冲的a 。如果效果良好，那么Async在控制台接收器的前面添加一个仅仅是延长对象寿命，而与允许每个线程直接提交到控制台接收器相比没有太大的好处。

因此，这取决于-IME将所有内容馈送给该对象Async并在其中进行所有处理（例如，写入缓冲文件，发出每个.5s（可能是转发到日志存储的Sidecar进程））。最重要的是，对于任何高吞吐量应用程序而言，良好的负载生成器设备都是非常有用的东西。一旦有了一个，您就可以进行实验-我已经看到了通过重组完全相同的输出以及如何计划它可以提高30％的吞吐量（诚然，在过渡期间，我也切换到了Serilog －您不太可能看到该顺序的任何东西）。