libuv记录最佳实践？

Question

我的程序中有一个std：：std流，它定期地(带有计时器)刷新到一个日志文件中。刷新和计时器处于默认运行循环中。

应用程序的其他部分只是附加到std：：std流中，其余部分由计时器负责。我确实限制了字符串流的大小( 1mb)，所以如果消息流是“满的”，我就会删除消息。

我只是在想，这是最好的做法吗？

• 表演？在主线程上可以处理这个IO吗？我能做得更好吗？
• 关键错误？问题可能在我使用libuv的范围内，这可能意味着基于libuv的日志记录将被编码？

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

Answer 1

我认为这个问题比一见钟情要复杂得多。

一个好的反应的一部分与libuv没有什么关系，与你的具体需求和权衡有很大关系。例如，虽然一些缓冲(即较少频繁的写系统)是好的，但它也带来了一个在日志记录方面可能(或不)对您造成严重打击的问题。原因:如果应用程序死了，缓冲的东西会随着应用程序一起死掉。然而，这违背了日志记录的逻辑。

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

一个人想要在写信息和缓冲之间找到一个很好的平衡。在你这种情况下，我的直觉是你的缓冲太多了，你应该更频繁地写出来。

一个人想要很好地考虑性能，无论是从它是否真的至关重要的角度，还是从细节的角度。后者在服务器负载较重的情况下越来越重要。当您提供大约100个连接时，它可能是无关紧要的，但是如果您为成千上万个连接提供服务，使用像fprintf这样的方便函数可能会花费太大。

具体示例:在高度加载的情况下，您可能希望在启动时获得一次墙壁时间，以及(然后)单个定时器的当前值(这非常便宜)。任何时间信息都可以相对于该起始值(一个简单的减法)。写出它的工作方式如下:预先格式化的开始壁时间加上单调差异(例如"03:52:41 +123456 ms")。

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

总之，我建议使用一个大约16K或32K的缓冲区，并更频繁地写出它。如果(并且只有当)您的场景是高性能/重负载时，您可能希望避免使用方便但昂贵的函数。

就利布夫而言，我不会担心。根据您的操作系统和libuv版本的文件(与套接字不同)可能确实是伪异步(通过线程伪造)，但我的经验是，libuv不是问题；例如，您的大型缓冲区可能是一个问题，因为它很可能是多块编写的。

关于基于计时器的方法，您可能希望查看libuv空闲机制，并处理完整缓冲区的问题。简单地丢弃日志信息对我来说似乎是不可接受的；毕竟，你不是为了它的乐趣而登录，而是因为这个信息大概很重要(如果不是这样的话，你就不会有问题了。)那么解决方案将很简单:更少的日志记录)。

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

我喜欢考虑这个问题领域，就像移动公司总部的任务一样:问题不在于最快的卡车，而在于它们都相当快，换句话说，是一种平衡的方法。

Answer 2

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

如果您正在编程学习，那么我建议您看看spdlog (最快的方法)和g3log，这是最坏的情况。

在我的经验中，std：：logging流不够快，不足以成为日志记录系统的一部分。