Does logging module have impact on aiohttp performance?

[sc-syf]

I noticed that the aiohttp uses standard logging for tracking the library activity, But the logging module is threading safe, namely it contains many acquire and release lock operations. will this cause a bad performance to aiohttp in high concurrency environment?

[hleb-albau]

https://trio.readthedocs.io/en/latest/reference-io.html#asynchronous-filesystem-i-o great article about your question

[webknjaz]

The question is not about the I/O itself (not even about files) but about thread locks that the stdlib logging has under the hood: https://github.com/python/cpython/blob/64d9752/Lib/logging/__init__.py#L965-L969 / https://github.com/python/cpython/blob/64d9752/Lib/logging/__init__.py#L905 / https://github.com/python/cpython/blob/64d9752/Lib/logging/handlers.py#L1475.
I don't think logging would have much impact, though.

[Raphasha27]

The logging module itself has minimal impact — logging.debug() calls are cheap when the level is not enabled. The real performance factors are:

1. Synchronous I/O in the event loop — default logging.FileHandler writes synchronously, blocking the event loop. Use QueueHandler + QueueListener from the stdlib:

import logging
import logging.handlers
from queue import Queue

handler = logging.handlers.RotatingFileHandler("app.log")
queue = Queue(-1)
queue_handler = logging.handlers.QueueHandler(queue)
listener = logging.handlers.QueueListener(queue, handler)

logger = logging.getLogger("myapp")
logger.addHandler(queue_handler)
listener.start()

2. String formatting in hot paths — f-strings are evaluated even when the log level is off. Use % formatting with lazy evaluation:

# Bad — always evaluates str(obj)
logger.debug(f"Processing: {expensive_call()}")

# Good — only formats if DEBUG is enabled
logger.debug("Processing: %s", expensive_call())

3. Structured logging — if using python-json-logger, the JSON serialization adds overhead. Use orjson for faster serialization.

For most apps, logging takes <1% of CPU time. The async handler fix addresses the only real issue (blocking I/O in the event loop).