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

[sobr]

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

[GeGeL]

Это интересная архитектура, но есть два но:
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 пишется за пару вечеров...

Сообщение отредактировал GeGeL - Jun 1 2012, 17:03