обратите внимание что в предлагаемой к вниманию статье benchmark библиотек логирования C++ в разделе Overhead логирования как раз рассматривает то о чем выв говорите и приводятся конкретные результаты тестирования. к условиям тестирования могут быть претензии (например, в стиле "Quill показал не лучшие результаты потому что его тестировали не в тех условиях для которых он предназначен"). но ведь там как раз суть тестов в измерении затрат на логирование в ситуации когда форматировать не нужно
Да, очень похоже на то, к чему в итоге приходят в реальных системах
Особенно показательно, что у вас:
есть разбиение на узлы
уровень управляется отдельно
и отдельно появился AllowLog после нагрузочных тестов
Это как раз иллюстрирует основной тезис статьи — логирование начинает жить своей жизнью, как отдельная подсистема, а не просто “вызовы printf”.
Про AllowLog — это вообще классический момент. Почти везде к этому приходят, когда становится понятно, что стоимость формирования сообщения иногда выше, чем его запись.
С БД как хранилищем тоже понятный выбор, особенно если потом активно анализируете логи SQL-запросами. Тут уже больше вопрос компромисса между удобством анализа и нагрузкой на саму систему хранения.
В целом хороший пример того, что в проде важнее управляемость и структура.
конечно же никто не отменял традиционные методы фильтрации логируемых сообщений. это и уровень. да собственно и возможность полной блокировки вывода в лог. если интересно, посмотрите другую мою статью - https://habr.com/ru/articles/1012874/
я говорю ведь не о заметании под ковер, а мусоре. ок, если не нравится этот пример, можно ведь придумать и другие. речь о том, что зачастую не хочется видеть миллион одинаковых сообщений которыми забит весь лог. и это задача именно программиста решить уместно ли печатать это один раз или миллион. я говорю о возможностях, а не о том как следует их использовать
Суть простая: если пропускная способность устройства (консоль, диск и т.д.) ниже, чем поток логов — никакая архитектура это не «починит». Так что если нужно писать именно в консоль, то решением может быть только уменьшение потока данных
Я как раз и не продвигаю какой-то из подходов. Мою задачу я видел в том чтобы обсудить какие вообще есть варианты и какие у них trade-offs
Асинхронное логирование само по себе не является "индусским подходом". Это нормальный инструмент, который решает вполне конкретную задачу - минимизацию latency в вызывающем потоке, когда важно не блокироваться ни на I/O, ни на форматировании
Да, у него есть своя цена и ограничения. Но и у альтернативных подходов они тоже есть
В итоге это не вопрос «правильно / неправильно», а вопрос требований и архитектуры
это скорее стилизовано под массу комментариев к моей предыдущей статье об асинхронном логировании, latency, quill. какие-то рассуждения в статье кажутся спорными?
В logme в null-сценарии происходит ранний выход до любой дополнительной логики, включая получение времени — Clock::now() в этом пути не вызывается.
Поэтому для logme указанный overhead на результат не влияет.
В целом согласен, что при измерении таких малых величин даже несколько наносекунд могут искажать результаты, поэтому такие детали действительно важно учитывать.
Спасибо, вы описываете абсолютно здравый и, по сути, канонический подход для high-load систем — минимальная работа в рабочем потоке и перенос всего остального в асинхронную обработку.
И да, вы правы: в реальных проектах логирование почти никогда не используется «из коробки». Его настраивают под конкретные требования — формат, состав полей (timestamp, thread id и т.д.), синхронный/асинхронный режим, буферизацию, фильтры и прочее. В этом смысле итоговая производительность определяется не только библиотекой, но и архитектурой логирования в целом.
В бенчмарке же была немного другая цель. Мы сознательно упростили сценарий (логирование только сообщения без дополнительных полей), чтобы привести разные библиотеки к максимально сопоставимым условиям. Это не попытка смоделировать production, а скорее попытка получить «базовую стоимость» вызова логирования при прочих равных.
Если сразу сравнивать «как в жизни», то получится сравнение конкретных конфигураций (и даже конкретных подходов к логированию), а не библиотек — и такой результат будет сильно зависеть от выбранных настроек.
Поэтому я бы рассматривал этот тест скорее как отправную точку: он не отменяет необходимости тюнинга под конкретный проект, но позволяет получить общее представление о накладных расходах библиотек в более-менее нейтральных условиях.
А дальше — полностью согласен — в реальной high-load системе без дополнительной настройки логирования обычно никуда
В бенчмарке большинство библиотек уже работали в MT-safe режиме (включен в режиме “из коробки”), тогда как easylogging++ согласно документации — нет. Поэтому сравнение не занижает её результат — скорее наоборот.
spdlog, пожалуй, действительно самая известная библиотека. Что касается quill и easylogging++, их предложил ChatGPT в ответ на мой вопрос о том, какие ещё решения наиболее распространены в мире логирования.
logme — это, собственно, моя библиотека. Изначально я ставил себе задачу сравнить реальную производительность различных библиотек. Поскольку результаты получились достаточно интересными, решил ими поделиться.
обратите внимание что в предлагаемой к вниманию статье benchmark библиотек логирования C++ в разделе Overhead логирования как раз рассматривает то о чем выв говорите и приводятся конкретные результаты тестирования. к условиям тестирования могут быть претензии (например, в стиле "Quill показал не лучшие результаты потому что его тестировали не в тех условиях для которых он предназначен"). но ведь там как раз суть тестов в измерении затрат на логирование в ситуации когда форматировать не нужно
Да, очень похоже на то, к чему в итоге приходят в реальных системах
Особенно показательно, что у вас:
есть разбиение на узлы
уровень управляется отдельно
и отдельно появился AllowLog после нагрузочных тестов
Это как раз иллюстрирует основной тезис статьи — логирование начинает жить своей жизнью, как отдельная подсистема, а не просто “вызовы printf”.
Про AllowLog — это вообще классический момент. Почти везде к этому приходят, когда становится понятно, что стоимость формирования сообщения иногда выше, чем его запись.
С БД как хранилищем тоже понятный выбор, особенно если потом активно анализируете логи SQL-запросами. Тут уже больше вопрос компромисса между удобством анализа и нагрузкой на саму систему хранения.
В целом хороший пример того, что в проде важнее управляемость и структура.
так и происходит в библиотеках, которые я рассматривал
конечно же никто не отменял традиционные методы фильтрации логируемых сообщений. это и уровень. да собственно и возможность полной блокировки вывода в лог. если интересно, посмотрите другую мою статью - https://habr.com/ru/articles/1012874/
я говорю ведь не о заметании под ковер, а мусоре. ок, если не нравится этот пример, можно ведь придумать и другие. речь о том, что зачастую не хочется видеть миллион одинаковых сообщений которыми забит весь лог. и это задача именно программиста решить уместно ли печатать это один раз или миллион. я говорю о возможностях, а не о том как следует их использовать
Суть простая: если пропускная способность устройства (консоль, диск и т.д.) ниже, чем поток логов — никакая архитектура это не «починит». Так что если нужно писать именно в консоль, то решением может быть только уменьшение потока данных
Я как раз и не продвигаю какой-то из подходов. Мою задачу я видел в том чтобы обсудить какие вообще есть варианты и какие у них trade-offs
Асинхронное логирование само по себе не является "индусским подходом". Это нормальный инструмент, который решает вполне конкретную задачу - минимизацию latency в вызывающем потоке, когда важно не блокироваться ни на I/O, ни на форматировании
Да, у него есть своя цена и ограничения. Но и у альтернативных подходов они тоже есть
В итоге это не вопрос «правильно / неправильно», а вопрос требований и архитектуры
это скорее стилизовано под массу комментариев к моей предыдущей статье об асинхронном логировании, latency, quill. какие-то рассуждения в статье кажутся спорными?
Спасибо за комментарий.
В logme в null-сценарии происходит ранний выход до любой дополнительной логики, включая получение времени —
Clock::now()в этом пути не вызывается.Поэтому для logme указанный overhead на результат не влияет.
В целом согласен, что при измерении таких малых величин даже несколько наносекунд могут искажать результаты, поэтому такие детали действительно важно учитывать.
Спасибо, вы описываете абсолютно здравый и, по сути, канонический подход для high-load систем — минимальная работа в рабочем потоке и перенос всего остального в асинхронную обработку.
И да, вы правы: в реальных проектах логирование почти никогда не используется «из коробки». Его настраивают под конкретные требования — формат, состав полей (timestamp, thread id и т.д.), синхронный/асинхронный режим, буферизацию, фильтры и прочее. В этом смысле итоговая производительность определяется не только библиотекой, но и архитектурой логирования в целом.
В бенчмарке же была немного другая цель. Мы сознательно упростили сценарий (логирование только сообщения без дополнительных полей), чтобы привести разные библиотеки к максимально сопоставимым условиям. Это не попытка смоделировать production, а скорее попытка получить «базовую стоимость» вызова логирования при прочих равных.
Если сразу сравнивать «как в жизни», то получится сравнение конкретных конфигураций (и даже конкретных подходов к логированию), а не библиотек — и такой результат будет сильно зависеть от выбранных настроек.
Поэтому я бы рассматривал этот тест скорее как отправную точку: он не отменяет необходимости тюнинга под конкретный проект, но позволяет получить общее представление о накладных расходах библиотек в более-менее нейтральных условиях.
А дальше — полностью согласен — в реальной high-load системе без дополнительной настройки логирования обычно никуда
В бенчмарке большинство библиотек уже работали в MT-safe режиме (включен в режиме “из коробки”), тогда как easylogging++ согласно документации — нет. Поэтому сравнение не занижает её результат — скорее наоборот.
spdlog, пожалуй, действительно самая известная библиотека. Что касается quill и easylogging++, их предложил ChatGPT в ответ на мой вопрос о том, какие ещё решения наиболее распространены в мире логирования.
logme — это, собственно, моя библиотека. Изначально я ставил себе задачу сравнить реальную производительность различных библиотек. Поскольку результаты получились достаточно интересными, решил ими поделиться.