Pull to refresh

Comments 16

Самое клёвое в gatling это то что это тот же самый код на scala и стандартный проект на sbt. Мы подключаем json4s для типизированной работы c ответами и запросами и собираем проект через sbt-native-packager. Единственный минус это отсутсвие распределённого запуска (мы решили его небольшой утилитой которая деплоит артефакт по ssh, запускает, качает логи и собирает стандартный отчёт) и привязанность к graphite (приходится держать influxdb а хотелось бы пушить логи в elastic).
А что-то помимо http им можно тестить?
Да. Также из коробки есть поддержка wss, jms и sse. А так в общем вы можете создать любое «brute force» приложение, в статье я написал, что внутри блока
exec( session => {
// ваш код
})

можно писать любой scala код. Так что тут ограничиваемся только своей фантазией и возможностями Scala/Java.
Ещё есть несколько плагинов (Cassandra, MQTT, Kafka, RabbitMQ, AMQP) http://gatling.io/docs/current/extensions/
выдерживает до 5000 открытых соединений без сбоев


Почему так мало? Netty держит сотни тысяч соединений. Или у вас какой-то особенный кейс?
Неправильно выразился. Просто у нас не было задачи тестировать бОльшее число коннектов по сокету. Так что эта цифра нас вполне удовлетворила.
val users = ssv(fileName).circular

Покажите, пожалуйста, примерное содержимое данного файла.

И как Вы высчитываете примерный онлайн который выдерживает сайт? Вот в вашем графике видно ~2000 запросов в HTTP Request completedtasksreport skill и 3 KO ( ошибки? )… но это же != 2000 юзерам
Содержание файла:
login;password
nameasd;passasd
asdname;sdsfjksdfk
...


Чтобы посчитать критическую нагрузку на сайт(на самом деле на одну из бек систем), мы линейно увеличиваем число потоков, при этом мониторим, например, через jmx бек. Также на графике «число ответов в секунду», можно будет выделить момент, при каком числе потоков(клиентов) начинается увеличение числа ошибок.

Да KO это ошибки.

2000 запросов это общее число запросов для этого метода за все время нагрузки. Каждый клиент вызывал этот метод 15 раз
.repeat(15) {
...
}
У меня была задача протестировать нагрузку сервиса, в который через WebSocket отсылались задания, а сервер по частям возвращал результат.

Я начал писать скрипт на Gatling (тогда версия 2.1.7). Потратил несколько дней, и забил на это дело — год назад Gatling был кривой, а его разработчики — немного неадекватны. Не знаю, если сейчас стало лучше.

Первой проблемой было то, что Gatling сам закрывал соединение. Я попросил автора помочь разобраться — где искать / как настроить, чтобы посмотреть детальные логи. Он мне сказал, что это типа твой сервер закрывает соединение — сам разбирайся. Потом я нашёл (там для вебсокетов оказывается отдельный логгер), что это у Gatling есть параметр webSocketMaxFrameSize, при превышении этого размера Gatling обрывает соединение без внятного сообщения об этом.
Как сейчас — уже сделали внятную документацию?

Второй проблемой было то, что под нагрузкой некоторые соединения помирали (time out). Ну на то оно и нагрузочное тестирование, чтобы обнаружить такие случаи. Но Gatling в таком случае просто подвисал, и не мог распознать time out. Эта задача до сих висит открытой:
https://github.com/gatling/gatling/issues/2601

Ну и третьей проблемой была их модель. Я когда спрашивал про некоторые исправления, то бывало отвечали так, что они уже что-то пофиксили, но чтобы получить эти фиксы — берите платную подписку. А хотите open source — ждите у моря погоды, мы когда-нибудь выложим. Такой вот open source.
Документация не поменялась. Единственный момент, не знаю было ли раньше, но сейчас можно получить конфигурационный файл со всеми параметрами и объяснениями через sbt команду:
gatling:copyConfigFiles


Насчет второго. Мне помогла принудительная проверка таймаута в таком виде:
check(wsAwait.within(10 second).until(1).regex(".*conversationCount.*"))

В этом случае если вдруг коннект повиснет, то через 10 секунд вылетит ошибка Check failed: Timeout

По поводу их модели ничего сказать не могу. Всегда хватало бесплатной версии.
С интересом ждём следующей статьи про Gatling…

Мне вот на днях дали задачу нагрузить HTTP endpoint обычными GET запросами.
Использовал Apache Bench, получается вот так:

ab -k -n 1000000 -c 1000 "http://10.20.30.40/id1/id2?q1=v1"
Requests per second: 5424.66 [#/sec] (mean)
Time per request: 184.343 [ms] (mean)
Time per request: 0.184 [ms] (mean, across all concurrent requests)

То есть другими словами, этот скрипт в каком-то смысле эквивалентен вопросу: при нагрузке в 1000 постоянных пользователей, сколько RPS и как быстро может выдать сервер?
И я получаю, что сервер выдаёт 5424 RPS, и выдаёт ответ в среднем за 184мс.

Вот никак не могу разобраться, как сделать что-то похожее с Gatling.
Смотрел все варианты injection profile:
http://gatling.io/docs/current/cheat-sheet/
И получается, что Gatling генерирует нагрузку только вот таким образом:
— Отправляй по X запросов в секунду (constantUsersPerSec) или добавляй по X пользователей в течении какого времени (rampUsersPerSec) и другие комбинации, которые все крутятся вокруг того, что я изначально задаю количество запросов в секунду и посмотреть, как система живёт под такой нагрузкой.
Но что делать, если я хочу нагрузить систему максимально (как Apache Bench) ограниченным количеством пользователей и померить, сколько RPS сервер выдаёт?
— atOnceUsers: Отправь X запросов сразу. Но тут проблема в том, что сразу не получится отправить 100000 запросов просто потому что столько соединений сразу не установишь, да и не надо это.

То есть как сделать запрос по типу: нагружай сервер используя 100 пользователей чтобы они слали запросы один за другим и покажи, сколько запросов (RPS) у них получится сделать?
Так, вроде бы разобрался:
package commonCollection

import io.gatling.core.Predef._
import io.gatling.http.Predef._

class ScsPerformanceSimulation extends Simulation {
  val scsUsers = 50
  val scsReqPerUser = 80

  val scs = exec(http("Test").get("/"))

  val httpConf = http
    .baseURL("http://example.com")
    .disableCaching

  val scn = scenario("Performance Test")
    .repeat(scsReqPerUser) {
      exec(scs)
  }

  setUp(
    scn.inject(atOnceUsers(scsUsers))
  ).protocols(httpConf)
}
В этом случае можно делать так
val scn = scenario("Performance Test").forever(exec(http("Test").get("/")))

setUp(scn.inject(atOnceUsers(numberUsers))).protocols(httpConf)

Тогда получается что несколько потоков в количестве numberUsers будут постоянно делать get на /

Тогда это будет закрытый сценарий где пользователи не выходят из симуляции, у вас в примере открытый где пользователи пройдя по симуляции просто умирают и всё,
Спасибо, не знал про forever. Просто использовал большое число повторений.

Вот теперь пытаюсь понять, что Gatling делать с соединениями: в случае закрытого сценария — используется ли одно соединение на каждого пользователя, которое сохраняется на протяжении всей жизни этого пользователя? Или как-то по другому?
То есть работает ли в Gatling в режиме Keep Alive или нет?

Вот тут описана опция .sharedConnections
http://gatling.io/docs/current/http/http_protocol/#connection-sharing
Я поэкпериментировал и не заметил, чтобы это давало какую-то разницу в результатах.
О, как коварно было оставить tinkoff.ru в тесте :-)
После тестового запуска с локальной машины я попал под fail2ban, похоже — и теперь tinkoff.ru просто не открывается.
Sign up to leave a comment.