📢 Load & Performance

Hello git lovers!

Неделю выбирал
🤩rebase или
🤩merge

Я работаю в своей ветке, и иногда мне нужно подмержить в свою ветку основной develop, и продолжить работу, подмерживать буду несколько раз. Для такого сценария ничего проще merge не придумали

Но я попробовал делать rebase основной ветки в свою

Один раз можно сделать rebase, а вот если два, то нужно

rebase —-onto …

с указанием базы, тут легко ошибиться. И вот этот второй rebase превращается в сложную задачу. Где ради ровного лога надо сидеть и высчитывать коммиты

merge

экономит время и мыслетопливо — предсказуемый результат, просто указываешь основную ветку и все хорошо, конфликты только там где они были, а не во всех перемещенных коммитах

Hello performance lovers!

Настроил IntelliJ IDEA Plugin — Pretty JSON Log
https://plugins.jetbrains.com/plugin/24693-pretty-json-log
для Gatling

В файле log4j2-test.xml достаточно написать, что будет использоваться JsonTemplateLayout для консоли

    <Appenders>
        <Console name="CONSOLE">
            <JsonTemplateLayout/>
        </Console>
    </Appenders>

И добавить зависимости в проект:

    implementation platform('org.apache.logging.log4j:log4j-bom:2.25.3')
    runtimeOnly 'org.apache.logging.log4j:log4j-layout-template-json'

И получаются отличные разноцветные логи в консоли. Статистика Gatling отображается просто серым, а сообщения
🟡 INFO
🟠 WARN
🔴 ERROR
отображаются нужными цветами

Началось все с того, что стал настраивать сохранение логов Gatling-теста в ELK, прочитав что Павел Байров подготовил

🖇 https://github.com/Amerousful/gatling-elasticsearch-logs

У нас на проекте используется log4j2, поэтому настройку стал делать под этот формат:
https://logging.apache.org/log4j/2.x/manual/json-template-layout.html

И тут выяснилось, что если JSON логи писать сразу в консоль, то они еще становятся с подсветкой

Сам себя обманул 🤦‍♂️ с профилированием

Настроил на тестовом стенде YourKit profiler с опцией periodic_perf=300 (сохранять снимок на диск раз в 300 секунд). Настроил и забыл

Смотрю на результаты тестов, и раз в 300 секунд скачки на графиках. Мой коллега называет их "вздрыжнями"

🤩Сборка мусора на приложении подумал я, проверил — все хорошо
🤩Сборка мусора на gatling подумал я, проверил — все хорошо
🤩Снизил нагрузку — все равно раз в 300 секунд
🤩И тут я понял, что все дело в профилировании, оно при сохранении блокирует работу потоков ненадолго, на 5-10 секунд, но на графиках это заметно

✅ Отключил periodic_perf=300, убрав этот параметр из строки запуска агента профилирования

https://www.yourkit.com/docs/java-profiler/2025.9/help/agent-startup-options.jsp#trigger

Вот такая получилась строка:
-agentpath:/tools/libyjpagent.so=port=10001,listen=all,probe_table_length_limit=100000,sessionname=youtrack-perf-test,dir=/opt/youtrack/logs,logdir=/opt/youtrack/logs,tmp_dir=/opt/youtrack/temp,triggers_out_dir=/opt/youtrack/logs,cpu=sampling,deadlocks_check_period=10,monitors=on,on_exit=snapshot,snapshot_name_format={app_name}-{datetime},app_name=youtrack_standalone

И стало ровнее

Hello performance lovers!

Как посчитать минимально необходимое время прогрева перед тестом производительности? На примере Gatling

💡 Самый интересный момент тут в том, что надо сложить и первое время отклика и длительность нестабильности

1️⃣ Была у меня проблема в тесте
В самом начале теста
🤩нагрузка была не самой ровной и
🤩время отклика подскакивало до 10 секунд

2️⃣ Нужен прогрев. Но как долго прогревать?
Можно заметить, что
🤩первые ответы имеют длительность 10 секунд
🤩значит, запросы были отправлены за 10 секунд до отображения этих результатов
🤩и еще 12 секунд после этого время отклика и RPS были нестабильны

Значит прогрев нужен на 22 секунды. А лучше на 30, с небольшим запасом

3️⃣ Для Gatling и Junit (BeforeAll) нужен статический метод запуска
🤩можно передать в параметры запуска
🤩🤩GatlingCliOptions.NoReports
🤩🤩GatlingCliOptions.Simulation
🤩🤩GatlingCliOptions.ResultsFolder
🤩указать что метод запуска static
🤩и запускать его как step_7_warmUp() в @BeforeAll


4️⃣ Прогрев дал результат
🤩Нагрузка стала ровнее

Hello performance lovers!

Я большой любитель тетрадей и блокнотов. В Ижевске в шкафу лежит сумка с записями. В Москве еще одна. В Мюнхене стопка. А в рюкзаке всегда со мной пара блокнотов

Некоторые тетради и блокноты очень старые. Больше всего мне пригодились блокноты с контактами и паролями, начал вести их осознанно и регулярно, где-то в 2007-м

🤩записи с контактами были очень актуальны, когда на SIM-карту помещалось несколько десятков контактов, а телефоны менялись/ломались раз в год без возможности переноса контактов между устройствами
🤩записи с паролями стали актуальны, когда погрузился в безопасность и стал делать сложные уникальные пароли на каждый случай, а случаев было много, сотни

Блокноты переживают переезды, повреждения жестких дисков, смену сервисов — бумага очень надежный носитель информации, который устойчив к нагрузкам

Тут стоит сказать и что можно записать, и куда, и чем. И поделиться хочу находками:

🤩Ручки Pilot, конкретно FriXion, 0.5 — шариковые роллеры с тонкой и легкой линией, и со стирающимися быстросохнущими чернилами. Писать ими легко, чернила негустые
🤩Еще не видел плохих ручек с шариком 0.5 и не видел плохих ручек от Pilot
🤩Часто можно найти в магазинах ручки 0.7 — больший шарик, чуть больший расход чернил, и они более густые, поэтому нужно больше сил прилагать. Но тоже хорошо
🤩Гелевые пишут легко, но расход большой и они сохнут дольше или даже мажут — нужна плотная бумага (90 g/m2) и нужно ждать пока все высохнет перед закрытием
🤩А в школе у меня, думаю, были ручки 1.0, с большим шариком, и там усилий надо было много — часто их расписывал, ведь большой шарик засыхал, а то что колпачок надо закрывать я не думал

Хорошую бумагу я открыл для себя в 2018-м. Это был блокнот 📓 70 g/m2, который я забыл где-то в переговорке Райффайзен банка и так и не нашел. И бумага такой плотности была просто шелковой по сравнению с тетрадками, которые использовал ранее

Да есть у блокнотов минус — их можно забыть. Поэтому удобно хранить важную бумагу в рюкзаках, а не в руках

Большая удача найти тетрадь на спирали с плотностью 90. Почему удача — с такой плотностью часто продают более дорогие красивые блокноты в толстой обложке, обложка изумительная, бумага тоже, но часто они сделаны как книга, и их сложно разложить на столе не помяв. А вот спиральки раскладываются без помятия. Слышал и про японские блокноты, которые раскладываются без помятия, хоть и не используют спирали, но не пока не было опыта, не видел их

Это была заметка про
🤩ручки 0.5
🤩бумагу 90
🤩и спирали

Сделал Drill Down по логам сегодня в Grafana. За счет
🤩трёх разных dashboards в которые можно переходить с передачей в них переменных типа Text
🤩Table panel, которая хорошо показывает логи (лучше чем панель Logs), но надо применить трансформацию Extract fields / _source / key+value
🤩И поверх этого Extract Fields с RegExp

Вот представьте что у вас есть в логах строки, которые на поля не парсятся, а там в теле сообщения есть и имя потока и метод и имя сервера. Вот Extract Fields с RegExp может разобрать такие строки на поля уже в браузере

А когда это станет полями, то Table panel активирует Data Links и эти поля становятся кликабельными фильтрами для других досок

Сегодня интерны вышли на работу, ко мне тоже

Будем вместе делать мониторинг для YouTrack. Продукт сразу будет идти с мониторингом и алертами

Пусть получится и коллегу себе подготовить и продукт

А через два дня открывается подача заявок на новый набор интернов в JetBrains. Там есть проект по предсказанию метрик в облаке. Менторы будут в Амстердаме

Кому это нужно?

Привет performance lovers! Как perf инженер я перфекционист, и перевел этот свой недостаток в преимущество. И главный вызов для меня в 2026-м не ИИ, а продуктовый подход, который идет в сторону от технической работы

То, что от ожидается от старшего инженера можно попробовать описать вопросом — Кому это нужно?

Хоть вопрос и звучит просто, он означает, что нужно проделывать довольно большую и важную работу, снова и снова

было:
🤩настроить профилирование, трассировку, логирование
🤩тестовые данные, тесты, метрики
🤩провести тест, выявить узкие места
🤩и оформить лаконичный воспроизводимый дефект с достаточным контекстом

стало: и еще …
🤩изучить какие клиенты когда и почему это используют
🤩на сколько важная это группа
🤩как они используют эту функциональность с узким местом
🤩как она настраивается
🤩как выглядит для пользователя замедление

В индустрии, сосредоточенные на этом вопросе роли называются Product engineer

Я пока на пути к этому уровню, и не могу сказать, как оно. Но знаю, что именно это от меня сейчас ждут

☕️ Есть такая JVM библиотека Caffeine, отличная. Можно строить с ней кеши где у ключей есть срок годности

И вот я писал тесты с OAuth токенами. И подумал — вот возьму библиотеку готовую для токенов, не буду делать на ConcurrentHashMap-е

Взял. Сделал тест с Gatling. Уперся в ❎ DeadLock, когда одновременно ключи добавлялись, читались, и выполнялся внутренний CleanUp для Caffeine

Починил пока написав обертку над Caffeine-вой Map-ой, которая ставит 🔒 RetainLoc, что на чтение, что на запись. Сделал однопоточный кеш. Вроде все хорошо теперь. Может немного потерял в скорости, но отказываться от удобной таблицы уже не хотелось

Привет performance lovers!

Есть такое состояние мониторинга, когда метрик нет, и это интересная и большая проблема

Некоторые инструменты показывают в это время ровные линии, которые соединяют две точки — эта техника реализована во многих инструментах от Microsoft и например в YourKit Java Profiler

👨‍⚕️👩‍⚕️ С такими инструментами чувствуешь себя ❤️ сердечным доктором

Некоторые инструменты не собирают метрик и не показывают их в такие моменты, чем показывают что проблема была и она серьезная

Такие инструменты мне нравятся больше, на них видно, что ничего не видно

Одной из возможных причин такого поведения бывает недостаток памяти по причине ее активной аллокации, и ресурсоемкий процесс освобождения занятой памяти, который вытесняет и ставит на паузу все средства мониторинга

Как найти причину зависания, если метрик нет? Поделюсь мыслями про
🤩логи сервера с исключениями
🤩обрывки профилирования
🤩логи и метрики клиентов

Заходите в комментарии, будем разбираться и лечить

Отлаживал аутентификацию OAuth. Кто знает про передачу JWT-токенов в относительных ссылках для GET-запросов, те знают, что относительные ссылки (которые #token={JWT|base64}) не всегда отображаются в прокси-серверах или даже на вкладке Network.

И я не сразу вспомнил про это и немного плутал. Чтобы лучше запомнить, да и вам напомнить, поделюсь картинками:

🤩В Network в секции Response Headers в заголовке Location для первого-второго запроса будет JWT-токен
🤩В Console если включить логирование запросов тоже будет виден JWT-токен, уже просто в Requests URL

🤩Но вот в Network в Request URL относительных ссылок не будет видно в браузерах
🤩И в прокси-серверах тоже относительные ссылки не показываются, например в ProxyMan, в URL

Это тот тонкий момент, когда параметры запроса есть только в предыдущем ответе и они скрываются при отображении этого запроса, почти везде