在生产环境中启用 Rails 日志记录会影响性能吗？
我希望这个问题不要太模糊，但是在生产环境中登录是否会导致性能下降？除了传统的 production.log 日志记录之外，我们还在开始/救援类型事件中记录了一些其他内容，以帮助我们调试问题。
在我们的 Production.rb 文件中，我们的设置是：
config.log_level = :info
config.active_support.deprecation = :log
我们还有一些：
TRACKER_LOG.warn xml_response_hash
这些文件可能会变得非常大（每个 1 或 2 GB），并且我们的网站每月会收到几百万的页面浏览量。最大限度地减少生产中日志的使用是否有助于提高性能？
I hope this question isn't too vague, but does logging in a production environment cause a hit in performance? In addition to the traditional production.log logging, we have a couple of additional things we record in begin/rescue type events to help us for debugging issues.
In our production.rb file, our settings are:
config.log_level = :info
config.active_support.deprecation = :log
And we also have some:
TRACKER_LOG.warn xml_response_hash
These files can become quite large (1 or 2 GB each) and our website receives a couple million page views a month. Chould minimizing our use of logs on production help with performance?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
日志记录确实会影响性能，但如果它允许运行服务的人员在不关闭服务的情况下诊断问题，那么它在生产中仍然有用。
也就是说，每月几百万的点击量相当于每天不到 10 万（平均），这不应该太令人担心。同样，只要服务部署合理，并且您使用日志轮换策略，几 GB 的日志文件也不用担心，因为磁盘空间非常便宜。因此，按照目前的水平，我建议你应该没问题。不过请留意它；如果流量突然激增（例如，正常一天的点击量达到 100 万次），您可能会遇到问题。 记录下来！您不希望制作人员对此类事情感到惊讶。
考虑使额外的日志记录以您可以在运行时禁用或启用的标志为条件，以便您只在需要时收集任何大的东西；对于通常的日志数据量，您很有可能只是偶尔查找问题。
Logging does impact on performance, but it can still be useful in production if it allows the people running the service to diagnose problems without taking the service down.
That said, a couple of million hits a month is less than 100k per day (on average) and that shouldn't be too much of a worry. Similarly, a few GB of log files should not be a worry provided the service is deployed sanely — and provided you're using a log rotation strategy of course — since disk space is pretty cheap. Thus at current levels, I'd suggest you should be OK. Keep an eye on it though; if traffic suddenly spikes (e.g., to 1M hits in a normal day) you could have problems. Document this! You don't want the production people to be surprised by these sorts of things.
Consider making the extra logging conditional on a flag that you can disable or enable at runtime so that you only collect anything large if you're looking for it; with usual volumes of logging data there's a good chance that you'll only look for problems occasionally anyway.