我在.NET Core Service Fabric应用程序上使用Serilog。
我们注意到了性能问题，经过调查发现，Serilog是罪魁祸首。
我们记录了大约2,000条调试消息，这需要10秒钟以上的时间。
即使仅配置控制台接收器并将其设置为仅在信息日志级别进行过滤（这样也不会显示任何调试消息），这也是什至如此。
将MinimumLevel设置为Information可使相同的代码运行<1秒（即使已配置接收器）。
我们的项目使用：
这是Serilog所期望的表现吗？
编辑：我在另一个（很多）较小的项目中注意到了相同的行为。这使我得以隔离问题：我有一个自定义的扩充程序，正在检索ProcessId。调用Process.GetCurrentProcess()非常昂贵。对于每个记录调用都这样做，是导致性能下降的原因。我将流程ID存储在实例字段中，性能猛增。
答案 0 :(得分：2)
过滤掉调试级别的事件与设置最低级别不同； Serilog可用于结构化日志数据的序列化，因此Debug事件的构造可能会占用大量时间。
这可能表明调试日志记录存在问题-Serilog本身速度很快，但是如果您的调试事件正在序列化任意大的东西，例如请求/响应有效负载或DTO，您的应用程序最终将进行大量反射，对对象的属性访问器调用（这可能会阻塞，执行I / O和其他疯狂的事情），分配和垃圾回收。
如果调试事件使用了无效的消息模板（即使用$"..."字符串插值或非恒定字符串进行记录），则您的应用程序还将浪费大量精力将它们解析为格式字符串。
即并不是Serilog在这里运行缓慢，而是您的应用程序在无意间让它执行了很多浪费的工作。
使用Debug，然后在控制台接收器上使用更高版本的Information过滤器将导致所有这些工作完成，然后被丢弃。将最低级别设置为Information将首先阻止这项工作。
从长远来看，审核调试级别的日志记录以使用非恒定消息模板@和destructureObjects: true应该可以使事情恢复到合理的水平。