Комментарии 17
Слабо себе представляю сценарий, который можно реализовать с помощью Gatling и нельзя с помощью JMeter. И для JMeter есть два официальных плагина для работы с веб-сокетами.
Думаю, что в определенных ситуациях его советы очень пригодятся, но в целом я не согласна с мнением, что если сложно, то надо писать меньше.
Описанная сложность для меня тоже не убедительна, это то, с чем приходится каждый день иметь дело. При грамотно написанных сценариях их поддерживать — это не такая и сложная задача.
А вот ситуация с анализом логов при помощи листика и ручки для меня выглядит пугающей. )
Анализаторы логов автором не дооценены.
Описанная сложность для меня тоже не убедительна, это то, с чем приходится каждый день иметь дело. При грамотно написанных сценариях их поддерживать — это не такая и сложная задача.
А мне сложность кажется реальной. Потому что пользователи работают с приложением. И сценариев его использования много. На какой рассчитывать? Рассчитывать ли, что все пользователи могут единомоментно пользоваться всем функционалом приложения (и, соответственно, — всеми микроприложениями и микросервисами) или мы можем все-таки согласиться, что нагрузка будет меньше. Но нам все равно надо тогда задать пределы для каждого сервиса. В полей рост принцип «разделяй и властвуй». И чем изолированнее компоненты — тем понятнее, какие требования к ним предъявлять
«Потому что пользователи работают с приложением. И сценариев его использования много.»
Это неверное понимание. Сервис всегда предоставляет ограниченный набор действий для пользователя — его функционал. Этот набор всегда известен при тестировании. Из всего этого набора ограниченное количество действий нагружается пользователем — это и есть сценарии для нагрузки, остальное можно отсечь.
В целом по больнице ситуация не очень отражена, как мне кажется.
Против общего посыла статьи не имею ничего. Недавно столкнулся с задачей краеугольным камнем которой была нагрузка! Но мне кажется это пока исключения. Может и есть специалисты выжать из битрикса, как ходовой пример, адекватный результат по нагрузке, нет я как-то не видел. Мне кажется внутренний рынок ещё не очень нуждается в нагрузочном показателе качества.
Мне кажется внутренний рынок ещё не очень нуждается в нагрузочном показателе качества.
Нуждается. Потому что без правильного нагрузочного тестирования и адекватных цифр нельзя управлять инфраструктурой. А экономия на мощностях может быть очень существенной. Что хуже — отсутствие понимания нагрузок будет приводить к факапам с недоступностью систем. Снова и снова. А это финансовые и репутационные потери…
Возможно, я серьёзно недоглядел чего-то в документации, но мне не удалось найти способа, допустим, настроить периодическое событие, запускаемое каждые 30 секунд и выполняющее определённые действия при ответе на сообщение WebSocket, а также производящее действия по HTTP, и всё это в рамках одной HTTP-сессии. Я не нашёл такой возможности ни в одном инструменте нагрузочного тестирования
Это чрезмерное усложнение. Всегда можно создать отдельный поток, отдельное подключение, чтобы реализовать задуманное. Да подключений будет больше, но на производительность и функциональность это чаще всего не влияет.
А стремление создать в тесте производительности поведение реального пользователя — чаще всего недостижимо. И сделать профиль нагрузки на бумажке, лишь опираясь на логи — хороший подход. Тут согласен. Пример такой, по логам можно узнать интенсивность входов. А у аналитика узнать, что треть пользователей выполняет операцию Х. И вот теперь, на листочке, можно примерно оценить интенсивность операции Х, как функции от интенсивности входа, даже если по Х не было никакой статистики.
И симуляция реального пользователя для большой нагрузки (100-1000 запросов в сек) вредна и не нужна. Проблемы автора, думаю, от этой идеи фикс. Но так можно делать для малой нагрузки.
Иногда идея фикс принимает форму: нам нужна нагрузка от 100 000 пользователей, значит нам нужно 100 000 потоков в JMeter.
Иногда такую: пользователь зайдя на сайт с вероятностью 80% ищет телефон, с вероятностью 70% красный, он может уточнить свой поиск, если наше телефон,… В результате люди пишут сложный функциональный тест на JMeter/Gatling, вместо того, чтобы заниматься нагрузкой.
А на деле все проще. От нагрузки требуется создать лишь интенсивность. По возможности повторить время жизни сессии — но это можно делать отдельно, не в JMeter/Gatling/… уже, а в параллельном автотесте, который работает в 1 поток.
Раз автор хочет все сразу, то у него нагрузка малая — до 10 запросов в сек.
Очень поддерживаю, реалистичность — дорого и, чаще всего, не нужно
Нам не нужно 100000 пользователей. Мы можем декомпозировать систему на компоненты.
Если мы знаем, что каждый компонент независим и может обслужить, скажем, 1000 пользователей, то нам нужно 100 экземпляров сервиса, но при этом мы можем его легко и дешево протестировать (единичный экземпляр) изолированно.
Разделяй и властвуй!
В совместной работе через пару лет платформа спокойно держала нагрузку. В какой-то момент я опубликовал сам тул, не пропадать же добру
https://vyatkins.wordpress.com/2016/07/30/velociraptor/
Тут уже мной занялся легал департамент копмании, но потом внимательно почитав статью решили не обострять… Никаких особых секретов я не выдал.
Нагрузочное тестирование выполнять сложно, а инструменты далеки от совершенства. Почему?