да, удовольствие тоже! И мы оба не упоминули ещё один фактор — возможность коммереского применения полученных навыков. Т.е. отточил человек навыки на OSS проекте, а потом сделал коммерческую фирму с похожим профилем. Или даже задействуя свои собственные наработки.
Если баг — это Ваша ответсвтенность поправить его в Вашем проекте.
Это всё равно что просить друзей пришедших на ваш День Рождения убрать у вас в комнате.
и Вас спасибо за отличный вопрос!
Кстати, забыл ответить на счёт «выносливости»: также тестировали на предмет деградации производительности при длительном использовании.
И ещё один момент: нужно будет повторить тесты под раздными JVM, пока не делали этого.
производительность была одним из основных требований к этому логгеру.
Расскажу как производилась оптимизация footprint этого логерра по отношению к CPU, RAM и влиянию на GC, а также как выбиралась архитектура и принципы разработки исходя из общей производительности:
— Тестовый стенд представляет собой гибридное Spring Boot приложение, имеющее около 150 постоянных потоков, как синхронизированных, так и постоянно работающих в фоне.
Он использует JPA, Hibernate, Groovy, REST. Стенд нагружался до степени, которая позволила выявить большое количество багов по потокобезопасности.
Влючалось логирование SQL и binding в JPA/Hibernate. Ну и самое главное — стенд использовал Blackbox, который логировал буквально каждый expression в коде бизнес логики. Т.е. вывод примерно 25Мб/с логов. Около 400 одновременно записываемых файлов.
— Была произведена первоначальная оптимизация при помощи нашего другого проекта Speedometer (пока на стадии разработки) — AST профайлер.
— Затем производился последовательный анализ вносимых изменений используя Java Visual VM. Анализировалось потребление CPU и особенно памяти и эффективности GC.
Как результат были выработаны и внедрены следующин принципы:
1-статическая компиляция всех классов (мы используем новый Groovy Enterprise Plugin)
2-отказ от использования синтаксиса форматирования аргументов, использованного в Slf4j (это кошмарная идея была изначальнл в Slf4j)
3-полное отсутствие synchronized блоков и методов
4-отказ от MDC/ThreadLocal — это вызывает проблемы для GC (тем не менее мы оставили поддержку встроенного MDC из Slf4j)
5-минимизация использования коллекций и особенно потокобезопасных коллекций. Это в первую очередь касается “@Memoized” — он очень сильно замедляет работу.
6-для замены Memoized была разработана другая аннотация “@CacheFieldInit”
7-минимизация создания экземпляров классов. По возможности используются только аргументы методов. Это очень сильно помогает GC, и непонятно почему этим пренебрегли в Logback.
8-скрипты из файла настройки статически компилируются в Груви класс используя GroovyClassLoader — это дает наилучшую производительность
9-потокобезопасность строится на принципе потоковой изоляции стеков операндов вызовов методов, избегая необходимость какой-либо синхронизации
Анализировались Heap Dumps, профайлер и разные статистики. Искались memory leaks.
Это был очень стрессовый процесс с пересиживаниями в ночь на протяжении 1.5 месяца. Иногда руки опускались и казалось что все напрасно.
Но конечный итог оправдал все надежды — у меня не было времени сохранить конкретные значения, но скажу так: по Java Visual VM logback выглядел… жирно — по сравнению с нашем логгером.
Если коротко — Bobbin быстрый. Очень быстрый. И экономит память.
Так же есть список todo: посмотреть как влияет opcodes.FINAL на GC в применении к операндам методов; протестировать производительность на других платформах кроме Windows.
тут есть такой момент, каждая фича должна быть покрыта тестами и документацией.
Так что фичи должны быть востребованы, иначе получается мертвый груз затрудняющий рефакторинг.
В идеале набор опций таков:
— xml, json, yaml конфиги
— groovy конфиг
— dsl конфиг
Начнем с yaml добавлять! По остальным проведем небольшой анализ и опрос.
отлично подмеченный момент! Пока подход такой: исключить эту функциональность, и позднее разработать отдельную независимую библиотеку для Housekeeping — в которой будут правила обращения с лог файлами и прочими файлами (например архивировать обработанные пакетные файлы с транзакциями).
Причина такая на мой взгляд: иначе получается смешение функциональностей и выходит супер библиотека, делающая всё.
А независимая библиотека априори более функциональная и качественная.
Да, так сделано в других логгерах. Например в Logback эти настройки применимы только к FileAppender, но в случае SiftingAppender появляются ограничения: jira.qos.ch/browse/LOGBACK-1442
Поэтому настало время принять правду — в Logback это архитектурно неправильно реализовано… Как Вы думаете?
вопрос ясен! И я тоже имел такую идею!
Но опыт показывает, что иногда пользователю может наоборот помешать доп. обработка — поэтому пока было сделано так. Пример:
"fileName": "threadName"
В этом случае имя лог файла равно имени треда. Но если взять насильно это в кавычки (за пределами JSON), смысл потеряется и переменная станет константой.
Огромное спасибо всем за комментарии! Если честно это был не очень подготовленный ход разместить статью сейчас. Дело в том что я сейчас в Бангладеше (идея привлечь студентов из развивающихся стран в Open Source проекты), тут дожди и у меня температура. Очень рад что пока позитивный feedback! (я боялся наихудшего!)
всё верно! Создаётся класс и компилируется используя GroovyClassloader.
Весь код использует только статическую компиляцию (через Groovy Enterprise Plugin).
Это сочетание обеспечивает наилучшую производительность (протестировали все возможности изначально).
изначально этот логгер был зависимостью более крупного проекта Blackbox — Груви аннотации для контроллируемого обогащения кода стейтментами с логированием.
При этом вывод планировался в XML. Так что мы любим и уважаем XML и XSD.
Просто пока есть только конфиг использующий Jackson databind.
Я буду рад добавить фичу! Делать XML конфиг? (будем рады сослаться на Ваш профиль в Хабре в описании issue на Гитхабе!)
Выглядит тоже не очень! Но идея в скриптах — возможно кто-то из пользователей найдет идеальный вариант. Каждый может использовать свой подход к написанию скрипта.
Ограничение вызвано интерпретацией кода в GString на этапе компиляции Груви класса, при использовании «$переменная».
если честно, я очень боялся что лишние ссылки будут выглядеть как само-PR (очень хочу чтобы этот проект стал «народным»). Поэтому понадеялся на авось, что у всех JCenter прописан. Прошу прощения!
Пожалуйста, пропишите репозиторий JCenter и попробуйте собрать.
PS: m2 репозиторий это внутренний репозиторий для m2, артефакты из него автоматически привязываются к JCenter.
да, удовольствие тоже! И мы оба не упоминули ещё один фактор — возможность коммереского применения полученных навыков. Т.е. отточил человек навыки на OSS проекте, а потом сделал коммерческую фирму с похожим профилем. Или даже задействуя свои собственные наработки.
Это всё равно что просить друзей пришедших на ваш День Рождения убрать у вас в комнате.
Это такая же работа, только оплачивается репутацией — которую при желании можно разменять на высокооплачиваемую позицию в фирме.
и Вас спасибо за отличный вопрос!
Кстати, забыл ответить на счёт «выносливости»: также тестировали на предмет деградации производительности при длительном использовании.
И ещё один момент: нужно будет повторить тесты под раздными JVM, пока не делали этого.
Расскажу как производилась оптимизация footprint этого логерра по отношению к CPU, RAM и влиянию на GC, а также как выбиралась архитектура и принципы разработки исходя из общей производительности:
— Тестовый стенд представляет собой гибридное Spring Boot приложение, имеющее около 150 постоянных потоков, как синхронизированных, так и постоянно работающих в фоне.
Он использует JPA, Hibernate, Groovy, REST. Стенд нагружался до степени, которая позволила выявить большое количество багов по потокобезопасности.
Влючалось логирование SQL и binding в JPA/Hibernate. Ну и самое главное — стенд использовал Blackbox, который логировал буквально каждый expression в коде бизнес логики. Т.е. вывод примерно 25Мб/с логов. Около 400 одновременно записываемых файлов.
— Была произведена первоначальная оптимизация при помощи нашего другого проекта Speedometer (пока на стадии разработки) — AST профайлер.
— Затем производился последовательный анализ вносимых изменений используя Java Visual VM. Анализировалось потребление CPU и особенно памяти и эффективности GC.
Как результат были выработаны и внедрены следующин принципы:
1-статическая компиляция всех классов (мы используем новый Groovy Enterprise Plugin)
2-отказ от использования синтаксиса форматирования аргументов, использованного в Slf4j (это кошмарная идея была изначальнл в Slf4j)
3-полное отсутствие synchronized блоков и методов
4-отказ от MDC/ThreadLocal — это вызывает проблемы для GC (тем не менее мы оставили поддержку встроенного MDC из Slf4j)
5-минимизация использования коллекций и особенно потокобезопасных коллекций. Это в первую очередь касается “@Memoized” — он очень сильно замедляет работу.
6-для замены Memoized была разработана другая аннотация “@CacheFieldInit”
7-минимизация создания экземпляров классов. По возможности используются только аргументы методов. Это очень сильно помогает GC, и непонятно почему этим пренебрегли в Logback.
8-скрипты из файла настройки статически компилируются в Груви класс используя GroovyClassLoader — это дает наилучшую производительность
9-потокобезопасность строится на принципе потоковой изоляции стеков операндов вызовов методов, избегая необходимость какой-либо синхронизации
Анализировались Heap Dumps, профайлер и разные статистики. Искались memory leaks.
Это был очень стрессовый процесс с пересиживаниями в ночь на протяжении 1.5 месяца. Иногда руки опускались и казалось что все напрасно.
Но конечный итог оправдал все надежды — у меня не было времени сохранить конкретные значения, но скажу так: по Java Visual VM logback выглядел… жирно — по сравнению с нашем логгером.
Если коротко — Bobbin быстрый. Очень быстрый. И экономит память.
Так же есть список todo: посмотреть как влияет opcodes.FINAL на GC в применении к операндам методов; протестировать производительность на других платформах кроме Windows.
Так что фичи должны быть востребованы, иначе получается мертвый груз затрудняющий рефакторинг.
В идеале набор опций таков:
— xml, json, yaml конфиги
— groovy конфиг
— dsl конфиг
Начнем с yaml добавлять! По остальным проведем небольшой анализ и опрос.
А вот yaml отличная идея. Добавил заявку: github.com/INFINITE-TECHNOLOGY/BOBBIN/issues/17
Спасибо!
Причина такая на мой взгляд: иначе получается смешение функциональностей и выходит супер библиотека, делающая всё.
А независимая библиотека априори более функциональная и качественная.
Да, так сделано в других логгерах. Например в Logback эти настройки применимы только к FileAppender, но в случае SiftingAppender появляются ограничения: jira.qos.ch/browse/LOGBACK-1442
Поэтому настало время принять правду — в Logback это архитектурно неправильно реализовано… Как Вы думаете?
Но dsl имеет другие недостатки — а именно непрозрачный синтексис.
Но опыт показывает, что иногда пользователю может наоборот помешать доп. обработка — поэтому пока было сделано так. Пример:
В этом случае имя лог файла равно имени треда. Но если взять насильно это в кавычки (за пределами JSON), смысл потеряется и переменная станет константой.
Документация на вики проекта в github обновленная, пожалуйста используйте ее:
github.com/INFINITE-TECHNOLOGY/BOBBIN/wiki
Сайт (не буду указывать ссылку дабы избежать рекламы) немного отстает и будет скоро обновлен!
Попробуйте из репозитория Jcenter:
Весь код использует только статическую компиляцию (через Groovy Enterprise Plugin).
Это сочетание обеспечивает наилучшую производительность (протестировали все возможности изначально).
При этом вывод планировался в XML. Так что мы любим и уважаем XML и XSD.
Просто пока есть только конфиг использующий Jackson databind.
Я буду рад добавить фичу! Делать XML конфиг? (будем рады сослаться на Ваш профиль в Хабре в описании issue на Гитхабе!)
Отличный вопрос! и я рад продемонстрировать гибкость скриптовой настройки, можно настроить без escape characters:
Выглядит тоже не очень! Но идея в скриптах — возможно кто-то из пользователей найдет идеальный вариант. Каждый может использовать свой подход к написанию скрипта.
Ограничение вызвано интерпретацией кода в GString на этапе компиляции Груви класса, при использовании «$переменная».
если честно, я очень боялся что лишние ссылки будут выглядеть как само-PR (очень хочу чтобы этот проект стал «народным»). Поэтому понадеялся на авось, что у всех JCenter прописан. Прошу прощения!
Пожалуйста, пропишите репозиторий JCenter и попробуйте собрать.
PS: m2 репозиторий это внутренний репозиторий для m2, артефакты из него автоматически привязываются к JCenter.
Приветствую valery1707!
Спасибо за комментарий! Репозиторий JCenter. Можете попробовать пожалуйста?