Перейти к содержимому

Фотография

Одновременное подключение 150000 коннектов


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 7

#1 AlexPAV

AlexPAV

    Новый участник

  • Members
  • Pip
  • 3 сообщений


Отправлено 22 июля 2015 - 08:37

Здравствуйте, коллеги!

 

Дано:

Есть требование заказчика. Сделайте нагрузочное тестирование. Количество одновременных подключений должно быть 150000.

 

Вопрос:

1.Кто-нибудь пытался такое сделать в принципе? Или это просто невозможно?

2.Может быть для такого тестирования существуют какие-то виды аппроксимации или введение определенного коэффициента. Может быть есть научные методы?

 

С заказчиком, конечно, будем работать, чтобы изменить такие требования.

 

С уважением,

Алексей.


  • 0

#2 ShortLegged

ShortLegged

    Постоянный участник

  • Members
  • PipPipPip
  • 155 сообщений
  • Город:Moscow

Отправлено 22 июля 2015 - 08:46

Возможно. Какой протокол?

 

p.s.

Скорее всего заказчик несколько переоценивает требования по производительности. Кажется что в первую очередь действительно прояснить требования и пожелания заказчика. Сталкивался с переоценкой ожидаемой нагрузки на порядки.


  • 0

#3 AlexPAV

AlexPAV

    Новый участник

  • Members
  • Pip
  • 3 сообщений


Отправлено 22 июля 2015 - 09:01

соединение через https

 

Переоценка может быть и есть, но заказчик хочет быть уверен, что у него все будет работать хорошо.

 

Если возможно, то какое для этого надо железо. Понятно, что распределенное тестирование. Но сколько узлов необходимо?


  • 0

#4 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 22 июля 2015 - 09:38

1) В принципе возможно. Вопрос в том есть ли у вас тестовая площадка на которой вы сможете дать такую нагрузку.

2) Если у вас предусмотрено горизонтальное масштабирование, то вы можете тестировать одну ноду, две, три и дальше делать некоторую аппроксимацию, но вам надо заведомо быть уверенным. что единые для всех нод сервисы, типа балансировщика и БД выдержат конечную нагрузку.

 

Помимо прочего, в тестировании таких нагрузок имеет значение инфраструктура. Например сейчас наши инженеры уже второй день бьются над выяснением почему чтение данных  с диска на релизной площадке в 5-8 раз медленнее чем на тестовой.


  • 0

#5 checo

checo

    Опытный участник

  • Members
  • PipPipPipPip
  • 400 сообщений
  • Город:Н.Новгород

Отправлено 22 июля 2015 - 11:18

Если возможно, то какое для этого надо железо. Понятно, что распределенное тестирование. Но сколько узлов необходимо?

 

Обсуждений таких полно, стоит только поискать. Вот, например: http://stackoverflow...aneously-run-in

В общем, все сходятся на том, что на простой машине максимальное количество тредов - порядка от нескольких сотен до нескольких тысяч. И это при условии, что выдержат память, процессор и сетевой канал. Мы, например, используем облачный сервер, на котором можно временно запросить расширение ресурсов, но тоже задаем всего несколько тысяч (нам больше не надо).

 

Есть сервисы, которые предлагают распределенное тестирование на "очень много" пользователей, и не зря же они берут за это деньги. Например вот или вот.


  • 0

#6 ShortLegged

ShortLegged

    Постоянный участник

  • Members
  • PipPipPip
  • 155 сообщений
  • Город:Moscow

Отправлено 22 июля 2015 - 13:03

Про треды тут можно забыть, лучше смотреть сюда - https://github.com/yandex/yandex-tank

 

Как вариант, начать с jmeter, оценить общее состояние сервиса на 2-3K rps, потом переходить к yandex-tank.


  • 0

#7 Сергей

Сергей

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 245 сообщений
  • Город:Москва

Отправлено 23 июля 2015 - 08:38

Большая просьба отписаться, как в итоге решали задачу.


  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#8 schizophrenia

schizophrenia

    Новый участник

  • Members
  • Pip
  • 58 сообщений
  • ФИО:Mikhail Epikhin
  • Город:Moscow

Отправлено 26 июля 2015 - 22:03

 

Дано:

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


  • 0

July 2015 — Present / Service Reliability Engineer at Yandex 

Sep 2012 — July 2015 / Performance Test Engineer at Yandex 
Feb 2012 — Aug 2012 / Performance Test Engineer at Performance Lab 



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных