820
Избранные материалы о тестировании производительности. Чат и источник тем: @qa_load
Hello performance lovers!
Мне понадобилось написать тесты на десятки методов (HTTP API, SSE, WebSocket) и для каждого метода есть еще по несколько вариантов Query String или тел запросов
Также мне хотелось использовать Gatling throttle, для ровной нагрузки по RPS. А для этого надо было сделать сценарии длиной в один запрос — только так работает throttle
Сделал каждый запрос реализацией интерфейса IEndpointChainBuilder
🤩это позволило работать с каждым из них в едином виде
🤩например, добавлять такие методы в Registry методов где будет указан вес метода (влияет на вероятность вызова) и Lambda которая вызывает IEndpointChainBuilder.build()
За основу профиля нагрузки взял randomSwitch().on(...)
🤩это позволяет запускать все методы с весами
🤩подметоды методов можно тоже запускать с весами (randomswitch может быть вложенным)
🤩веса вычисляет класс-утилита Registry, который на вход принимает количества и сам вычисляет проценты в этой группе
Так как часть методов связаны — некоторые ответы являются основной для других запросов, — то добавил механизм Adapter-ов которые добавляют общие классы-хранилища (потокобезопасные Queue или Map) в связанные запросы
🤩атомарные запросы связаны не через Gatling Session, а через общие Queue и Map, заданные через Adapter-ы
Получился расширяемый проект
🤩легко добавить новый метод
🤩легко скорректировать актуальное количество (вес) каждого метода
Чтобы было проще отлаживать добавил к заголовкам каждого запроса X-TEST-NAME, где содержится имя теста:
🤩по заголовкам запроса легко отследить запрос на прокси-сервере как ProxyMan.io
Концепт написал и отладил руками, опираясь на знание Gatling DSL. И когда первые тесты были готовы и отлажены, то за работу по добавлению новых методов и вариаций тел и параметров запросов взялся AI агент Junie, который встроен в 💻 ItelliJ IDEA
Закодировать методы и добавить адаптеры по спецификации агент может с помощью как Gemini так и Opus, выбор модели не так важен
Отладка пока осталась на мне. Но процесс понятный
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'
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️⃣ Прогрев дал результат
🤩Нагрузка стала ровнее
Сделал Drill Down по логам сегодня в Grafana. За счет
🤩трёх разных dashboards в которые можно переходить с передачей в них переменных типа Text
🤩Table panel, которая хорошо показывает логи (лучше чем панель Logs), но надо применить трансформацию Extract fields / _source / key+value
🤩И поверх этого Extract Fields с RegExp
Вот представьте что у вас есть в логах строки, которые на поля не парсятся, а там в теле сообщения есть и имя потока и метод и имя сервера. Вот Extract Fields с RegExp может разобрать такие строки на поля уже в браузере
А когда это станет полями, то Table panel активирует Data Links и эти поля становятся кликабельными фильтрами для других досок
Кому это нужно?
Привет performance lovers!
Есть такое состояние мониторинга, когда метрик нет, и это интересная и большая проблема
Некоторые инструменты показывают в это время ровные линии, которые соединяют две точки — эта техника реализована во многих инструментах от Microsoft и например в YourKit Java Profiler
👨⚕️👩⚕️ С такими инструментами чувствуешь себя ❤️ сердечным доктором
Некоторые инструменты не собирают метрик и не показывают их в такие моменты, чем показывают что проблема была и она серьезная
Такие инструменты мне нравятся больше, на них видно, что ничего не видно
Одной из возможных причин такого поведения бывает недостаток памяти по причине ее активной аллокации, и ресурсоемкий процесс освобождения занятой памяти, который вытесняет и ставит на паузу все средства мониторинга
Как найти причину зависания, если метрик нет? Поделюсь мыслями про
🤩логи сервера с исключениями
🤩обрывки профилирования
🤩логи и метрики клиентов
Заходите в комментарии, будем разбираться и лечить
Отлаживал HTTP-тесты, написанные на Gatling, через прокси-сервер. И так как тесты уже разрослись, то в данных прокси-сервера Proxyman все слилось. Понять, какие запросы из какого теста стало сложно
Здорово, что
🤩 можно добавить любые заголовки запроса в Gatling
🤩 получить текущее имя класса в Java
🤩 отобразить заголовки запроса в ProxyMan
static String name=this.getClass().getSimpleName();
...
http("name").get("/")
.header("X-NAME", name)
Интересная новость — Брендан Грегг будет заниматься производительностью ChatGPT в OpenAI
https://www.brendangregg.com/blog/2026-02-07/why-i-joined-openai.html
У него было 26 интервью и встреч, и он делал свой выбор тоже, выбирая по степени полезности проектов для людей вокруг и наличию друзей в компании
Задали мне сегодня вопрос: «А зачем ты это оптимизировал»? Но в вежливой европейской форме: “Какая доля потоков занята этими запросом”?
И в данном случае я и правда оптимизировал то, что было легко сделать, не посчитав предварительно на сколько это критично в числах
🤩 А считать конечно же надо было до, в потом и после, чтобы показать эффект
Как посчитать какая доля потоков на бекенде была занята таким вот запросом?
Есть в nginx такая метрика upstream_response_time, думаю что она поможет мне сделать подсчет по access логам . Напишу потом как получится
Не будьте как я — считаете метрики с важностью оптимизации до оптимизации
Свои первые замеры производительности делал читая логи
Привет любители производительности, когда-то вел таблички в базе знаний с метрикам производительности. База знаний у нас была на 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
Пока собираются сборки, качаются репки и горят токены, поделюсь подходом к одной игре. Играю я в 📱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/
Интересный был сегодня день — замедлились API запросы, запрофилировал, увидел что медленно работают запросы к базе данных. А запросы не менялись
И тут коллега говорит — смотри, сжатие файлов БД перестало работать
Причина медленной работы получилось из-за ошибки, из-за которой остановилось автоматическое сжатие (что-то типа auto vacuum), из-за остановки которого файлы данных с измеренными/удаленными записями стали содержать меньше нужных данных и больше ненужных, из-за чего поиск нужных данных замедлился. А чинится это запуском сжатия вручную один раз (что-то типа vacuum), после чего автоматическое сжатие снова работает
Прошел год и оно заработало!
Год назад начал маркировать тегами с именем api endpoint все дефекты по инцидентам. И делал это год, иногда каждый день, иногда раз в неделю — разбирал каждый скачок времени отклика
И вот уже две недели эти теги работают на меня — фильтрую по ним инциденты, а там уже все разобрано. Можно дополнять профилированием посвежее да и только
Ставить теги на задачи полезно
Пеку блины и читаю книгу "Производительность систем" (Брендан Грегг, 2023, Питер) — какая крутая книга. Я читал только предыдущее издание, и вот дошел до этой части, тут уже Ubuntu и eBPF
Однозначно рекомендую
Напишите в комментариях какие вы книги читали в этом году и рекомендуете ли их?
Ускоряем Allure.TestOps
Год назад работал над ускорением вот этой инсталляцииЧитать полностью…
🕚https://qameta.io/our-customers/miro/
▶️3000 tests for each of the 400 pull requests being run every day
которая давала более 1млн новых launch за день
И делал доклад потом
🕚https://polarnik.github.io/Allure.TestOps.SpeedUp/slides.html
🕚https://www.youtube.com/watch?v=Bzs7cAweTLY
По результатам также появился вот этот раздел инструкции
🕚https://docs.qameta.io/allure-testops/install/database/#separating-connection-pools
▶️The analytics pool, if enabled, will be used for some of the read-only aggregated data queries. It is a common practice to use a separate database for analytics, with replication configured between the two databases.
Но честно говоря, именно для той инсталляции, нагрузка от аналитики не была такой огромной, что это требовало отдельной реплики.
Там нагрузка создавалась вставками и обновлениями в огромном количестве (1+ млн в день). А также запросами по API разных данных — интеграциями. И там хорошо помогло
🕚удалить некоторое количество индексов
🕚создавать partial-индексы только на новые данные, где launch >= ..., test_id >= ... — раз в неделю
Индексы все же были нужны, потому что свежие данные по API и через UI использовались. Но именно свежие
При этом удалять старые данные из системы было непроизводительно. Вот этот скрипт
🕚https://github.com/eroshenkoam/allure-testops-utils?tab=readme-ov-file#delete-launches-in-allure-testops
ставит много задач на удаление в очередь задач, а они тяжелые, тяжелее задач на выборку и вставку, поэтому если его запустить, то производительности конец. Его можно запускать по выходным. Если такие дни бывают у вашей системы. Но partial-индексы с фильтром по свежим id будут игнорировать все архивные записи, поэтому их наличие не будет сказываться на скорости
Hello git lovers!
Неделю выбирал
🤩rebase или
🤩merge
Я работаю в своей ветке, и иногда мне нужно подмержить в свою ветку основной develop, и продолжить работу, подмерживать буду несколько раз. Для такого сценария ничего проще merge не придумали
Но я попробовал делать rebase основной ветки в свою
Один раз можно сделать rebase, а вот если два, то нужно
rebase —-onto …
rebase превращается в сложную задачу. Где ради ровного лога надо сидеть и высчитывать коммиты merge
Сам себя обманул 🤦♂️ с профилированием
Настроил на тестовом стенде 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!
Я большой любитель тетрадей и блокнотов. В Ижевске в шкафу лежит сумка с записями. В Москве еще одна. В Мюнхене стопка. А в рюкзаке всегда со мной пара блокнотов
Некоторые тетради и блокноты очень старые. Больше всего мне пригодились блокноты с контактами и паролями, начал вести их осознанно и регулярно, где-то в 2007-м
🤩записи с контактами были очень актуальны, когда на SIM-карту помещалось несколько десятков контактов, а телефоны менялись/ломались раз в год без возможности переноса контактов между устройствами
🤩записи с паролями стали актуальны, когда погрузился в безопасность и стал делать сложные уникальные пароли на каждый случай, а случаев было много, сотни
Блокноты переживают переезды, повреждения жестких дисков, смену сервисов — бумага очень надежный носитель информации, который устойчив к нагрузкам
Тут стоит сказать и что можно записать, и куда, и чем. И поделиться хочу находками:
🤩Ручки Pilot, конкретно FriXion, 0.5 — шариковые роллеры с тонкой и легкой линией, и со стирающимися быстросохнущими чернилами. Писать ими легко, чернила негустые
🤩Еще не видел плохих ручек с шариком 0.5 и не видел плохих ручек от Pilot
🤩Часто можно найти в магазинах ручки 0.7 — больший шарик, чуть больший расход чернил, и они более густые, поэтому нужно больше сил прилагать. Но тоже хорошо
🤩Гелевые пишут легко, но расход большой и они сохнут дольше или даже мажут — нужна плотная бумага (90 g/m2) и нужно ждать пока все высохнет перед закрытием
🤩А в школе у меня, думаю, были ручки 1.0, с большим шариком, и там усилий надо было много — часто их расписывал, ведь большой шарик засыхал, а то что колпачок надо закрывать я не думал
Хорошую бумагу я открыл для себя в 2018-м. Это был блокнот 📓 70 g/m2, который я забыл где-то в переговорке Райффайзен банка и так и не нашел. И бумага такой плотности была просто шелковой по сравнению с тетрадками, которые использовал ранее
Да есть у блокнотов минус — их можно забыть. Поэтому удобно хранить важную бумагу в рюкзаках, а не в руках
Большая удача найти тетрадь на спирали с плотностью 90. Почему удача — с такой плотностью часто продают более дорогие красивые блокноты в толстой обложке, обложка изумительная, бумага тоже, но часто они сделаны как книга, и их сложно разложить на столе не помяв. А вот спиральки раскладываются без помятия. Слышал и про японские блокноты, которые раскладываются без помятия, хоть и не используют спирали, но не пока не было опыта, не видел их
Сегодня интерны вышли на работу, ко мне тоже
Будем вместе делать мониторинг для YouTrack. Продукт сразу будет идти с мониторингом и алертами
Пусть получится и коллегу себе подготовить и продукт
А через два дня открывается подача заявок на новый набор интернов в JetBrains. Там есть проект по предсказанию метрик в облаке. Менторы будут в Амстердаме
☕️ Есть такая JVM библиотека Caffeine, отличная. Можно строить с ней кеши где у ключей есть срок годности
И вот я писал тесты с OAuth токенами. И подумал — вот возьму библиотеку готовую для токенов, не буду делать на ConcurrentHashMap-е
Взял. Сделал тест с Gatling. Уперся в ❎ DeadLock, когда одновременно ключи добавлялись, читались, и выполнялся внутренний CleanUp для Caffeine
Починил пока написав обертку над Caffeine-вой Map-ой, которая ставит 🔒 RetainLoc, что на чтение, что на запись. Сделал однопоточный кеш. Вроде все хорошо теперь. Может немного потерял в скорости, но отказываться от удобной таблицы уже не хотелось
Отлаживал аутентификацию OAuth. Кто знает про передачу JWT-токенов в относительных ссылках для GET-запросов, те знают, что относительные ссылки (которые #token={JWT|base64}) не всегда отображаются в прокси-серверах или даже на вкладке Network.
И я не сразу вспомнил про это и немного плутал. Чтобы лучше запомнить, да и вам напомнить, поделюсь картинками:
🤩В Network в секции Response Headers в заголовке Location для первого-второго запроса будет JWT-токен
🤩В Console если включить логирование запросов тоже будет виден JWT-токен, уже просто в Requests URL
🤩Но вот в Network в Request URL относительных ссылок не будет видно в браузерах
🤩И в прокси-серверах тоже относительные ссылки не показываются, например в ProxyMan, в URL
Это тот тонкий момент, когда параметры запроса есть только в предыдущем ответе и они скрываются при отображении этого запроса, почти везде
Представьте, что вы отвечаете за доступность и корректность работы большой системы, и у вас может быть есть явная роль 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
Ни теста без дефекта!!
Задали мне сегодня вопрос «Есть ли у меня план-бекап?» И вопрос был задан в контексте того, а вот отключится все электричество года так на два — двадцать два — что будешь делать?
И тут я подумал, что нагрузкой больше заниматься не буду.
Надо бы научится чему-то полезному, людей лечить, например, или зверей хотя бы. Существо я социальное, хоть и проводил в лесах и горах много времени, но жить там полностью автономно не смогу. А по-хорошему мне в такой ситуации хотелось бы проделать путь длиной примерно в 3-4 месяца пути (пешком или на транспорте, как велосипед), родных проведать. На таком пути будет здорово знать языки и уметь людям помогать как-то
Год назад начал разбирать 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
## Дудупликация строк
-XX:+UseStringDeduplication
## Работает с G1GC:
-XX:+UseG1GC
## Сколько поколений сборки мусора надо пережить (3 по умолчанию)
-XX:StringDeduplicationAgeThreshold=1
## Надо будет добавить 100ms к длительности пауз (по умолчанию в JMeter 100)
-XX:MaxGCPauseMillis=200
view.results.tree.max_size=10485760 байт, если результат загружается из файла (при просмотре результатов в live-режиме обрезать результат нельзя)String.intern() для некоторых больших строк (думаю это точно нужно только для JMX-файлов и для тел запроса в режиме чтения тела запроса из файла
Есть в профилировании 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. Но это лучшая оценка
Все такие множители удобно записывать в виде комментариев к строкам стек-трейса — просто через //
И когда разработчики будут смотреть на такой аннотированный трейс, то будут говорить спасибо. А чтобы его получить надо будет сделать три разных профилирования одной и той же операции
Сегодня взял небольшой отпуск и пошёл в кафе в горах почитать, просмотреть, покушать. В некоторых горах есть кафе!!! Да, надо добраться сюда, но …
🤩🤩🤩🤩🤩🤩🤩🤩🤩
Нагрузочных историй пока нет, но нашел вот эмоджи интересные
🤩🤩❤❤❤❤❤❤❤
Можно ими порадовать близких
❕❕❕❕
Узнал, что если рассматривать мозг как мышцу, то ему нужен отдых, минут 🤩🤩 в течение дня в тишине или на природе и 🤩🤩🤩 ночью — тогда он будет расти
Подумал что будет здорово гулять по 🤩🤩 минут после обеда, кушаю я быстро, а обеденный перерыв на работе на час. Может стану соображать лучше от этого
〰️〰️〰️〰️〰️〰️〰️〰️
Еще подумал, что данный канал выглядит для вас не как summary чата нагрузки, а как дневник одного человека. Может переименовать в дневник
Прочитал новости про закат StackOverflow как площадки, где эксперты отвечали на вопросы. Вопросы теперь задаются не экспертам, а чатам с моделями, натренированными на StackOverflow
В чате qa_load вопросов тоже не так чтобы много, потому-то модели ответят быстрее, чем люди в чате
Пока, скорость решающий фактор, но в редких ситуациях, люди будут продолжать искать людей. И чтобы такие ситуации случались, стоит продолжать рассказывать миру — глубоко разбираюсь вот в таких вот темах и решаю вот такие вот проблемы
Возможно следующая версия чатов будет представлять из себя именные топики для общения с нужным человеком, но публично, плюс общий чат, в котором умные модели с нужным контекстом, ответят на вопросы
Привет performance lovers! Вы когда-нибудь участвовали в выборе хостинга, сервиса, продукта в вашей компании. Например, в рамках технического комитета, где надо было оценить варианты с точки зрения производительности
Производительность, наблюдаемость, доступность — те характеристики, на которые могу повлиять в YouTrack, и влияю уже год. Считаю, что прогресс существенный. А вот когда клиенты выбирают продукты, то как решения принимаются?
✨Оценка делается на основе статей и мнения разработчиков решения?
✨Оценка на основе мнения экспертов из индустрии?
✨Оценка делается исходя из того, что друзья/партнеры/конкуренты используют это решение?
✨Независимая экспертиза и услуги консалтеров?
✨Внутренняя оценка, и делаются сравнительные тесты, внутренние пилоты?
🎄или не играет большой роли производительность
🍪 Поделитесь мыслями или своим опытом. Можно в личные сообщения @smirnovqa
❤ Всем отличной субботы, а тем у кого уже воскресенье — отличного воскресения
Оказалось, что больше всего в этом году смотрел Heisenbug на YouTube
Иногда это были доклады, на которых был, но хотелось вспомнить детали
Иногда это были просто интересные материалы
Буду очень рад новым мастер-классам и докладам по мониторингу и производительности весной. Да и не я один. Отправляете свои материалы ☺️. Просто идеи бывает сложно конвертировать в отличный материал, а MVP довести до прода — одно удовольствие
Весной будет юбилей конференции. Будет здорово!
Вчера был международный день гор — 11 декабря ⛰🏔🌋
Почему это важно для меня? Мои путешествия начались с горного туризма.Читать полностью…
И там я впервые понял, что я не нагрузочник и не сотрудник компании, я был просто собой и людям вокруг было важно чтобы был верный маршрут, починенные вещи, приятная компания. А до походов я почти всегда был инженером, кроме тех дней когда я был дома
Заниматься инженерией и производительностью круто. Но если сложно ответить на вопрос, а кто же я, без использования названия компаний, то можно сходить в поход или домой поехать. А почему стоит посмотреть на горы? В горном походе хорошо то, что комаров мало и красиво как нигде.