Привет performance lovers!

Прошла еще одна нагрузочная неделя. У меня получилось разобраться в сборке мусора Go (GOGC: 1000 норм), автоматизировать сбор метрик от эфимерных тестовых стендов (использовал Prometheus Push Gateway и цикл с двумя curl-ами), от души поговорить с коллегами. И вот думаю, что полезного написать? Чтобы пригодилось многим и чтобы это еще не было написано в интернете и модели про это не знали?

Кажется самое интересное что сделал на этой неделе — выбрал в каком кабинете буду работать

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

❓Куда пойти нагрузочнику

Команда производительности IDEA сидит плотно, рядом с ними мест не нашел. Подумал — а может к лучшему, да и я из другого проекта, но было бы круто поработать рядом с ними

Команда автоматизации тестирования тоже сидит плотно (трое в кабинете на троих). Подумал — а может и к лучшему

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

В офисе почти все рабочие места в кабинетах заняты, есть некоторое количество пустых, их видно в Envoy. Вот, я открыл карту свободных мест и стал смотреть по карте этажей:

— на какие этажи ходил
— в каких кабинетах был
— где я видел друзей
— где сидит команда
— кого я знаю

И получилось не так много вариантов. А потом написал другу — не будет ли кто против, если перееду к нему? Там простой стол, без тумбочек и полочек, но зато есть вид из окна 🤩 это я люблю. Забронировал пока в Envoy свободный стол на две недели в вперед. Это оказался очень полезный сервис

Итого получается такая рекомендация

✔️ используйте внутренние сервисы чтобы найти свободные столы
✔️ работать рядом с друзьями это хорошая рекомендация
✔️ маленькие мелочи как вид из окна также важны
✔️ эти выборы можно сделать самостоятельно, а если что-то идет не гладко — может это к лучшему

Думаю, что следующая неделя будет еще лучше. Чего и вам желаю 🍀

А на видео водопад, который вытекает из горного озера и переходит в чистейший ручей. Это в городе Garmisch-Partenkirchen. Если кто-то из вас проходит собеседование в YouTrack QA Performance с релокацией в Мюнхен, то напишите, как все получится — рабочее место освободил и все прибрал, красивые места вокруг разведал 🙂

Привет performance lovers!

Знаете почему алерты могут не приходить, когда система под нагрузкой?

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

А под нагрузкой логов больше, они кладутся в очередь и начинают попадать в систему анализа логов с задержкой. И в системе анализа логов (OpenSearch) логов нет за последние 3 минуты, 4, … доходит до 6-ти. А проверка выполняется по последней минуте. И в этой минуте проблем не обнаружено 🙈 а они как раз таки есть

🚩🚩〰️〰️〰️📳〰️📳
🚩🚩〰️〰️📳〰️〰️📳
🚩🚩〰️📳〰️〰️〰️📳

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

Стал собирать метрики за широкое окно:

📳🚩🚩〰️〰️〰️〰️📳

А также собирать метрики из прошлого за узкое окно с разными смещениями:

🚩🚩〰️📳〰️📳〰️〰️
🚩🚩📳〰️📳〰️〰️〰️
🚩📳🚩📳〰️〰️〰️〰️
📳🚩📳〰️〰️〰️〰️〰️

У метрик появились labels:
🟤window
🟤offset

Логика визуализации чуть сложнее стала и логика алертов тоже. Но зато теперь они есть

А на видео горы и кузнечики стрекочут

Привет performance lovers!

Заметил за собой, что у меня нет привычки делать code review

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

Для привычки завел себе тетрадный листок, там клеточек примерно на месяц

▫️🗓🗓🗓🗓🗓🗓🗓
🗓✔️✔️⭐⭐⭐⭐⭐

Надеюсь через месяц стану мастером ревью

А на видео река Дунай в городе Регенсбург. Красивый город. И там сейчас проходит праздник дультфест (как октоберфест)

Привет performance lovers!

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

🚩 профессионально читаю логи

Еще профессионально смотрю на метрики, но по ним часто становится понятно, что нужно

🚩 логи почитать

Пока что мне очень нравится такая простота само описания

❓ как бы вы описали свою работу простыми словами

А на видео зеркало озера Seebensee — красивое место

https://www.google.com/search?q=Seebensee

Привет performance lovers!

Утилита GitHub cli упростила мою работу на этой неделе: https://cli.github.com/

Думаю вы слышали истории, что разные инструменты генерируют много кода и так сложно стало делать review кода. Да нет же. Пройти ревью стало сложнее, ведь разные инструменты как Copilot подключились к процессу и они хороши, не очень глубоки, но хороши. Если они что-то заметили, то там вокруг еще много чего поправить стоит и перечитать и переосмыслить

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

Copilot теперь это мой большой брат (старший), присматривает за порядком

А программирую тесты я в IDEA, в ней работает моя младшая сестренка-помощника Junie, она легко удаляет код, не забывает ничего.

Но мне надо было подключить Junie и IDEA ко всем комментариям которые Copilot оставил на GitHub. Как это сделать?? MCP скажите вы — да нет наверно отвечу я. Уже подключил так много разные MCP, что достиг лимитов. Я еще пробовал использовать Docker Desktop как Hub для MCP — но в нем точно такие же лимиты на количество методов MCP как и везде — 100 методов. Все выглядело так, что как-то передавать комментарии одного агента другому у меня не получится

https://cli.github.com/manual/gh_pr_view

gh pr view [<number> | <url> | <branch>] [flags]

вот эта команда мне помогла соединить все
если я работаю в репозитории который залит на github и в этом же репозитории есть PR с номером 42 то использую вот такую команду

Сначала я пробовал текстовый вид

gh pr view 42

но время от времени он возвращал мне старые результаты без новых комментариев и статусов, из-за кеширования и несогласованности кешей или еще из-за чего-то

И я перешел на JSON-формат, сначала со всеми полями вообще:

/opt/homebrew/bin/gh pr view 42 --json additions,assignees,author,autoMergeRequest,baseRefName,baseRefOid,body,changedFiles,closed,closedAt,closingIssuesReferences,comments,commits,createdAt,deletions,files,fullDatabaseId,headRefName,headRefOid,headRepository,headRepositoryOwner,id,isCrossRepository,isDraft,labels,latestReviews,maintainerCanModify,mergeCommit,mergeStateStatus,mergeable,mergedAt,mergedBy,milestone,number,potentialMergeCommit,projectCards,projectItems,reactionGroups,reviewDecision,reviewRequests,reviews,state,statusCheckRollup,title,updatedAt,url 2>&1

тут полезное поле это
🤩latestReviews — самые свежие комментарии, это стоит передавать
тут самое большое поле это
🤩reviews — все комментарии с историей, если их уже много, то можно это поле убрать

а потом только на часть полей

/opt/homebrew/bin/gh pr view 42 --json number,title,state,body,baseRefName,headRefName,latestReviews 2>&1

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

Когда все будет доработано то можно обновить и body (описание) всего PR-а:

/opt/homebrew/bin/gh pr view 42 --json number,title,state,body,reviews 2>&1

вот так можно получить и первоначальное описание и все правки которые были сделаны в ходе ревью и сформулировать обновленное описание.

Если же вы в ходе review делаете небольшие новые git commit с правками и commit message с описаниями доработок, то финальное описание можно будет получить по локальной истории, без походов в github

Привет performance lovers!

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

⚡ Изменилась скорость изменений. Теперь уже нормально увидеть результат запланированного через дни и недели. Не через годы

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

Откуда такая привычка пришла? Так получилось из-за того, что я почти никогда не видел результаты изменений в те сроки, которые были в плане, а работы нужно было проделать много больше планируемой. Шутка про домножение сроков есть в разных книгах, где-то без деталей, где-то с деталями. Например Фредерик Брукс («Мифический человеко-месяц») вывел правило: разработчики обычно оценивают только время на написание кода. А проект это сумма, где планирование занимает 1/3 времени, написание кода — 1/6, а тестирование и отладка — половину всего времени. И вот тестирование с отладкой стали x3 от кодирования, а весь проект x6. Это никому не нравилось, но такой был консенсус. Другие книги говорили, что менеджер попросит сократить сроки в 2 раза, возможно, потому что умножая все на 6, менеджеры не попадали в свои ожидания. Поэтому другие книги советовали сразу умножать все в два раза. Хаос, а не математика с планированием, согласитесь? И простая истина была такой:

хорошие дела быстро не делаются

Так лет 15 назад меня научили менять вещи планомерно делая дело, и что к изменениями окружающие будут относиться последовательно меняя мнение о них:
- что-то странное
- в этом что-то есть
- а так всегда и было

И на интервале пятнадцать ... пять лет назад, я долго делал и делал что-то, пока не находились люди, которым это нравилось тоже. А потом дело шло хорошо. Вообще "долго делал и делал что-то" не звучит как изменение, согласитесь? Но вот такой улиточный способ был рабочим. Он действительно работал.

Также улиточная скорость была вокруг меня по роду работы - нередко это некая старая система, которая работала годами и будет работать еще годы спустя, но ее надо ускорить. Поэтому у меня сложился подход к работе, что сначала попробовать ускорить систему конфигурациями и настройками или количеством узлов, как-то понять систему и настроить, потому что ее не поменять скорее всего. Понимание системы, часто связанное с мониторингом, и изменение конфигурации для меня стало синонимом быстрого способа изменений. Добавление индексов в БД тоже стало синонимом быстрого способа изменений. А вот переписывание системы или миграция на новую систему - что-то на долгом и богатом. Да, я буду в этом участвовать, но результат будет не скоро. Такая была установка, которая была проверена на множестве проектов

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

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

Если вы уже привыкли домножать. И стали энтерпрайз-человеком, то это может мешать при работе в стартапе, например. Это может мешать при работе на некоторых проектах. Знать эти старые техники можно и нужно, знать откуда и почему они взялись тоже. Их можно будет применить при случае. Будем надеяться, что таких случаев будет меньше и меньше

А красная точка на видео — это я благодарный моим родным, друзьям и людям сделавшим этот маршрут. Отличных вам выходных!

Привет performance lovers!

Недавно слышал совет:

делать обработку данных, как можно ближе к источнику

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

Проблема

Тест устроен так, что в нем
1️⃣выбираются данные из БД
2️⃣данные выгружаются в JSON
3️⃣JSON читается и построчно кладется в Redis как list
4️⃣k6 тест в котором несколько vus последовательно читает записи из Redis по индексу
5️⃣отправляются запросы которые делают операции с записями

Проблема производительности возникала на шаге 5️⃣когда много VUS начинали работать с данными из одной группы.

Причины

Так получилось потому, что данные из БД выбираются отсортированными по ID группы в начале. Поэтому в конце этой цепочки много vus начинают обрабатывать записи принадлежащие одной ID группы. И эта группа блокируется.

Первый подход к решению

Такой бы блокироки не было, если бы все разные VUS обрабатывали бы разные группы. Подумал я. И начал править шаг 4️⃣ где VU-ы выбирают какие данные они будут обрабатывать. Cделал интересную логику, где каждый VU берет себе кусочек тестовых данных и работает с ним, а к тестовым данным обращается по индексу с примерно такой логикой:

exec.vu.idInTest * 
dataset.length /
exec.test.options.scenarios.NAME.vus + 
exec.vu.iterationInInstance

Тут 1-й пользователь обрабатывает начало списка, а 100-й конец списка (100-й подсписок). Поэтому не возникает ситуации что все 100 vus взялись за одну и ту же область с одной и той же ID группы. Но логика получилась довольно непростой. Потому что вы понимаете — если хочется обработать все записи без пропусков и без повторов, то просто применить индекс не получится. На границе отрезков что-то потеряется и округлится, а что-то обработается дважды. А нужны специальные проверки на случай что VUS-ов больше, чем длина тестовых данных.

Второй подход к решению

А более простым решением оказалось в модификации шага 1️⃣
Еще при выгрузке данных из БД убрать сортировку данных по ID группы, а сортировать по ID записи (случайный GUID). Записи сразу перемешиваются, и в тесте можно просто обращаться к ним через

exec.scenario.iterationInInstance

или

exec.scenario.iterationInTest

Такое решение позволяет сделать простой-простой скрипт k6, но не пропустить тестовые данные

Кажется, удача меня любит

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

🍿 История

Взял в работу две задачи — настроить мониторинг баз данных и настроить восстановление баз данных из бекапов с разными тестовыми данными. По задаче мониторинга подготовил параметры подключения. И параметры подключения с RO-доступом, более того, только с доступом до статистики pg_stat_*. И сделать такую роль было непросто. Все круто с этой задаче, но роль было сделать сложно. Одна база данных оказалась с таблицами в схеме public (не в схеме %{service_name}, а в схеме по умолчанию для postgresql). И на нее действуют DEFAULT PRIVILEGES, а они такие, что у роли pg_monitor в том числе есть права на чтение и работу с TABLES, SEQUENCES, FUNCTIONS. Хотя это не видно явно:

CREATE ROLE pg_monitor WITH 
 NOSUPERUSER
 NOCREATEDB
 NOCREATEROLE
 INHERIT
 NOLOGIN
 NOREPLICATION
 NOBYPASSRLS
 CONNECTION LIMIT -1;

GRANT pg_read_all_settings TO pg_monitor;
GRANT pg_read_all_stats TO pg_monitor;
GRANT pg_stat_scan_tables TO pg_monitor;

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

Подготовил по второй задаче скрипты и параметры, бекапы сделал. Начинаю тестировать восстановление. И тут запара, другая запара ..., а все эти connection strings длинные и похожие ...

Беру connection string (взял из списка, который готовил для мониторинга), передаю в скрипт восстановления БД и запускаю. А он мне пишет — прав нет на операцию

pg_restore: error: could not execute query: ERROR:  must be owner of table ...

Я сначала не понял, да как так. Я же админ, а прав нет — должны быть. А потом как понял, что это большая удача 🍀

🐤 Причина

Я взял строку подключения, вообще, к другой базе данных и восстанавливал в нее бекап не для нее. И все получилось хорошо (а точнее ничего не получилось), только потому, что строки подключения для мониторинга были с минимальными привилегиями

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

💡 Что тут можно подумать

1️⃣ Может не стоит делать сразу две задачи. Может не стоит попадать в запары и запариваться, а если уж запара есть, то не брать две задачи 🙂
2️⃣ И очень круто, что для мониторинга, даже для тестового, использовал минимальные привилегии, а не админские

Если бы были админские права, то базу данных я бы незаметно сломал. Я бы потом не сразу понял почему в ней есть таблицы от другой базы данных?

Привет любители производительности!

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

Что внутри папки:
- Каналы разработчиков: авторы показывают крутые фишки, заметки с полей, релизы, библиотеки и многое другое 🙂
- АI, чат боты и вайбкодинг: куда без этого, кто-то ещё работает руками?😁
- QA и ИБ каналы, опытные специалисты делятся своими знаниями и помогают в группах/комментариях
- Целый список крутых авторских каналов, которые не позволят заскучать😀
В этой папке все очень-очень актуальное, то что не будет пылиться в архиве телеграмма


А если наоборот хотите вернуться в прошлое и еще не знали, что в цифровых библиотеках тоже можно брать книги, читать, возвращать. И думаете как найти свои старые книги с пожелтевшими страницами. То загляните в архив и открытую библиотеку.
Например, многим будет интересно прочитать первые две части Дюны
🤩 https://openlibrary.org/books/OL7500941M/Dune (фильмы 1-3 по этим двум частям). И в декабре-январе многие будут смотреть третью часть фильма
Или энциклопедии
🤩 https://archive.org/details/20210402_202104
🤩 https://archive.org/details/rosmen_encyclopedia_zhivoi_mir_1997
(у меня были обе эти книги)
Или какие-то старые журналы по радио

🤩 В OpenLibrary, как много где, бывает так, что книга доступна для чтения, но вскоре становится доступна лишь в настоящей библиотеке поблизости. Но, все книги из читательского билета, которые вы начинали читать — продолжают быть открытыми. Поэтому тут даже полезно начать что-то читать и отложить на время — так сохраннее