Недавно слышал совет:
делать обработку данных, как можно ближе к источнику
И вот как это применилось на примере 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, но не пропустить тестовые данные