schizophrenia

 

 

Но зачастую, при чтении приходит значение "-1". Не могли бы, Вы помочь с решением данной проблемы?

Это означает что закрылся сокет. Это не проблема, просто кто-то закрыл соединение. Это можно увидеть в tcpdump по FIN-пакетам

 

Дано:

Есть требование заказчика. Сделайте нагрузочное тестирование. Количество одновременных подключений должно быть 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:)

А какая задача стоит?

Если у вас задача протестировать application, то лучше тестировать по тому протоколу, по которому он и работает. Обычно application стоят за http-серверами и общаются с ними по простому http / fastcgi.

Если задача протестировать реализацию spdy-сервера, то здесь всё сложней. При использовании стандартного API jmeter нельзя написать нормальную реализацию семплеров, которые позволят правильно протестировать протокол в общем. Если есть какая-то частная задача -- можно, но зависит от задачи. Кроме того, при тестировании протокола нужна очень хорошая raw power, которую jmeter не обеспечит без должного внимания.

Поэтому, для задачи тестирования именно spdy-сервера лучше посмотреть на другой инструментарий. В качестве простой бенчмарк утилиты можно взять h2load https://nghttp2.org/...load-howto.html от Tatsuhiro Tsujikawa или взять модуль spdy для phantom https://github.com/bacek/phantom-spdy и зайти в чат яндекс.танка  https://gitter.im/yandex/yandex-tank. В Яндексе реализацию spdy в nginx тестировали через модуль от bacek@

#UPD

Про http/2.0 кстати ответ ровно такой же. Тут на днях вышел семплер https://github.com/s...er-http2-plugin, который позволяет стрелять http/2.0 но лучше этим не пользоваться.

На каждый запрос содаётся группа потоков, которая будет работать с селекторами для асинхронной работы IO

Вся асинхронность обёрнута в блокирующие методы, а в конце работы сокет закрывается, что означает что никакого keep-alive нету, и каждый раз spdy соединение будет устанавливаться заново.

Семплер просто by design не способен обрабатывать нагрузку, у него огроменные накладные расходы. Из-за рождения EventLoopGroup на каждый запрос у него будет очень большая погрешность. Функциональность у него просто никакая, тестировать spdy каждый раз переоткрывая сокет бессмысленно, никакого мультиплекcирования не будет вовсе. Результаты будут хуже чем для http/1.1.

Пользуйтесь h2load, достойных альтернатив пока нет.

Да, конечно сталкивались. Для такой задачи вам лучше всего подойду инструменты, которые оперируют hit-based нагрузкой, такие как wrk или yandex-tank.

Чтобы грамотно его протестировать вам необходимо понять какую именно функциональность вы хотите проверить на производительность. Виды тестов могут быть разными в зависимости от функциональности.

Что именно интересно? Посмотреть на то как хорошо прокисируются запросы, какая latency добавляется при проксировании, сколько одновременных сессий могут висеть, как работает lua / perl? Можно написать в личку:)