Иногда жизнь преподносит нам сюрпризы. Когда продакт-менеджер обратился ко мне с предложением примерить на себя роль лидера проекта, я была уверена, что он шутит. Сначала я сомневалась, ведь что может предложить QA-инженер вроде меня? У меня не было технических навыков разработчика. Но потом меня осенило. Я поняла, что у меня есть уникальный шанс сделать все по-другому.

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

Итак, мы с вами добрались до третьей, самой «хардовой» части цикла. Сегодня поговорим про gRPC.

Что такое gRPC? 

Сам RPC — удалённый вызов процедур (иногда вызов удалённых процедур; RPC от англ. remote procedure call) — класс технологий, позволяющих программам вызывать функции или процедуры других программ, делая это так, как если бы они находились в одном адресном пространстве. Буква g в названии — это гугловая реализация этих технологий.

Разберем это все на примере.

Допустим, что вы — программист и сидите в монолитной репе. У вас одно приложение. Сам проект открыт в IDE и вы в нем работаете. В репе реализован определенный класс (например, на Kotlin), у которого есть метод, возвращающий вам данные по пользователю.

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

Меня зовут Кирилл Юрков, я SRE-тимлид Samokat.tech. Сегодня поговорим про нагрузочное тестирование. Про то, как мы решали обозначенную проблему, какие грабли нам попались, и какие трудности удалось преодолеть.

Всем привет, я Никита Мунтян, QA Load Engineer в inDriver. Пришел в компанию в 2020 году развивать направление нагрузочного тестирования. В первую очередь познакомился с коллегами, выстроил план работы и начал планомерно выстраивать процессы и технические решения.

Тогда передо мной было пустое поле — делай как хочешь и как видишь, возможностей для творческой реализации много. Оставалось понять, что хотят увидеть от нагрузки, и какой подход использовать. Мы решили делать Load as a Service, об этом и расскажу под катом.