python logging 模块中的 log_level 参数不会影响性能吗？

Question

我正在使用 API 从我的项目中获取一些服务。 API 调用花费的时间太长，所以我认为原因之一可能是我在项目中放置了大量日志，并且 IO 读取/写入需要时间。

我正在使用logging。我的猜测是 LOG_LEVEL 丢弃较低优先级的日志，较高优先级的 API 调用应该在更短的时间内完成。但时间几乎相同（差异在 1/10 秒的范围内）。

我从here 得到的关于 LOG_LEVEL 和性能的唯一参考是

这样做的好处是，如果您将日志级别设置为 WARN，则信息和调试消息几乎不会影响性能。

这里有几点需要注意

1. 我没有将我的日志配置为流式传输到任何日志服务，例如 Kibana。

2. 我已经检查了this 的情况，我没有在日志消息中做任何预处理。

3. 我已经完成了基本的 Logger 初始化，即

导入日志
logger = logging.getLogger(__name__)

和没有使用任何文件写入日志如下。 LOG_LEVEL 作为环境变量之一给出。

logging.basicConfig(filename="file_name.log")

考虑到其他一切都是最佳的（如果一切都不是最佳的，那么更高优先级的日志应该花费更少的时间），由于日志读/写，我猜测更多时间是错误的吗？如果不是，那么为什么使用高优先级 LOG_LEVEL 标志并没有减少时间？

日志模块在哪个默认位置存储日志？

Answer 1

日志级别的性能有什么区别？

设置日志级别可能会影响性能，但在规模化之前可能不会很明显。

当您设置级别时，您正在创建一种方法来阻止日志记录过程继续进行，并且在使用任何单独的日志检查之前几乎不会发生这种情况。例如，这是CRITICAL 日志在code 中的样子：

if self.isEnabledFor(CRITICAL):
    self._log(CRITICAL, msg, args, **kwargs)

作为_log 的一部分，记录器本身还有更多工作要做，而不仅仅是此检查，因此通过设置日志级别可以节省时间。但是，它经过了相当优化，因此在您启动记录器时，除非调用量的差异很大，否则您可能不会注意到太多。

如果您删除了对日志记录的任何引用，而不仅仅是设置级别，您将获得更多的性能提升，因为根本没有进行检查（这显然需要一些时间）。

日志默认存储在哪里？

默认情况下，不设置文件，StreamHandler [source] 是启用的，并且不指定特定流，它将流到sys.stderr。当你设置一个文件时，它会创建一个FileHandler，它继承自与StreamHandlers相同的函数[source]。

如何优化？

对于您没有问的问题，如何加快日志记录？我建议查看this，它会提供一些建议。该建议的一部分是我在上面指出的，但告诉您明确检查您的日志级别，您甚至可以缓存该结果并改为检查缓存，这将进一步减少时间。

查看this answer 了解更多关于优化日志记录的信息。

最后，如果您想确定代码的速度问题，无论是否来自日志记录，您都需要使用分析器。 Python中有内置的分析函数，请查看here。

Answer 2

一个日志级别并不比另一个日志级别更高，但是，如果启用了一个级别的日志记录，则记录器是嵌套的（在您的示例中，如果__name__ 中有像mypackage.core.logs 这样的点，则会发生这种情况），并且您正在运行的 Python 版本可以。这是因为当您进行日志调用时会发生三件事：

1. 记录器确定是否启用了日志记录级别。

   每次通话都会发生这种情况。在 3.7 之前的 Python 版本中，此调用未缓存，并且嵌套记录器需要更长的时间来确定它们是否已启用。还要多久？在某些基准测试中，时间是原来的两倍。也就是说，这在很大程度上依赖于日志嵌套，即使在记录数百万条消息时，也只能节省几秒钟的系统时间。

2. 记录器处理记录。

   这就是in the documentation 概述的优化发挥作用的地方。它们允许记录创建跳过一些步骤。

3. 记录器将记录发送给处理程序。

   这可能是默认的StreamHandler、FileHandler、SysLogHandler，或者任何数量的内置或自定义处理程序。在您的示例中，您使用FileHandler 写入当前目录中的file_name.log。这对于较小的应用程序可能很好，较大的应用程序将受益于使用外部记录器，如 syslog 或 systemd 日志。主要原因是它们在单独的进程中运行，并且针对处理大量日志进行了优化。