Чем, как протестировать нагрузочную способность TCP сервера?

Что, никто не тестирует свои серваки? Или сервакими не пользуемся?

А что значит нагрузочная способность? Сколько соедениний тянет? На каком потоке данных затыкается? Если второе то для GPRS это вообще неактуально.
PS как вариант берете любой VirtualSerial<->TCP (например этот http://www.hw-group.com/products/hw_vsp/index_en.html) соеденяетесь с сервером и копируете в этот порт файл.
Вот еще ipref то-же под винду http://mayoxide.com/iperf/

В общем случае: нужна программа имитирующая нормальную работу того, что там к серверу подключается. Желательно в over9000 потоков. Потом на over9000 компьютерах запускается over9000 копий (на каждом) и смотрится время отклика, используемая память и где узкие места и т.п.

Если сервер web, то есть готовое ПО. Или можно прямо тут адрес написать, тебе и протестируют сразу всё подряд.

over 9000 на несчастный контроллер?

Какой контроллер, вы о чем?
Я имею в виду сервер в дата-центре.
Суть в том, что щас делаю ТСР сервер к которому будут коннектиться
Десятки тысяч девайсов через GPRS. А сдругой стороны столько же юзеров с компов и айфонов.
Сервер создает практически прозрачный канал между девайсом в машине и юзером, и тот в онлайне мониторит и управляет.
Вот и встал вопрос какой мощности железо надо ставить в датацентре.
С ходу не нашел готовый инструмент для стресс-теста.
Пока выкрутился так: сам сервер VPS 600 MGz, на другом таком же плодятся клиенты в количестве 1000 и хором каждую секунду на мой сервак отправляют пакеты по 100 байт.
Проц нагрузился на 15%. тест конечно не очень коректный, но в первим приближении пойдет.

А те виртуальные серверы под винду на которые вы ссылки привели попробуйте хотя бы 1000 сокетов нагрузить, скорее всего разочаруетесь.

Wooow!



Я правильно понимаю, сервер просто из тцп/удп сокета айфона отправляет в тцп/удп сокет прибора, и наоборот? Т.е. практически обработки информации нет. Это резко меняет дело. Потому, что когда речь идёт о БД, о вебе со скриптами, об каких-то других приложениях -- это одно. А тут просто proxy.

Если так, то в принципе почти хватит обычного IBM-PC. Но -- десятки тысяч, это сколько? Тут дальше начинаются вопросы связанные в основном с архитектурой ПО в первую очередь, во второй очереди лимит количества (полу)пустых пакетов в секунду, на сетевом интерфейсе. Для 100Мбит сети во втором случае речь будет идти где-то о 64к пакетов в секунду, с другой стороны поддержать более 64к коннектов на один тцп/удп порт тоже не получится. Но 100МБит сеть закончится в пределах датацентра и дааалеко не факт, что хостинг-провайдер будет иметь достаточно хорошую связность с опсосами, но это отдельный вопрос и пока далёкий. Зато недалёким видится вопрос в регулярной нарушении оной связности, что бывает в любом датацентре, и жалобы десятков тысяч клиентов. А также различные сбои ПО, сети, чего угодно ещё. Напрашивается по меньшей мере два различных сервера на двух разных площадках, множественные A-записи в DNS, и ещё скорей какие-то методы балансирования нагрузки на уровне IP-протокола (маршрутизации). Если это только прокси. Иначе ещё и репликация БД.

Что касается архитектуры ПО. google C10k problem. Вопрос в архитектуре ПО сервера. Скорей это небольшое число потоков и параллельных программ (в 2-4 раза большее, чем количество процессоров в сервере), где каждый из потоков (я бы не рекомендовал увлекаться многопоточным программированием без нужды, классические средства межпроцессного взаимодействия позволяют всё то же самое, почти, но при этом граница между процессами более явно видна не сложно вляпаться в неочевидные трудности) или программ обрабатывает достаточно большое (единицы тысяч) соединений. Здесь становится очевидно, что proxy таким образом построить достаточно легко (пример nginx), а сложные приложения, со своей сложной логикой, БД и т.п. -- не очень-то. И стоит сказать про ограничения операционной системы. По-умолчанию обычно больше ~1024 файлов (соединнений) на процесс не открыть, придётся настраивать ОС, вплоть до перекомпиляции ядра (я немножко не в теме, но знаю, проблема есть). Объём ОЗУ опять же. Несколько десятков-сотен КБайт на стек и соединение (одно!) при многопоточном программировнии (C10k -- можно забыть) или несколько килобайт при описываемом подходе.



VPS. Позволяет масштабирование по ресурсам и деньгам в весьма широких пределах.



Бредовая оценка. Зачастую лимитирует отнюдь не процессор. А (зависит от софта) размер ОЗУ, ограничения ОС на число открытых сокетов, пропускная способность сети и даже непосредственно сетевой карты. А также тип технологии виртуализации.



AFAIK винда просто не позволяет более N соединений по лицензионным соображениям. Какие десятки тысяч? Только если ultimate-enterprise edition.

Во... Беседа началась. С вашего позволения завтра с компа отвечу, а то с "огрызка" тяжко много писАть.

Проще свою тестилку написать и запустить 100500 экземпляров с разных машин. Есть в природе и готовые утилиты, только я ими не пользовался. Попробуйте JMeter или LoadRunner.

Закажите DDoS на свой адрес =)

Я так понимаю, речь идет о сервере мониторинга объектов (охрана, навигация и т.д.). Тоже занимался аналогичным, сделал так:
- использую самый дешевый VDS (P500 MHz, 256 RAM с Ubuntu), 5 уе/мес
- обработка на сервере МИНИМАЛЬНА: в одном потоке разруливание пакетов и архивация , причем не в БД, а в суточный двоичный файл в собственном сжатом формате с метками времени. Доступ клиента к архиву через свой UDP-протокол, использующий метки времени.
- связь с объектами и с клиентами (диспетчера, визуализация, управление) - только UDP, на сервере ОДИН сокет, так гораздо економнее по ресурсам.
- каждый клиент поддерживает связь с помощью KeepAlive, отваливается по таймауту, каждое устройство требует подтверждения данных сервером, но не на каждый пакет, а по необходимости.
- сервер также обеспечивает транзит управляющий пакетов "клиент - устройство" туда и обратно.
- все остальные вычисления, обработка, фильтрация, сортировка, выборка и т.п. - на клиентской программе.


Многое зависит также от программирования: все желательно делать компакно и оптимально по коду, заранее чувствуя, как оно будет тянуть ресурс.
А вот что касается не-windows - юзеров (Android, iOS etc) - вопрос пока остался открытым. Возможно, придется тоже подымать второй сервер c Apachi и на php делать мультиюзера, работающего с браузерными клиентами, но это уже другой разговор.

И сколько клиентов одновременно держит?


Ну не совсем. Железка прицепляется к серверу по ТСР, авторизуется и гонит пакеты в бинарном виде. Когда прицепляется юзер через Websockets с такимже идентификатором, сервер переводит пакеты из бинарного в текстовый формат и шлет юзеру и наоборот. От БД пока отказался.
Да хрен его знает, сколько влезет.
Вот для того, что бы это выяснить и хочу нагрузить его по самое "не балуйся".
Пока остановился на Node.js
VPS только для тренировки "на кошках", буду ставить нормальный сервер.
Какая есть, нет возможности с кучи машин одновременно долбить сервер, по тому то и спросил как это можно устроить. Но в моем конкретном случае на 1000 коннектах пока лимитирует лишь процессор память практически не грузится. Сам сервер сжирает 9.5 МБ при 0 коннектов, а при 1000 - 10МБ. А вот нагрузка на проц растет пропорционально открытым сокетам, точнее даже не открытым а передающим.

Зря. Половина нагрузки ( по вашим словам) ляжет на БД. А лучше чем там не напишете

ЗЫ А чем вам не нравится синтез анализ? Прямо в код сервера включите "клиентов" передающих. Тогда всё что вам надо будет потом - обеспечить достаточный канал. Я на Qt генерил сигналы коннекта и передачи вручную, в отдельном потоке. Нажал кнопку - добавил в тело 1 клиента. И так жамкаешь пока уже кнопка/GUI не жамкается, а зависает Потом GUI убрал - ещё и запас появился.

Так вот я и пытаюсь донести мысль... В моей архитектуре как бы нет понятия "к-во клиентов", ибо они используют udp, т.е. в любой момент любая железка и любой клиент могут отправить единичный пакет, и он будет обработан. Значимым есть не к-во клиентов, а их общая активность.
Конечно, если открывать тсп для каждого клиента и каждой железки, то VDS будет для кошек. Но это ведь следствие неверного (студенческого) проектирования. Кроме проблемы ресурсов, установленное тсп подразумевает жесткий учет переданных-принятых байт и разрыв сесии при невостановлении. Это не всегда оптимально для нашей задачи (а особенно со стороны движущихся объектов с их реконектами).


А зря вы так считаете... Да, лучше не напишешь, но ведь универсальных вещей хороших не бывает. И если заточить конкретно под задачу, то однозначно выйдет лучше.
У меня БД организована в виде суточных бинарных файлов, фрагменты которых по необходимости клиент может получить на локаль и там уже анализировать и извлекать что надо. Сервер работает с файлами через стандартные open, fgetc и т.д. Оцените экономию ресурса в сравнении, скажем с SQL

Ничего не понял


Я это и имел в виду когда спрашивал о количестве клиентов. Какое количество активных клиентов выдержит ваш сервер с "KeepAlive"? У меня тоже каждый клиент и каждая железка могут в любой момент отправить пакет, и он будет обработан. А вот с удп сомневаюсь что каждый...

Я имею в виду , что ему же надо работать и с клиентами и с M2M. Логичнее и надёжнее развязать это БД. Т.е. два серверных приложения, работающих с разными видами TCP|UDP клиентов. Опять же БД можно будет привязать потом и на WEB. Т.е. масштабировать систему будет легче.
Правда управлять устройствами можно будет только постфактум. Т.е. устройство само через приложение по определённому протоколу лезет в БД и забирает необходимые данные.

Т.е. есть БД, как средоточие всего. Есть приложения клиентов, есть приложение устройств. Если у вас увеличивается нагрузка на часть устройств запускаете ещё одно приложение на другом порте или хосте. Получается такая "паутинка" из подключённых к БД приложений, которые в силу мощности серверной части самой БД не влияют друг на друга.





Проверку "нагрузки" включите в исходный код сервера

Это интересная архитектура, но есть два но:
1. это управление постфактум. Боюсь, sobr это не устроит, исходя из специфики его приложений.
2. мощность сервера. Конечно, если это огромная компания, то пофиг: окупится. Но для старта не совсем удобно.

Я так сделал: на минимальном VDS кручу демон, опрашивающий в единственном потоке единственный удп-сокет с достаточно объемным буфером. М2М у меня тоже имеют "отложенное управление" - они активны, и получить управляющий пакет могут лишь после отправки своего (а отправляют они по фоновому интервалу, и по событию - в среднем 12-16 байт на пакет, никакого текста, все bin). Пакет имеет флаг необходимости подтверждения, М2М сам определяет критичность пакета.
Сервер эти пакеты обрабатывает минимально: проверяет КС, определяет номер М2М, пишет в суточный бинарный файл (как бы БД), по необходимости подтверждает и пересылает необходимым клиентам в неизменном виде через тот же сокет.
С клиентами по другому: сервер должен иметь их айпи-порты. Для этого использую массив с одним int (IP) и двумя short (порт и номер клиента). С помощью периодически отправляемых KeepAlive клиент прописывается в свободном слоте (записи массива). Получается 8 байт ОЗУ на клиента.
Но это хорошо, т.к. у меня клиентов много меньше, чем М2М (клиенты-это диспетчера групп М2М). Если клиентов равно М2М (думаю, у sobr именно так), то есть смысл заранее создать массив по количеству клиентов из int (IP) и short (port) (6 байт на клиента), так быстрее будет искать его.
То же самое придется сделать и для М2М, если необходимо обеспечить моментальное управление их клиентами.

Что касается работы с архивом, то это не так часто требуется, одновременное выполнение таких запросов ограничено всего 16-ю (теоретически ограничивается количеством открытых файлов в системе). Инициируется клиентом запрос с указанием даты (по ней определяется имя файла архива), диапазона времени, номера клиента. Сервер открывает нужный файл архива (там находятся пакеты) и соотв. индексный файл (туда через определенные интервалы времени пишется позиция основного файла). fseek переводит основной файл на нужную позицию, отбираются записи по нужному М2М (или по всем) и отправляются клиенту серией удп-пакетов с КС и инкрементируемыми идентификаторами. Клиент их пишет в свою БД и далее делает анализ своими силами.

Т.о. сервер использует фантастически минимальный ресурс без особой потери в гарантии обслуживания за счет опционного подтверждения пакетов. Ну и код для gcc пишется за пару вечеров...