TCP Server, Нагрузка на сервер Опции

[sobr]

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

[=F8=]

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

[sobr]

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

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

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

[GeGeL]

Суть в том, что щас делаю ТСР сервер к которому будут коннектиться
Десятки тысяч девайсов через GPRS. А сдругой стороны столько же юзеров с компов и айфонов.
Сервер создает практически прозрачный канал между девайсом в машине и юзером, и тот в онлайне мониторит и управляет.

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


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

Сообщение отредактировал GeGeL - May 31 2012, 10:14

[sobr]

Я так понимаю, речь идет о сервере мониторинга объектов (охрана, навигация и т.д.). Тоже занимался аналогичным, сделал так:...

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

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

Ну не совсем. Железка прицепляется к серверу по ТСР, авторизуется и гонит пакеты в бинарном виде. Когда прицепляется юзер через Websockets с такимже идентификатором, сервер переводит пакеты из бинарного в текстовый формат и шлет юзеру и наоборот. От БД пока отказался.

Но -- десятки тысяч, это сколько?

Да хрен его знает, сколько влезет.

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

Вот для того, что бы это выяснить и хочу нагрузить его по самое "не балуйся".

Что касается архитектуры ПО. google C10k problem. Вопрос в архитектуре ПО сервера...

Пока остановился на Node.js

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

VPS только для тренировки "на кошках", буду ставить нормальный сервер.

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

Какая есть, нет возможности с кучи машин одновременно долбить сервер, по тому то и спросил как это можно устроить. Но в моем конкретном случае на 1000 коннектах пока лимитирует лишь процессор память практически не грузится. Сам сервер сжирает 9.5 МБ при 0 коннектов, а при 1000 - 10МБ. А вот нагрузка на проц растет пропорционально открытым сокетам, точнее даже не открытым а передающим.