Привет performance lovers!

Мы вместе с коллегой занимаемся Observability as code, и обнаружили что для хранения информации по сотне тысяч сервисов InfluxDB (v1) быстро и просто принимает метрики (если вставлять пачками по 10 000), но медленно потом отдает группировки, а вот Postgres позволяет и записать метрики и быстро показать

Думаю надо будет попозже сделать отчёт сравнение. Потому что такие возможности как LIMIT и SLIMIT мы не попробовали даже для InfluxQL:

https://docs.influxdata.com/influxdb/v2/query-data/influxql/explore-data/limit-and-slimit/

И сравнивали на запросе
SELECT * FROM …

Продолжение следует
Подписывайтесь на канал и жмите на 🛎️

В инструменте FlameGraph Брендена Грегга есть возможность визуально показать на графе новые/другие части другим цветом. Делается за счет того, для каждой строки можно сохранить какой сейчас используется цвет, а потом переиспользовать его при формировании графа для нового профилирования, для которого будет задана другая расцветка

Описано это вот тут — как переиспользовать палитру
https://github.com/brendangregg/FlameGraph?tab=readme-ov-file#consistent-palette
Вот есть два примера
- https://github.com/brendangregg/FlameGraph/blob/master/demos/palette-example-broken.svg
- https://github.com/brendangregg/FlameGraph/blob/master/demos/palette-example-working.svg

А мне захотелось чтобы все вызовы методов работы с БД были одного цвета, все вызовы бизнес-логики другого, ...

Поэтому придумал категории, префиксы категорий и цвета категорий:

# Jetty HTTP server
org.eclipse.jetty.=JETTY_BOILERPLATE

# Jersey JAX-RS (javax.ws.rs. must be before javax. for longest-prefix-wins)
org.glassfish.jersey.=JERSEY_BOILERPLATE
javax.ws.rs.=JERSEY_BOILERPLATE

# Kotlin standard library and coroutines
kotlin.=KOTLIN_STDLIB
kotlinx.coroutines.=KOTLIN_STDLIB

# JVM runtime
java.=JVM_RUNTIME
javax.=JVM_RUNTIME
jdk.=JVM_RUNTIME
sun.=JVM_RUNTIME
com.sun.=JVM_RUNTIME

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

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

Как подружить Gatling и JUnit 5

Вызов Java-метода
import io.gatling.app.Gatling
Думаю что вы уже знаете, как вызвать Gatling программно

Gatling.main(gatlingArgs);

но вот незадача — там в конце main-вызова есть

.MODULE$.exit(this.fromArgs(args));

и этот код завершит текущий процесс, включая и Junit 5 процесс — все просто схлопнется, но нагрузка выполнится до конца, а вот сделать какой-то assert или обработку в Junit уже не получится

Вызов Scala-метода
import io.gatling.app.`Gatling$`
Можно запустить Scala-класс явно, без Java-обертки которая вызывает exit в конце

`Gatling$`.`MODULE$`.fromArgs(gatlingArgs)

Тут все получится и тест не завершится. Но он не упадет если внутри Gatling сработали ассерты.

Добавить проверку статуса
import io.gatling.app.`Gatling$` + код возврата
Чтобы внутренние ассерты сработали надо еще добавить проверку кода:

  ┌─────────────────────────────┬───────────┬──────────────────────┐
  │      Scala case object      │ Exit code │       Значение       │
  ├─────────────────────────────┼───────────┼──────────────────────┤
  │ StatusCode.Success          │ 0         │ Всё ок               │
  ├─────────────────────────────┼───────────┼──────────────────────┤
  │ StatusCode.InvalidArguments │ 1         │ Ошибка аргументов    │
  ├─────────────────────────────┼───────────┼──────────────────────┤
  │ StatusCode.AssertionsFailed │ 2         │ Assertions провалены │
  └─────────────────────────────┴───────────┴──────────────────────┘

Проверка на Kotlin может выглядеть вот так

val exitCode = `Gatling$`.`MODULE$`.fromArgs(gatlingArgs)
if (exitCode != 0) {
    throw AssertionError(
        "Gatling simulation ${simulationClass.simpleName} failed with exit code $exitCode" +
        if (exitCode == 2) " (assertion failures — check Gatling report for details)" else ""
    )
}

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

Собрал промежуточные результаты наших опросов https://t.me/qa_load/170588. Картина получается интересная: местами предсказуемая, а местами заставляющая задуматься, куда мы идем. 🤩

1️⃣ Кто мы и где находимся
Большая часть нашего сообщества (более 85%) это специалисты из РФ и РБ. Рынок повзрослел: сеньоров и лидов у нас почти столько же, сколько мидлов, а вот джунов совсем мало, меньше 5%. Это подтверждает мысль: простые задачи уходят в AI, и порог входа становится выше

2️⃣ Про деньги и полярность
Медиана нашего рынка — $2 000-$3 500. Но разброс колоссальный:

👑 Верхушка айсберга: Всего 3 человека (около 1.5%) пробили планку в $15 000-$22 000+. Это почти 100% корреляция с рынком США и позициями Staff-уровня.

🦾 Эффект Overemployment: 19 человек работают на 2+ проектах одновременно. Скорее всего, это они сидят в вилке $7 500-$12 000, превращаясь в индивидуальное Performance-агентство за счет AI, экономящего им 40% времени.

📉 Зона турбулентности: 33 человека получают меньше $2 000. При этом работу ищут 27 человек. Рынок насыщен специалистами с опытом 2–3 года, которые конкурируют за все чеки и за низкие чеки тоже

#статистика_нт #карьера_2026

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

https://performance.shopify.com/pages/services

Интересная бизнес модель у отличной платформы создания интернет магазинов shopify — можно нанять их команду производительности или команду партнеров 💡

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

Как они добились и как обосновывают?

https://www.shopify.com/enterprise/blog/store-speed-conversion

The trend is clear: for every 100 milliseconds slower a store loads, conversion tends to be about 3.5% lower.

Посчитали, что 100 ms задержки к LCP снижают конверсию (вероятность покупки) на 3.5%

For every 32 milliseconds slower a store responds to interactions, conversion tends to drop by about 1.5%.

А 32 ms к INP также снижают эту вероятность на 1.5%

И чтобы это посчитать они сделали сервис аналитики производительности (встроенный в систему)

https://help.shopify.com/en/manual/online-store/web-performance/web-performance-reports

Отчёт небольшой, использует хранилище Google и просто показывает метрики из него, эти метрики Google и так собирает со всех Google-устройств и Chrome-ов

💰 Их фишка, что они смогли собрать ключевую метрику Conversion rate по сайтам клиентов и соотнести ее с performance метриками

Для этого им скорее всего пришлось постараться и сделать непростой механизм сбора бизнес метрик. Сохранить и обогатить CrUX метрики. Выстроить сеть партнеров с perf-компетенциями. И запустить все

Крутой проект, сколько рабочих мест создано! И как же это красиво подано 🔥

Привет performance lovers! Я начал забывать

Двадцать лет назад я зачитывался историями про ученых Греции, про физиков и математиков. Поражала их память и объёмы информации в их голове

Тогда я делал одно упражнение по вечерам — возвращаясь домой вспоминал весь свой день в деталях. Только один день, но очень детально

И это помогало быстро вспоминать что было вчера и неделю назад и месяц

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

Как-то работая в НПО я заучил и запомнил всех коллег по фото и имени. Не помню сколько человек это было, думаю пару недель учил просматривая карточки в SharePoint снова и снова. Там можно было делать что-то типа SQL запросов к данным и создавать отчёты — только с фото, только с именем, и с фото и с именем

А сегодня мне друг напомнил про поход к водопаду рядом с Иджеваном, а я не помню где это, где Иджеван? Какой из походов это был?

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

Надеюсь, когда мы встретимся с вами и возникнет вопрос — а помнишь … — буду помнить