testomat.io управление авто тестамиЭто был ответ на ваше сообщение
“Почитаю мануал, напишу пару скриптов и стану эспертом в нагрузочном тестировании”
Извините, это был сарказм.
Ок), только вот я сказал совсем не
Почитаю мануал, напишу пару скриптов и стану эспертом в нагрузочном тестировании
а,
достаточно взять тулзу типа apache jmeter, yandex tank, почитать мануал, включить голову, и можно уже получить минимальные результаты
Вы подменили “получить минимальные результаты” на “стану экспертом в нагрузочном тестировании”. А ведь смысл совершенно разный.
“достаточно взять тулзу типа apache jmeter, yandex tank, почитать мануал, включить голову, и можно уже получить минимальные результаты” - это покажет что вы умеете писать скрипты и запускать их. Все равно что почитать мануал по Java, написать “Hello world” приложение и сказать что я умею программировать и готов писать production код.
Вот пример из моего опыта, когда я делал именно так как Вы говорите.
Изучил инструмент (на тот момент - HP LoadRunner)
Подготовил скрипт (FrontEnd - ExtJs)
Запустил и показал, что мое приложение может работать с 50 concurrent users (потому что я же мерял response time страниц и результаты были удовлетворительными), работая на 4 CPU/16 Gb RAM. Именно это я сказал заказчику и он был счастлив…
Но потом, когда я получше разобрался с технологией Ajax - я понял, что мерять загрузку страниц без загрузки Ajax комопнентов - это бесполезная работа. И что основная нагрузка - это как из этих запросов. И что реальная “выносливость” системы была 1-2 concurrent users. Выходит, я ввел заказчика в заблуждение, потому что не был экспертом в своем деле.
Если вы делаете работу и просите за это деньги - вы должны делать ее правильно.
Владимир, ну что же все старательно переиначиваете мои слова 
Ей богу, уже даже несмешно 
. Ну как можно приравнять “получить минимальные результаты” и “написать “Hello world” приложение и сказать что я умею программировать и готов писать production код”. Написать хелловорлд - это есть минимальные результаты, но ни как не готовность писать продакшн код.
А по поводу
Вам как Performance Engineer нужно определить требования к системе.
Тут и без перформанс-инженера прекрасно разберутся заказчик и разработчик, особенно если такого инженера нет (как сказал автор). Тут заказчик, разработчик и девопс (опционально) вполне сообразят на троих, без необходимости нанимать лишний рот, который нужно кормить.
Узнаю себя 10 лет назад, работая в одной из украинских оутсорсинговых компаниях.
Тратить свое время на бесполезную дискуссию дальше не вижу смысла, все равно что общаться со школьником 7-го класс о пользе изучения физики или высшей математики.
Удачи в вашей работе. Могу ответить на конкретные вопросы по организации процесса нагрузочного тестирования и решения технич. вопросов, но обсуждать “необходимость учиться прежде чем вставлять отвертку куда-ни попадя” я не собираюсь.
Спасибо за хорошие пожелания, и вам приятной работы.
За это тоже спасибо, только тут и без ментора разобраться на полвечера. Вы лучше автору поста помогите по-настоящему и желательно бесплатно
Эх, жаль что инженер по нагрузке не выдержал нагрузки. Но приятно было пообщаться 
Успехов в вашем нелегком деле.
Вам также спасибо за пожелания. Без всякого сарказма и никакой личной неприязни. Как я и написал, понимание приходит с опытом и возрастом. И оно обязательно прийдет.
Насчет помощи - я с удовольствием помогу советом бесплатно, но без срача типа теплого и мягкого.
Владимир так и я вам тоже без сарказма и уж тем более личной неприязни. Этот разговор - приятное отвлечение от текущей рутины
Раздели задачу хотя бы на три разные stories
- Бизнес требования
- Почему 500 человек - откуда цифра, что она отображает? Каких 500 человек (какое поведение/сценарии)? Как действуют пользователи - опытный (открывает страницу, сразу кликает на ссылку, описание товара не читает, сразу добавляет в корзину и делает checkout). Или новый, который делает эти операции в 5 раз медленнее?
- Ответ на вопрос - что значит что приложение работает хорошо или плохо? Какие метрики используем для ответа?
Например, мы для backend - это может быть Response Time <= 500 msec. Определяется SLA - и для разных запросов они могут существенно отличаться.
- Генерация нагрузки
- Выбор инструмента и подхода.
например, можно записать поведение пользователя и сгенерировать сценарий (fiddler и множество других бесплатных инструментов). Опять же нужно понимать архитектуру приложения - монолит, microservices, serverless. Как я понимаю, у вас есть API (скорее всего RESTful API), которые используются фронтендом. Разработайте сценарий в том же Postman c последовательностью шагов для решения бизнес-задачи (например, Login->fetch product → put to shopping box → Checkout) напрямую на бэкенд (без необходимости генерировать HTML).
Если нет опыта разработки - выбирайте Jmeter - там большую часть несложных задач (без необходимости сложной корреляции) можно решить без кода. - выбор среды выполнения нагрузки - где вы собираетесь запускать ваши скрипты?
Например, пропускной способности нашей локальной сети компании достаточно
Нас не заблокирует провайдер, AWS и т.д. Наш траффик не будет рассмотрен как DDOS атака.
Или мы должны выполнять нагрузку в той же сети где и Backend. Нагрузка на сервисы напрямую или на Application Live Balancer/ API Gateway
Используются механизмы кеширования и как их обходить чтоб не тестировать сам кэш.
Для генерации нагрузки в 500 concurrent users с реалистичным сценарием (проставкой хотя бы 5-10 секунд между запросами), одной машины в 2 CPU/ 4Gb RAM думаю хватит. Опять же, без сложных вычислений и обработки массивов данных. Иначе уже может понадобиться больше памяти и CPU.
- Мониторинг и анализ результатов
На каком окружении находится система (Backend) - из каких компонентов состоит. Какие риски. Можем ли конфигурировать и мониторить эти компоненты. Какие метрики должны получить от мониторов.
Сторонние сервисы, которые мы можем сломать при нагрузке. Или влияют на результат.
Это лишь верхушка айсберга тех вопросов, ответы на которые нужно найти прежде чем приступать к реальным нагрузочным тестам.