Дано:
Есть требование заказчика. Сделайте нагрузочное тестирование. Количество одновременных подключений должно быть 150000.
Вопрос:
1.Кто-нибудь пытался такое сделать в принципе? Или это просто невозможно?
Чтобы сказать браться или нет нужны еще условия, протокол, взаимодействие, более детальное описание работы системы и требования к ней.
Такое возможно, число одновременных сокетов ограничено лишь размером оперативной памяти и числом доступных ip-адресов и портов.
2.Может быть для такого тестирования существуют какие-то виды аппроксимации или введение определенного коэффициента. Может быть есть научные методы?
С заказчиком, конечно, будем работать, чтобы изменить такие требования.
Наверное всё же эстраполяции? На самом деле, на такой задаче лучше не экстраполировать, а эмпирически проверять. Воспользоваться инструментарием, который сможет это сделать, или сделать такой инструментарий самому.
соединение через https
Переоценка может быть и есть, но заказчик хочет быть уверен, что у него все будет работать хорошо.
Если возможно, то какое для этого надо железо. Понятно, что распределенное тестирование. Но сколько узлов необходимо?
Чтобы понять есть ли переоценка, надо взять и протестировать и показать заказчику результаты.
На самом деле пока не ясно нужно ли здесь распределённое тестирование, чтобы говорить точно необходимо понять какие у нас железки есть для load generatorов и сколько с одной можем получить.
Кроме того, надо всё же понять более детально работу сервиса. Есть четыре основные метрики производительности: время, пропускная способность, конкурентность и утилизация. Сейчас в топике обозначена только одна из них. Вопрос в том что именно эти сессии будут делать, как часто по ним будут происходить события, с какой интенсивностью? Как это обрабатывает клиент и сервер? На сколько это затратно по утилизации ресурсов? Какое SLA по времени ответа на эти события?
Обсуждений таких полно, стоит только поискать. Вот, например: http://stackoverflow...aneously-run-in
В общем, все сходятся на том, что на простой машине максимальное количество тредов - порядка от нескольких сотен до нескольких тысяч. И это при условии, что выдержат память, процессор и сетевой канал. Мы, например, используем облачный сервер, на котором можно временно запросить расширение ресурсов, но тоже задаем всего несколько тысяч (нам больше не надо).
Есть сервисы, которые предлагают распределенное тестирование на "очень много" пользователей, и не зря же они берут за это деньги. Например вот или вот.
Я не советую в данной задаче использовать инструментарий с парадигмой 1 thread per 1 user / session, потому что 1 thread тяжеловесная структура, и переключение между ними не такое дешевое как хотелось бы. При использовании такого инструмента вы не сможете иметь хорошую точность по времени ответа / пропусной способности / конкурентности и даже утилизации.
А сервисы с внешними облаками -- черные ящики. Не ясно сколько userов они пускают одновременно на одном физ. процессоре и как оно внутри работает. Если на своём железе погрешность можно оценить, то в облаках это на порядок сложней. Да и разориться можно, дорогое удовольствие.
Про треды тут можно забыть, лучше смотреть сюда - https://github.com/yandex/yandex-tank
Как вариант, начать с jmeter, оценить общее состояние сервиса на 2-3K rps, потом переходить к yandex-tank.
Чтобы выбрать инструмент надо точно понимать в чём задача, сейчас не совсем ясно в чём же именно она.
Jmeter без кастомных вставок точно не годится, а не меняя парадигму 1 thread per 1 user вам мало кто может написать свой plugin.
yandex-tank поможет только если задача сводится к 150 тыс. keep-alive сессий, через которые дёргаем http-запросы. С большим числом https-сессий в phantom из yandex-tank есть определённые затыки, но вопрос какой throughput нужен?
Вообщем, если нужна помощь, то опишите задачу как она есть. Сейчас сложно что-то советовать. Можно в личку, можно в skype:)