libuv 记录最佳实践？答案

【问题标题】：libuv logging best practice?libuv 记录最佳实践？
【发布时间】：2015-03-12 20:41:32
【问题描述】：

我的程序中有一个 std::stringstream，它会定期（使用计时器）刷新到日志文件中。刷新和计时器在默认的运行循环中。

应用程序的其他部分只是附加到该 std::stringstream 并且计时器负责其余部分。我确实限制了字符串流的大小（到 1mb），所以如果流是“满的”，我会丢弃消息。

我只是想知道，这是最佳实践吗；

node.js 如何处理日志记录？

【问题讨论】：

我在这里看到的唯一问题是，如果您将日志重定向到文件中，它将被阻塞。所以，我要说的是，既然你已经使用 libuv 来刷新你的流，那么为什么不通过uv_fs_* + 重定向接口实现一个完全非阻塞的日志记录方法呢？在我的实践中，我发现阻塞日志文件对于增加额外延迟非常重要，尤其是在 libuv 的情况下，所有工作都在单个线程中完成，无论其他一切是否都是非阻塞的。
我正在使用 uv_fs_* 以非阻塞方式写入文件。

标签： libuv

【解决方案1】：

我认为这个问题比人们乍一看可能想的要复杂。

良好响应的一部分与 libuv 无关，而与您的具体需求和权衡取舍有很大关系。虽然，例如，一些缓冲，即不太频繁的写入系统调用，是好的，但它也引入了一个问题，可能（或不会）在日志记录领域对您造成严重影响。原因：如果应用程序死亡，缓冲的东西也会随着应用程序一起死亡。然而，这与日志记录的逻辑背道而驰。

至于libuv和性能，我个人的经验是这样的

a) 人们希望在写出信息和缓冲之间找到一个很好的平衡点。在你的情况下，我的直觉是你缓冲太多，你应该更频繁地写出来。

b) 人们希望从性能是否真的关键以及细节方面考虑性能。后者在繁重的服务器负载下变得越来越重要。当您提供大约 100 个连接时，它可能无关紧要，但如果您提供数万或数十万个连接，则使用 fprintf 等便利功能可能成本太高。

具体示例：在高负载情况下，您可能希望在启动时获取一次挂壁时间以及单调计时器的（当时）当前值（非常便宜）。任何时间信息都可能与该起始值相关（简单的减法）。写出来的工作方式如下：预先格式化的开始时间加上单调差异（例如“03:52:41 +123456 ms”）。

您的场景的另一点是现代操作系统几乎总是会提供出色的缓冲，因此自己缓冲过多通常没有多大意义。

总而言之，我建议使用大约 16K 或 32K 的缓冲区并更频繁地写出它。如果（且仅当）您的场景是高性能/重负载时，您可能希望避免使用方便但昂贵的功能。

就 libuv 而言，我不担心。根据您的操作系统和 libuv 版本文件内容（与套接字内容相反）可能确实是伪异步（通过线程伪造），但我的经验是 libuv 不是问题；相反，例如，您的大缓冲区可能是个问题，因为它很可能被写入多个块。

关于基于计时器的方法，您可能需要查看 libuv 空闲机制并注意缓冲区已满的问题。简单地丢弃日志信息对我来说似乎是不可接受的。毕竟，您不是为了好玩而登录，而是因为该信息可能很重要（如果不是这样，您一开始就不会遇到问题。那么解决方案将很简单：减少日志记录）。

最后，我想说一个更笼统的说法：这里的秘诀是平衡，而不是优化单个细节的性能。您希望使整个系统保持良好的平衡，而不是通过使用大型缓冲区进行优化，这最终只是将问题推到另一个层次而不是解决它。

我喜欢把这个问题领域想象成搬家的任务，例如搬家。公司总部：问题不在于最快的卡车，而在于所有卡车都非常快，换句话说，这是一种平衡的方法。

【讨论】：

【解决方案2】：

老实说，有比手动记录更好的选择。如果您正在编写应用程序，那么在开发和执行时间上，使用库通常会更快。

如果您正在编程学习，那么我建议您看一下 spdlog（最快的方法）和 g3log，它们声称有最好的最坏情况。

根据我的经验，std::stringstream 的速度不足以成为日志系统的一部分。

【讨论】：