使用 FileHandler 进行日志记录是瓶颈吗？
我正在考虑使用 Java 日志记录和 FileHandler 在 J2EE Web 应用程序中记录业务事件。
我想知道这是否会导致性能瓶颈，因为许多日志记录将写入一个文件。
您有什么经验和看法？
使用 Java 日志记录和 FileHandler 将繁忙的 Web 应用程序记录到一个文件是否可能成为性能瓶颈？
I am considering logging business events in a J2EE web application by using Java logging and FileHandler.
I am wondering whether that could cause a performance bottleneck, since many log records will be written to one file.
What are your experiences and opinions?
Is logging a busy web application to one file with Java logging and FileHandler likely to become performance bottleneck?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这完全取决于您添加多少日志语句。如果在每行代码之后添加日志记录，那么性能肯定会下降。
对重要情况使用日志记录，为当前目的（测试或实际部署）设置正确的日志记录级别，并使用诸如
避免调用运行成本高昂的代码之类的结构。
您可能还想查看这篇文章
It all depends on how much log statements you add. If you add logging after every line of code then performance will must certainly degrade.
Use logging for the important cases, set the correct logging level for your current purposes (testing or actual deployment) and use constructions like
to avoid calling code that is costly to run.
You might also want to check this article
为了避免诸如“这取决于”或“一点”等笼统的说法，您应该在有或没有日志记录开销的情况下测量应用程序的性能。 Apache JMeter 可以帮助您生成测试负载。
您可以通过日志记录收集的信息通常对于应用程序的完整性至关重要，因此您不能盲目操作。如果您使用 Google Analytics，也会产生轻微的开销，但好处占上风。
为了将日志文件保持在合理的大小内，您始终可以使用轮换日志文件。
In order to avoid generalities like "it depends" or "a little" etc. you should measure the performance of your application with and without the logging overhead. Apache JMeter can help you generate the load for the test.
The information you can collect through logging is usually so essential for the integrity of the application, that you can not operate blindly. There is also a slight overhead if you use Google Analytics, but the benefits prevail.
In order to keep your log files within reasonable sizes, you can always use rotating log files.
我认为 JavaRevisited 博客有一篇关于性能问题的非常好的帖子： Java 日志记录的 10 大技巧
I think that JavaRevisited blog has a pretty good post on a problem with performance: Top 10 Tips on Logging in Java
在最近的一个项目中，我将审核事件记录到数据库表中，并且我担心性能，因此我添加了以“异步”模式登录的功能。在这种模式下，记录器在低优先级后台线程中运行，从主线程进行记录的行为只是将日志事件放入队列中，由后台记录线程延迟检索和写入。
然而，这种方法只有在处理过程中存在自然“中断”的情况下才有效。如果您的系统持续繁忙，那么队列将永远不会被清空。解决此问题的一种方法是根据队列中日志消息的数量使后台线程更加活跃（我尚未实现的增强功能）。
In a recent project, I log audit events to a database table and I was concerned about performance, so I added the ability to log in 'asynchronous' mode. In this mode the logger runs in a low-priority background thread and the act of logging from the main thread just puts the log events onto a queue which are lazily retrieved and written by the background logging thread.
This approach will only work, however, if there are natural 'breaks' in the processing; if your system is constantly busy then the queue will never be emptied. One way to solve this is to make the background thread more active depending on the number of the log messages in the queue (an enhancement I've yet to implement).
您应该：
定义适当的性能指标（例如响应能力、吞吐量等）。然后，您应该在关闭所有日志记录然后再打开的情况下测量该指标。区别在于伐木的成本。
然后您应该尝试不同的日志库及其提供的模式并记录观察到的差异。
根据我个人的经验，对于我参与的所有三个项目，我发现异步日志记录有助于提高应用程序吞吐量。但同样的情况可能不适用于您，因此请务必在仔细测量后做出决定。
以下内容与您的问题没有直接关系。
我注意到您特别提到了业务日志记录。在这种情况下，您可能还希望保持日志记录的相关性和干净性，以防您发现日志文件变得巨大且难以理解。该领域有一种普遍接受的设计模式：按照以下方式记录功能。这意味着业务日志记录（例如，客户请求退款）将转到不同的目的地，界面日志记录将转到另一个目的地（例如，用户单击了赞成按钮！=用户赞成答案），并且跨系统调用将转到另一个目的地。到另一个目的地（例如，通过支付网关请求清关）。有些人保留包含所有事件的主日志文件，只是为了查看流程的时间线，而有些人则设计日志挖掘程序/抓取器以在需要时构建时间线。
希望这有帮助，
You should:
Define an appropriate metric of performance (e.g., responsiveness, throughput, etc.). Then you should measure this metric with all logging turned off and then on. The difference would be the cost of logging.
Then you should experiment with different logging libraries and the modes they provide and document the observed differences.
In my personal experience, for all the three projects I worked on, I found that asynchronous logging helped improve the application throughput a lot. But the same may not hold for you, so make sure you make your decision after careful measurements.
The following does not directly relate to your question.
I noticed that you specifically mentioned business logging. In this case, you may also want to keep logging relevant and clean, in case you find your log files are growing huge and difficult to understand. There is a generally accepted design pattern in this area: log as per function. This would mean that business logging (e.g., customer requested a refund) goes to a different destination, interface logging would go to another destination (e.g., user clicked the upvote button != user upvoted an answer), and a cross system call would go to another destination (e.g., Requesting clearance through payment gateway). Some people keep a master log file with all events as well just to see a timeline of the process while some design log miners/scrappers to construct timelines when required.
Hope this helps,