Комментарии 5
Одним из важнейших вопросов инструментов на рынке инструментов особенно написанных на Java, Python и прочих языках это границы погрешности и отказа именно самих инструментов. Где проходит та самая грань где мы уже видим деградацию производительности инструмента. Проще говоря как проводить поверку подобным инструментам и доверять действительно нагруженные системы. Отсюда следующий шаг про сложность проведения нагрузочного тестирования требующего внимания и очень высокой квалификации специалиста.
locust с fasthttpclient для нагрузки http сервисов дает хорошую производительность, но запускать его надо как master-slave по количеству ядер, а еще можно на нескольких серверах
Хорошую, отличную или совсем великолепную? Можно по подробнее, что это качественная оценка означет. Не станет ли проблемой собственная производительность Python в какой-то момент? А если и станет, то какой инструмент внутреннего мониторинга производительности сигнализирует об этом? Понятное дело, что можно масштабировать, но вопрос когда это стоит начинать делать, а то может сразу начинать с использования другиого инструмента и не тратить время. Вот именно об этой неопределенности я и говорю, что это просто такая игрушка попробовать пошевелить систему, но реального понимания вы не достигните, так как не узнаете стоимость самого движка. Стоимость движка вы узнаете только в том случае если начнете еще и профилировать свою систему (не знаю поддерживает ли Python какие-то механизмы Runtime профилирования).
Не самую большую в классе (k6 делает это лучше), но у локуста ее можно наращивать добавлением серверов. По поводу внутреннего торможения из-за питона, это достаточно легко отслеживается по ресурсам сервера и загрузке процессора после парочки тестовых запусков, внутренних механизмов понять это, к сожалению нет. Мы в самом большом сетапе нашем, запускали локуст на 9 серверах по 16 ядер в 9х16 потоков с выделением мастера на отдельный маленький сервер, rps не скажу, т.к. был не совсем http траффик.
Locust удобный инструмент для проведения быстрого нагрузочного тестирования с получением данных прямо сейчас и регулировкой нагрузки кнопочками в интерфейсе.
По поводу внутреннего торможения из-за питона, это достаточно легко отслеживается по ресурсам сервера и загрузке процессора после парочки тестовых запусков, внутренних механизмов понять это, к сожалению нет.
Выходит механизма для регулирования исходящей нагрузки у данного инструмента нет? А если есть, то как вы можете говорить, что 80% загрузка CPU это не 20% простоя на этом регулировании, а остальное время это перегрузка CPU в циклах Python.
Монитортинг CPU в данном случае работает только в случае проведения стресс испытаний.
rps не скажу, т.к. был не совсем http траффик.
Не очень понятно чем вы занимались и что выяснили, так как основную характеристику (кстати лучше говорить тогда уже о HPS) не выяснили, но понятно, что задействовано несколько серверов для масштабирования.
Locust удобный инструмент для проведения быстрого нагрузочного тестирования
И получения непонятного результата. Где в целом не так важен результат. Подозреваю, что при проведении поверки самого инструмента всплывет уйма не самых миловидных для инструмента деталей.
Locust: проводим нагрузочное тестирование