Serilog.Sinks.Console 接收器是否从包装到 Serilog.Sinks.Async 接收器中获得任何好处? [英] Does Serilog.Sinks.Console sink get any benefits from wrapping to Serilog.Sinks.Async sink?

问题描述

我在我的 aspnet 核心应用程序中使用 Serilog 进行日志记录.而且我需要非常频繁地将日志事件写入控制台(每秒 300-500 个事件).我在 docker 容器中运行我的应用程序，并使用协调器工具处理控制台日志.

I using Serilog inside my aspnet core app for logging. And i need to write log events to console pretty frequently (300-500 events per second). I run my app inside docker container and procces console logs using orchestrator tools.

所以我的问题是:我应该为我的 Console 接收器使用 Async 包装器，我会从中获得任何好处吗?我阅读了文档(https://github.com/serilog/serilog-sinks-async)，但无法理解 Console 接收器是否实际.

So my question: should i use Async wrapper for my Console sink and will i get any benefits from that? I read the documentation (https://github.com/serilog/serilog-sinks-async), but can't understand is it actual for Console sink or not.

推荐答案

Async Sink 接收已经捕获的 LogEvent 项并将它们从使用 ConcurrentQueue 生产者/消费者集合的多个前台线程.一般来说，这对于稳定的吞吐量尤其是事件吞吐量来说是一件好事.

The Async Sink takes the already-captured LogEvent items and shifts them to a single background processor from multiple foreground threads using a ConcurrentQueue Producer/Consumer collection. In general that's a good thing for stable throughput esp with that throughput of events.

此外，如果发送到 >1 个接收器，转移到一个后台线程，该线程将根据需要重点关注该工作负载(即传播到缓存中的接收器的路径)，如果您有足够的可用内核和/或接收器甚至暂时阻止.

Also if sending to >1 sink, shifting to a background thread which will be scheduled as necessary focusing on that workload (i.e., paths propagating to sinks being in cache) can be good if you have enough cores available and/or Sinks block even momentarily.

话虽如此，基于此信息的任何内容都是过早的优化.

Having said that, to base anything of this information is premature optimization.

如果您不将 Async 放在前面，控制台接收器以及它们在不阻塞的情况下有效摄取的能力，总是取决于很多 - 例如，托管环境通常会合成一个 stdout.如果效果很好，在控制台接收器前添加 Async 只会延长对象的生命周期，而与允许每个线程直接提交到控制台接收器相比没有太大好处.

Console sinks and their ability to ingest efficiently without blocking if you don't put an Async in front, always Depends a lot - for example, hosting environments typically synthesize a stdout that buffers efficiently. When that works well, adding an Async in front of the Console sink is merely going to prolong object lifetimes without much benefit vs allowing each thread submit to the Console sink directly.

所以，这取决于 - IME 将所有内容提供给 Async 并在那里进行所有处理(例如写入一个缓冲文件，每发送一个 .5s(可能发送到一个 sidecar 进程)转发到您的日志存储))可以很好地工作.最重要的是，一个好的负载生成器装备对于任何高吞吐量应用程序都是非常有用的.一旦你有了一个，你就可以进行实验——我已经看到通过重新组织完全相同的输出和它的调度方式，吞吐量提高了 30%(不可否认，我也在过渡期间切换到了 Serilog——你不太可能看到任何顺序).

So, it depends - IME feeding everything to Async and doing all processing there (e.g. writing to a buffered file, emitting every .5s (perhaps to a sidecar process that forwards to your log store)) can work well. The bottom line is that a good load generator rig is a very useful thing for any high throughput app. Once you have one, you can experiment - I've seen 30% throughput gains from reorganizing the exact same output and how it's scheduled (admittedly I also switched to Serilog during that transition - you're unlikely to see anything of that order).

这篇关于Serilog.Sinks.Console 接收器是否从包装到 Serilog.Sinks.Async 接收器中获得任何好处?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！