@n00b.vcxproj

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

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

Если это имеет значение, писать буду под Линукс, на с++, сервер будет работать с базами Oracle 11g.

Итак, варианты:

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

P.S. Если бы меня не насторожило количество потоков (<50000), я скорее всего бы не стал создавать эту тему, и начал бы писать этим способом. Возникает вопрос: А есть ли ограничения на потоки? Не упадет ли система от такого количества потоков? А падение системы неприемлемо.

2. На каждую функцию(около 100) сделать по потоку с очередью(стеком). Как и в первом способе, accept будет в мэйнстриме. После установления соединения, клиент становится в очередь приема сообщений, и так далее, каждое сообщение обрабатывается в очереди. Я думаю, этот способ более надежный, однако кода здесь будет на много, а то и во много раз больше.

Обсуждайте.

0

@Jtalk

Смотря каких потоков. Если это будут pthreads, то да, для такого количества производительность будет печальна. Плюс накладные расходы при их создании/удалении из-за переключения контекста, а также необходимость хранить информацию по каждому потоку.
Для высоконагруженных сервисов такая модель недопустима.

Вторая реализация будет сильно зависеть от ваших талантов — как напишете синхронизацию между потоками, как будете управлять количеством ядерных потоков и т.д.

Лично я бы не городил велосипеды и взял уже реализованную систему конкурентного программирования — тот же Erlang, например, в зависимости от задачи. Но если требование именно C++, то вам можно только посочувствовать.

Можете посмотреть в сторону библиотек, реализующих быстрые потоки в userspace, но с ними нужно быть очень аккуратным при блокирующих вызовах. Плюс, у таких библиотек могут быть проблемы с "реальной" многозадачностью — те же GNU Portable Threads не умеют использовать SMP, т.е. вам придется запускать несколько копий обработчика по количеству ядер и раздавать им здания вручную, а также контролировать нагруженность этих процессов, что опять же приведет к усложнению архитектуры и разрастанию кода.

1

@Bumerang

Серьёзный проэкт. А реализация потока на сколько я понял делается через сокеты(?) Если так то, каждый поток организуется блокирующим сокетом в дочернем процессе (к примеру через fork) или все делается паралельно одним процессом не блокирующим? Мне кажется в любом случае первый вариант сильно чреват для такого колличества подключений. Даже сославшись на хорошее железо разве этот вариант не более уязвим скажем к DDOS атакам?
===
Если сроки не жмут и есть навыки достаточные для реализации 2-го варианта. Думаю, лучше он. И с точки зрения безопасности и устойчивость системы будет для такого колличества подключений.

0