日志记录策略与性能答案

【问题标题】：Logging strategy vs. performance日志记录策略与性能
【发布时间】：2010-04-12 21:56:25
【问题描述】：

我正在开发一个必须支持大量同时请求的 Web 应用程序，并且我希望它保持足够快的速度。我现在必须实施日志记录策略，我将使用 log4net，但是......我应该记录什么以及如何记录？我的意思是：

日志记录对性能有何影响？是否可以/推荐使用异步调用进行日志记录？
使用文本文件还是数据库更好？是否可以有条件地做到这一点？例如，默认日志到数据库，如果失败，则切换到文本文件。
多线程呢？使用 log4net 时我应该关心同步吗？还是开箱即用的线程安全？

在要求中，应用程序应该为每个请求缓存一些东西，我担心这会影响性能。

干杯。

【问题讨论】：

标签： .net architecture logging synchronization log4net

【解决方案1】：

它让事情变得更慢 - 做某事比什么都不做需要更多的时间。通常可以忽略不计。不用担心。
登录到文本文件 imo。它们很容易移动/grep/compress/mail 等，并且您不必担心数据库已关闭的事实记录到数据库。如果您需要，可以使用附加程序记录到 log4net 的数据库。
Yes，log4net 是线程安全的。

记录/跟踪非常有价值——至少您应该记录错误，否则您永远不会知道它们。大多数日志记录 API 允许您打开和关闭您需要记录的详细程度。

在出现问题之前不要担心性能。这不像您正在建造月球火箭并想通过测试来了解它可以承载多少重量 - 它只是代码，删除淹没您的日志的日志语句并在它成为问题时重新编译。

【讨论】：

【解决方案2】：

我想说你在文章的早期就担心性能，以一种很容易在以后关闭或自定义的方式使用 log4net（例如：使用定义日志级别 NONE、ERROR、WARN 的 conf 文件，调试、信息、全部、详细等...），

但是您的另外两个问题是有效的，对于问题 2，我会选择纯文件，因为它们可以很容易地读取和访问，而不是数据库。此外，写入文件末尾的性能也优于 db。

是的，正如 nos 所说，log4net 是线程安全的。

一条一般性建议，如果您的项目很大，并且您希望拥有如上所述的可配置日志级别，那么您确实需要在您的团队中就记录的内容达成一致的编码标准在不同的层次。

【讨论】：

【解决方案3】：

我完全同意 hhafez 和 nos 所说的话。您正在使用日志记录包走上正确的道路，而不是尝试自己动手。它更清洁，更容易正确。记录到文本文件比 DB 记录更容易长期管理（考虑到典型的项目技能），但如果您计划对报告的数据进行任何复杂的分析，有时将其保存在 DB 中会更容易。

如果调试是您实现日志记录解决方案的既定目标之一，那么您必须预先标准化所有日志级别并将其作为代码审查流程的一部分。在粒度上有足够的差异，以便您可以通过进入下一个级别来逐渐增加报告的深度。对 PROD 问题进行故障排除，没有足够的日志信息来查看问题，然后增加到下一个日志记录级别并完全淹没日志，以至于您看不到树木的森林（并且由于体积，您的日志每 5 分钟滚动一次）。我已经看到了。

在大多数文本文件日志记录的情况下，性能应该不是问题。数据库日志记录有点棘手。插入只比附加到文本文件稍微密集一些，但它是每单位时间的体积使它在规模上更难看。

另外，如果您要进行任何离线日志分析，您应该选择一种易于扩展的日志文件格式，并且如果您需要在日志中添加一些内容，则不需要对分析代码进行大量更改。远离嵌套的多部分消息结构。解析这些会很痛苦。

祝你好运！

【讨论】：