📢 Load & Performance

Отлаживал HTTP-тесты, написанные на Gatling, через прокси-сервер. И так как тесты уже разрослись, то в данных прокси-сервера Proxyman все слилось. Понять, какие запросы из какого теста стало сложно

Здорово, что
🤩 можно добавить любые заголовки запроса в Gatling
🤩 получить текущее имя класса в Java
🤩 отобразить заголовки запроса в ProxyMan

static String name=this.getClass().getSimpleName();
...
http("name").get("/")
  .header("X-NAME", name)

Так отладка пошла куда веселее

Ссылки
🤩https://docs.gatling.io/reference/script/http/request/#headers
🤩https://stackoverflow.com/questions/6271417/java-get-the-current-class-name
🤩https://docs.proxyman.com/basic-features/custom-header-column

Представьте, что вы отвечаете за доступность и корректность работы большой системы, и у вас может быть есть явная роль SRE. Но вы так хорошо работали, что нет ни алертов ни проблем

Или вы запустили тест производительности, а он прошел хорошо, также как обычно, и даже никаких дефектов не завести ...

... кажется, что не завести никаких дефектов

На этот случай рекомендую открыть логи и посмотреть на их количество. Моя любимая фича в хранилище логов OpenSearch это Top 5 values по ключевым полям логов. А любимые поля это

🤩service, чтобы отфильтровать по сервису
🤩source или file, чтобы выбрать конкретный лог, если сервис пишет несколько логов
🤩level, чтобы оставить ERROR или WARN
🤩class (иногда это называется logger)
🤩message с текстом сообщения

Обычно достаточно сделать фильтры по
🤩service = главный сервис
🤩source = основной лог
🤩level = ERROR
и посмотреть на TOP-5 по полю
🤩class

Потом можно сделать фильтрацию только по TOP-1 значению, получить messages от этого класса, часто они будут очень похожи друг на друга. И тут вы сможете понять, что вот она ошибка, скрывалась, но нашлась

Такие удобные фильтры как TOP 5 values есть и OpenSearch Dashboard и в Kibana и в Grafana

Ни теста без дефекта!!

Интересная новость — Брендан Грегг будет заниматься производительностью ChatGPT в OpenAI

https://www.brendangregg.com/blog/2026-02-07/why-i-joined-openai.html

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

Задали мне сегодня вопрос «Есть ли у меня план-бекап?» И вопрос был задан в контексте того, а вот отключится все электричество года так на два — двадцать два — что будешь делать?

И тут я подумал, что нагрузкой больше заниматься не буду.

Надо бы научится чему-то полезному, людей лечить, например, или зверей хотя бы. Существо я социальное, хоть и проводил в лесах и горах много времени, но жить там полностью автономно не смогу. А по-хорошему мне в такой ситуации хотелось бы проделать путь длиной примерно в 3-4 месяца пути (пешком или на транспорте, как велосипед), родных проведать. На таком пути будет здорово знать языки и уметь людям помогать как-то

Интересный был урок по английскому

А еще сегодня день рождения 💻 JetBrains отмечали. У нас было в альпийском стиле с баварскими закусками, но на обед были пельмешки, вот так подарок 🎁

Если потеряю нагрузку, буду ценить те моменты, когда занимался ею, потеряю комфорт, буду ценить его, как пельмешки

Задали мне сегодня вопрос: «А зачем ты это оптимизировал»? Но в вежливой европейской форме: “Какая доля потоков занята этими запросом”?

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

🤩 А считать конечно же надо было до, в потом и после, чтобы показать эффект

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

Есть в nginx такая метрика upstream_response_time, думаю что она поможет мне сделать подсчет по access логам . Напишу потом как получится

Не будьте как я — считаете метрики с важностью оптимизации до оптимизации

Год назад начал разбирать Memory Leak при просмотре результатов теста во View Result Tree, для случая больших файлов в запросах или ответах

Это задача 6336, разобрал тогда в какие моменты выделяется память и что она не очищается даже после Clear All.
Автор дефекта получил проблему на больших запросах (Request), а я проверял на ответах (Response)

Некоторые наблюдения из этого разбора
🤩тема System работает на 2 минуты быстрее темы Darklaf - Dracula (detault) при открытии результатов теста с большими файлами
🤩настройки на лимиты размеров текста при отображении, не делают объем хранимиго в памяти текста меньше — думаю что можно оставлять только начало ответа еще при загрузке результатов
🤩дедупликация строк не используется, если открыть два одинаковых ответа или запроса, то память выделится тоже дважы

Тут я говорю про настройки JMeter

## MAX_DISPLAY_SIZE
view.results.tree.max_size=10485760

## MAX_LINE_SIZE
view.results.tree.max_line_size=110000

## SOFT_WRAP_LINE_SIZE
view.results.tree.soft_wrap_line_size=100000

И настройку OpenJDK

## Дудупликация строк
-XX:+UseStringDeduplication

## Работает с G1GC:
-XX:+UseG1GC

## Сколько поколений сборки мусора надо пережить (3 по умолчанию)
-XX:StringDeduplicationAgeThreshold=1

## Надо будет добавить 100ms к длительности пауз (по умолчанию в JMeter 100)
-XX:MaxGCPauseMillis=200

Этот гештальт пока висит незакрытым. Вот думаю что пора его закрыть.

🤩Докрутить задачу с утечкой памяти именно для больших запросов.
🤩Сделать так чтобы в памяти ViewResultTree читались только первые
view.results.tree.max_size=10485760 байт, если результат загружается из файла (при просмотре результатов в live-режиме обрезать результат нельзя)
🤩исследовать есть ли лимит на отображение тела запроса (не только ответы могут быть большими)
🤩возможно обосновать, что красивая и темная Darklaf - Dracula тема слишком медленная и вернуться к System, как варианту по умолчанию
🤩добавить явное указание String.intern() для некоторых больших строк (думаю это точно нужно только для JMX-файлов и для тел запроса в режиме чтения тела запроса из файла
🤩включить по умолчанию UseStringDeduplication и подтянуть настройки G1GC так, чтобы дедупликация эффективно работала
🤩разобраться почему Clean All не приводит к освобождению памяти во View Result Tree

Задача вроде простая и короткая на входе. Но работы там зарыто немало. Да и на работе в YouTrack задачи примерно такие же, если не в 10 раз сложнее, и надо их разбирать первым приоритетом

Но если начать сообща разбирать дефект по дефекту, то разберем. Что думаете?

Свои первые замеры производительности делал читая логи

Привет любители производительности, когда-то вел таблички в базе знаний с метрикам производительности. База знаний у нас была на Microsoft Sharepoint. Я учился в университете по направлению Интеллектуальные системы управления, онтологии и инженерия знаний. И фанател от Матрицы. А база знаний у нас в команде пустовала

И начал заполнять базу знаний метриками:
🤩как долго строится отчёт
🤩как долго делается поиск при разных параметрах
🤩как долго делается импорт
🤩сколько времени проходит между событиями в логах — 🤩 вот это была золотая жила метрик

По логам получались точные замеры, а менее точные делал через специальную программу-таймер

Тогда открыл для себя, что если просто открыть логи и внимательно посмотреть в них, то можно многое увидеть:
🤩что процесс начался в 08:30
🤩обработал 120 000 объектов
🤩завершился в 09:40

Значит:
🤩70 минут на 120000 объектов или 35 ms на объект для версии … и конфигурации …

И посмотреть в логи, увидеть там суть, записать данные, посчитать метрики, оценить их — это тоже замер и тест производительности

Тогда для меня это было открытием. И я до сих пор делаю тесты и замеры по логам. Если есть что-то фоновое и медленное — добавляю в код логи или прошу коллег добавить. А еще лучше с прогрессом:

08:30 - start
08:33 - 1000/120000
08:36 - 2000/120000
…
09:40 - 120000/120000
09:40 - finish

Есть в профилировании JVM сложная задача — посчитать количество итераций в каждой строке за счет наложения на данные семплирующего профайлера (Sampling) данные трассировки (Tracing) и подсчета количества выполнений (Call counting)

Режим Sampling
дает самые меньшие искажения и почти незаметен для профилируемого сервиса, по нему можно понять, что какая-то строка кода выполняется, например, 60% времени

По данным семплирования удобно строить Flame диаграммы, как на скриншоте

И данная строка может быть горячей по разным причинам:
🤩медленная операция которая потребляет CPU
🤩выделяет память
🤩походы на диск
🤩походы по сети
🤩и может быть это супер быстрый код, но который вызывают 1 000 000 раз в цикле

Вот в этом последнем варианте причина медленной работы в том методе который вызывает данный метод 1 000 000 раз

Это довольно частый случай. А технически задача становится такой:
🤩собрать статистику по количеству выполнений методов
🤩наложить статистику с количеством на данные семплирования

Сбор статистики по количеству выполнений бывает двух видов
🤩без номеров строк и вышестоящих запросов (Call Counting) — быстрый
🤩с номерами строк (Tracing) — медленный

В Call Counting попадают абсолютно все вызовы данного метода, и если метод — это некий популярный интерфейс, как EntityIteratorBase.hasNext, то по нему будут миллионы вызовов в статистике, даже если в профилируемой операции он вызывался 10 000 раз только. Обычно такие методы в начале или середине стека. Они есть при каждом HTTP-запросе и каждой операции и Call Counting покажет для них очень высокие значения.

Но вот для уникальных строк в конце стек-трейса, таких как Delegator.checkPage (вершина Flame graph), Call Counting будет работать очень точно. Он покажет точные значения. Потому что чаще всего это узкое место уникально для этого запроса. А еще будут точные значения про метод который вызывал этот метод. И может быть про предыдущий

Как понять, что числа в Call Counting более менее настоящие

Например, смотрим на метрики сверху вниз

🤩DataIterator.checkPage — 27 000 000 вызовов
🤩PatriciaTreeBase.getDataIterator — 5 000 000 вызовов (такое может быть, этот метод вызывает checkPage примерно по 5-6 раз)
🤩PatriciaTreeBase.getLoggable — 5 000 000 вызовов (такое может быть, он вызывает getDataIterator только один раз)
🤩PatriciaTreeBase.loadNode — 5 000 000 (ok)
🤩ChildReference.getNode - 1 600 000 (этот вызывает loadNode 3 раза)
🤩PatriciaTraverser.moveDown — 80 000 000

Тут я выдумал число 80 000 000 для сокращения, но если вдруг количество по вышестоящему методу резко выроcло, а не упало — то это означает, что дальше метрикам Call Counting верить нельзя. Они свое отработали, показали для методов нижнего уровня сколько вызовов приходится на следующий:
🤩x5, x1, x1, x1, x3, x???

Дальше можно продолжать разматывать стек, но уже держа в голове, что это замусоренные данные.

И в какой-то момент придется переключиться на данные трассировки. Это самые неточные данные. Трассировка хоть и самая детальная, но вносит столько изменений и замедлений в код, что часто выполнение кода становится уже неполным (завершается по таймауту) или искаженным. Она покажет неполные данные — например скачок в x218208 на данных трассировки в реальности может быть и скачком в x1000000, но код просто не дожил то итерации в 1 000 000 и прервался на 218208. Но это лучшая оценка

Все такие множители удобно записывать в виде комментариев к строкам стек-трейса — просто через //

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

Пока собираются сборки, качаются репки и горят токены, поделюсь подходом к одной игре. Играю я в 📱Linkedin, цель игры — собрать много Connect-ов

Есть ограничения:

1️⃣ нажать кнопку Connect можно ограниченное количество раз, примерно 80 в неделю
2️⃣ в списках, таких как результаты поиска, не показывается отправлен ли Connect уже этому человеку, можно потратить Connect дважды
3️⃣ если открывать страницы в браузере, чтобы проверять не было ли уже отправки, то ваc признают ботом
4️⃣ если накопить много Connect-ов без ответов, то лимиты еще ниже 80-ти в неделю — например 10-20

Рекомендации, как играть в эту игру гласят, что стоит отправлять персонализированные приглашения и растягивать процесс на неделю

Но есть интересное скрытое ограничение:

5️⃣ многие пользователи не используют Linkedin, но учетные записи у них там есть — это мои коллеги, друзья, приятели, ... и докладчики с недавней конференции тоже

Поэтому, работает вот что:
🎚 играть в эту игру с теми кто комментирует и ставит реакции на интересные вам посты — это активные люди
🎚 пробовать писать свои, и смотреть кто отликнется на них

Если вы уже в бане, то можно нажать Follow на человека, который активен в интересующей вас теме:

🍀 высока вероятность что в ответ вам прилетит нужный Connect
✅ а ваша лента наполнится рекомендациями исходя из активностей людей, которые вам интересны

Например: найти сообщения по фразе Performance testing за неделю и Follow-ить авторов комментариев

Игра интересная, давайте играть вместе. Присылайте в комментариях ссылку на свой профиль, а вот мой:
https://www.linkedin.com/in/v8v/

Сегодня взял небольшой отпуск и пошёл в кафе в горах почитать, просмотреть, покушать. В некоторых горах есть кафе!!! Да, надо добраться сюда, но …

🤩🤩🤩🤩🤩🤩🤩🤩🤩

Нагрузочных историй пока нет, но нашел вот эмоджи интересные

🤩🤩❤❤❤❤❤❤❤

Можно ими порадовать близких

❕❕❕❕

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

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

〰️〰️〰️〰️〰️〰️〰️〰️

Еще подумал, что данный канал выглядит для вас не как summary чата нагрузки, а как дневник одного человека. Может переименовать в дневник

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

И тут коллега говорит — смотри, сжатие файлов БД перестало работать

Причина медленной работы получилось из-за ошибки, из-за которой остановилось автоматическое сжатие (что-то типа auto vacuum), из-за остановки которого файлы данных с измеренными/удаленными записями стали содержать меньше нужных данных и больше ненужных, из-за чего поиск нужных данных замедлился. А чинится это запуском сжатия вручную один раз (что-то типа vacuum), после чего автоматическое сжатие снова работает

Прочитал новости про закат StackOverflow как площадки, где эксперты отвечали на вопросы. Вопросы теперь задаются не экспертам, а чатам с моделями, натренированными на StackOverflow

В чате qa_load вопросов тоже не так чтобы много, потому-то модели ответят быстрее, чем люди в чате

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

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

Прошел год и оно заработало!

Год назад начал маркировать тегами с именем api endpoint все дефекты по инцидентам. И делал это год, иногда каждый день, иногда раз в неделю — разбирал каждый скачок времени отклика

И вот уже две недели эти теги работают на меня — фильтрую по ним инциденты, а там уже все разобрано. Можно дополнять профилированием посвежее да и только

Ставить теги на задачи полезно

Привет performance lovers! Вы когда-нибудь участвовали в выборе хостинга, сервиса, продукта в вашей компании. Например, в рамках технического комитета, где надо было оценить варианты с точки зрения производительности

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

✨Оценка делается на основе статей и мнения разработчиков решения?
✨Оценка на основе мнения экспертов из индустрии?
✨Оценка делается исходя из того, что друзья/партнеры/конкуренты используют это решение?
✨Независимая экспертиза и услуги консалтеров?
✨Внутренняя оценка, и делаются сравнительные тесты, внутренние пилоты?
🎄или не играет большой роли производительность

🍪 Поделитесь мыслями или своим опытом. Можно в личные сообщения @smirnovqa

❤ Всем отличной субботы, а тем у кого уже воскресенье — отличного воскресения

Пеку блины и читаю книгу "Производительность систем" (Брендан Грегг, 2023, Питер) — какая крутая книга. Я читал только предыдущее издание, и вот дошел до этой части, тут уже Ubuntu и eBPF

Однозначно рекомендую

Напишите в комментариях какие вы книги читали в этом году и рекомендуете ли их?