Как стать автором
Обновить

Комментарии 8

Я рассматривал, там есть большой минус в единицах измерения - virtual users, которые не дают реального понимая сколько запросов может выдержать сервис (хотя это можно настроить).

В плане нагрузочного тестирования мне больше всего зашёл Яндекс Танк, но для gRPC нужно будет немного дописать код (форк)

На всякий случай добавлю, что проблема с k6 и VUs легко решается переходом на старый добрый RPS

А про причины почему k6 использует именно VUs, можно почитать здесь

На тот момент не рассматривали, искали инструмент для тестирования GRPC

jsonPath("$.id").saveAs(id) - сохранит значение в сессию, но дальше в примере стоит строковый интерполятор и вызов сессии, но переменные используются не из сессии, оно так не будет работать. Можно же просто указать переменные из сессии и все

 .body(
      StringBody(
           """
               {
                  "id": "${id}",
                  "name": "${name}",
               }
           """)
    )

.check(status.is(200)) - можно не указывать, так как входит в дефолтную проверку

200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 304

При написании сценариев на HTTP в какой-то момент можно столкнуться с проблемой отсутствия грамотной сериализации на Scala

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

Спасибо, за найденную ошибку!

  • При написании скриптов для http мы не нашли способа сериализации ответа в объект Scala.

  • Ещё есть проблема с увеличением буфера памяти, поскольку при массовой загрузки файлов в какой-то момент можно напороться на нехватку памяти, при том, что ресурсы машины используются далеко не полностью. (параметры -Xms, -Xmx пробовали менять)

А зачем вручную json создавать? Используйте существующие либы, circe или zio-json там

Также можно extension написать, чтобы каждый раз не писать asJson

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории