Спасибо, не знал про forever. Просто использовал большое число повторений.
Вот теперь пытаюсь понять, что Gatling делать с соединениями: в случае закрытого сценария — используется ли одно соединение на каждого пользователя, которое сохраняется на протяжении всей жизни этого пользователя? Или как-то по другому?
То есть работает ли в Gatling в режиме Keep Alive или нет?
Мне вот на днях дали задачу нагрузить 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) у них получится сделать?
Поделюсь одной весьма полезной штукой, появившейся в последних файловых системах, о которых почему-то пока ещё редко упоминают, говоря о backup.
Преположил, что вы настроили backup, и делаете две копии, и даже offsite, и проверяете их.
Но случилось так, что часть этих данных была удалена / испорчена / отредактирована… НО ЭТО СРАЗУ НЕ ОБНАРУЖИЛИ.
И backup забэкапил скомпроментированные данные. Приплыли…
Так вот в ZFS, BTRFS есть снэпшоты — крутая штука. Позволяет вернуться к состояниям любых файлов в прошлом, для которых есть спэпшоты. Я делаю снэпшоты каждую неделю (хотя можно делать хоть каждые пять минут).
Конечно, совсем правильно делать снэпшоты не на продуктиве, а на бэкапе, но на современных файловых системах снэпшоты практически не тормозят систему и очень удобны.
И да, конечно, снэпшоты — это не бэкап, может быть только полу-бэкап (решает проблему компроментации данных, но не решает потерю физического носителя — дисков или контроллера).
Вот только бывает случаи, когда блокируются не порты, а протокол. Не знаю, как TV ведёт себя в этом случае. Знаю, что Chrome Remote Desktop «не пролазиет» через наш корпоративный прокси.
Противоречия нет:
— админские права нужны на удалённо компьютере, где мы ставим VNC и noVNC
— на стороне клиента нужен только браузер. Админские права не нужны
Сам я TeamViewer QS не пробовал, но
— похоже его надо запускать на удалённом компьютере, тогда как noVNC может работать как сёрвис.
— да, Team Viewer (не QS) можно поставить, как сёрвис. Вот интересно в этом случае, — нужно ли инсталлировать что-то клиентской стороне? И будет ли это работать в организациях, где заблокировано всё, кроме HTTP?
Вопрос: а есть ли похожие материалы для ELK? Можно на русском или на английском. Пока я гуглил — большей частью всё туториалы, как установить, но не про то как строить интересные репорты.
И соответсвенно ещё один вопрос: насколько в таких задачах ELK сравним со Splunk — проще / сложнее?
Вот какая несправедливость:
У американцев email взламывали и АНБ и ЦРУ, а когда их поймали на этом деле (Сноуден, Vault 7), то как они были недовольны!
А вот когда тоже самое сделали русские (взломали почту Yahoo), то тут у них бомбануло...:
Нам вот можно, а вы куда лезете?!
У меня была задача протестировать нагрузку сервиса, в который через 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.
Самая засада с Agile у меня была, когда я работал QA менеджером в медицинской компании (выпускали медицинский софт). Специфика была такая, что:
— Наше направление деятельности довольно серьёзно регулируется федеральными и штатовскими законами (США), такими как HIPAA, FDA Title 21
— У нас сертификация ISO, так что всё должно идти в соответствии с процессами
— От штата и от ISO к нам аудиторы приезжают и проверяют.
Поэтому, что бы писать софт по всем правилам, были такие вещи:
— У нас были чётко описанные WI (Work Instructions) и SOP (Standard Operating Instructions), в которых довольно детально описывалось, как должно проходить тестирование, как проверяются баги и т.д.
— Мы должны были выдавать (или принимать участие) горы документации, включая: требования, трассировку требований, тест план, тест протоколы, анализ рисков и т.д.
В общем по моему мнению, у нас был водопад. Да, было несколько забюрократизировано, но в общем вменяемо.
Но потом, похожа какая-то муха укусило начальство, и нам стали говорить, что мы «недостаточно agile»… Наняли начальника разработки специально, чтобы выстраивать agile-процесс.
Я всё никак не мог взять в толк: как можно совместить agile-процесс со всей бюрократией и процессами специфичными для наших продуктов?
Вот и натягивали сову на глобус… Сначало ушло несколько разработчиков. Потом ушёл я. Что было потом — не знаю, но сейчас настраиватель agile-процессов уже там не работает.
А вот сейчас я работаю в компании, где у нас SaaS, не связанный с медицинской сферой. У нас — практически чистый Agile, и всё идёт, как надо.
Не в порядке исправления, а больше в плане дискуссии / развития своего английского:
Мне кажется выражение «meaningful interference» более правильно перевести, как «значимая» или «значительная» помеха. Как думаете?
https://www.synology.com/en-us/releaseNote/DS412+
Вот теперь пытаюсь понять, что Gatling делать с соединениями: в случае закрытого сценария — используется ли одно соединение на каждого пользователя, которое сохраняется на протяжении всей жизни этого пользователя? Или как-то по другому?
То есть работает ли в Gatling в режиме Keep Alive или нет?
Вот тут описана опция .sharedConnections
http://gatling.io/docs/current/http/http_protocol/#connection-sharing
Я поэкпериментировал и не заметил, чтобы это давало какую-то разницу в результатах.
Мне вот на днях дали задачу нагрузить 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) у них получится сделать?
Преположил, что вы настроили backup, и делаете две копии, и даже offsite, и проверяете их.
Но случилось так, что часть этих данных была удалена / испорчена / отредактирована… НО ЭТО СРАЗУ НЕ ОБНАРУЖИЛИ.
И backup забэкапил скомпроментированные данные. Приплыли…
Так вот в ZFS, BTRFS есть снэпшоты — крутая штука. Позволяет вернуться к состояниям любых файлов в прошлом, для которых есть спэпшоты. Я делаю снэпшоты каждую неделю (хотя можно делать хоть каждые пять минут).
Конечно, совсем правильно делать снэпшоты не на продуктиве, а на бэкапе, но на современных файловых системах снэпшоты практически не тормозят систему и очень удобны.
И да, конечно, снэпшоты — это не бэкап, может быть только полу-бэкап (решает проблему компроментации данных, но не решает потерю физического носителя — дисков или контроллера).
Вот только бывает случаи, когда блокируются не порты, а протокол. Не знаю, как TV ведёт себя в этом случае. Знаю, что Chrome Remote Desktop «не пролазиет» через наш корпоративный прокси.
— админские права нужны на удалённо компьютере, где мы ставим VNC и noVNC
— на стороне клиента нужен только браузер. Админские права не нужны
Хотя я так понял, что у него другие цели. И работает он через тот же протокол RDP. Верно?
Пишут, что они не поддерживают tight, но поддерживают tightPNG и это самый быстрый режим для noVNC.
Теперь надо вот разобраться, какие VNC серверы поддерживают tightPNG.
В общем, noVNC работает заметно медленней RDP, но вполне терпимо.
Сам я TeamViewer QS не пробовал, но
— похоже его надо запускать на удалённом компьютере, тогда как noVNC может работать как сёрвис.
— да, Team Viewer (не QS) можно поставить, как сёрвис. Вот интересно в этом случае, — нужно ли инсталлировать что-то клиентской стороне? И будет ли это работать в организациях, где заблокировано всё, кроме HTTP?
Вопрос: а есть ли похожие материалы для ELK? Можно на русском или на английском. Пока я гуглил — большей частью всё туториалы, как установить, но не про то как строить интересные репорты.
И соответсвенно ещё один вопрос: насколько в таких задачах ELK сравним со Splunk — проще / сложнее?
Попробовал без OpenDNS, и там в довесок идёт килограм рекламы из непонятного источника…
У американцев email взламывали и АНБ и ЦРУ, а когда их поймали на этом деле (Сноуден, Vault 7), то как они были недовольны!
А вот когда тоже самое сделали русские (взломали почту Yahoo), то тут у них бомбануло...:
Нам вот можно, а вы куда лезете?!
Я начал писать скрипт на 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.
Я почитал, и вроде бы записывать видео можно, но похоже система не заточена под это?
— Наше направление деятельности довольно серьёзно регулируется федеральными и штатовскими законами (США), такими как HIPAA, FDA Title 21
— У нас сертификация ISO, так что всё должно идти в соответствии с процессами
— От штата и от ISO к нам аудиторы приезжают и проверяют.
Поэтому, что бы писать софт по всем правилам, были такие вещи:
— У нас были чётко описанные WI (Work Instructions) и SOP (Standard Operating Instructions), в которых довольно детально описывалось, как должно проходить тестирование, как проверяются баги и т.д.
— Мы должны были выдавать (или принимать участие) горы документации, включая: требования, трассировку требований, тест план, тест протоколы, анализ рисков и т.д.
В общем по моему мнению, у нас был водопад. Да, было несколько забюрократизировано, но в общем вменяемо.
Но потом, похожа какая-то муха укусило начальство, и нам стали говорить, что мы «недостаточно agile»… Наняли начальника разработки специально, чтобы выстраивать agile-процесс.
Я всё никак не мог взять в толк: как можно совместить agile-процесс со всей бюрократией и процессами специфичными для наших продуктов?
Вот и натягивали сову на глобус… Сначало ушло несколько разработчиков. Потом ушёл я. Что было потом — не знаю, но сейчас настраиватель agile-процессов уже там не работает.
А вот сейчас я работаю в компании, где у нас SaaS, не связанный с медицинской сферой. У нас — практически чистый Agile, и всё идёт, как надо.
Вывод: Для каждой работы — свой инструмент.
Не в порядке исправления, а больше в плане дискуссии / развития своего английского:
Мне кажется выражение «meaningful interference» более правильно перевести, как «значимая» или «значительная» помеха. Как думаете?
Но на такой финт у них есть болт — называется structuring.