Высоконагруженный сокет-сервер?

Доброго времени суток, уважаемые хабровчане!



Пишу свой первый высоконагруженный сокет сервер (порядка 5000к клиентов) под *nix. Алгоритм таков, что соединение с клиентом нужно держать, пока он сам его не разорвет.

Вопрос. Как правильно организовать многопоточность и IPC?

ОС: *nix.

Язык: C++.



Что уже искал. Гугл дает реализации, в которых процессы с потоками отрабатывают запрос и отключаются…

Мне же необходимо активным потокам взаимодействовать с родителем, или чем-нить еще, для постоянного обновления статистики… (вариант с БД пока не приемлем)

Подскажите, пожалуйста, идею или где копнуть, как реализовать сервер с такой нагрузкой, т.е. как правильно упорядочить accept()+fork()+pthread_create() и какой вид IPC лучше подойдет для такого рода нагрузок? Что из видов IPC сможет выдержать нагрузки в 5-10к клиентов? с минимумом задержек естественно…



Изучая исходники Open Source веб-серверов, ничего не получил… ибо «отрабатывают запрос и отключаются»…



я правильно понял, что это не больно-то тривиальная проблема?



Спасибо.
  • Вопрос задан
  • 7894 просмотра
Решения вопроса 1
vanxant
@vanxant
1. Забудьте про треды и тем более процессы, 5-10к тредов не выдержит никакая ось.
2. Соответственно только неблокирующий ввод-вывод. Один поток занимается только i/o и сбрасывает полученные данные другим потокам… Вы бы сказали всё же какая у вас задача, а то это пальцем в небо.
3. Нормально реализовать неблокирующий и/о с первого раза сложно, со второго тоже… Там внутрях каждой оси много «трюков», которые нет-нет да заблокируют ваш поток. Очень советую использовать libevent или что-то вроде того.
4. Если уж собираете статистику и всё такое, не изобретайте велосипед и возьмите хотя бы SQLite. Иначе опять же соберете кучу граблей и косяков с конкурентностью, взаимными блокировками потоков, крахом базы при падении сервера, рейсами и прочими прелестями многопоточки. SQLite можно встроить прямо в вашу прогу, для внешнего наблюдателя её как бы и не будет.
Ответ написан
Пригласить эксперта
Ответы на вопрос 6
@korvindest
Мне кажется вам лучше смотреть в сторону openSource СУБД типа PostgreSQL ведь СУБД то как раз должны держать коннект, до тех пор пока он не будет разорван клиентом.

Хотя конечно, подозреваю, что выковыривать от туда сей механизм будет не просто.
Ответ написан
@rPman
Я не специалист, но фраза 'какой из механизмов IPC выдержит' немного странная, какая разница, если в ОС штатно только один — message queue, shared memory и semaphore, что бы вы не выбрали, будет использовать их (особо кривые что то одно).

Не совсем веб-проект, но для распараллеливания задачи пришлось использовать и очереди и семафоры (очень активное использование), рекомендую не передавать данные в очереди, она быстро кончается… максимум идентификаторы и подробности через shared memory или другие механизмы.
Возможно, не стоит создавать один семафор на все, лучше под напрячься и по семафору на объект или хотя бы группу (чтобы блокировать только на доступ к группе а не всех ко всему) — этот подход может дать наверное максимально возможный прирост, когда упретесь в потолок (особенно грустно когда процессоры еще не нагружен и демоны чего то ждут), это в смысле организации многопроцессорного демона (или демон на ядро, так удобнее).
Ответ написан
Если вам нужен высокопроиводительный сокет-сервер — лучше не писать многопоточное приложение, а обрабатывать все операции с сокетами в одном потоке, как это делает например nginx.
Ответ написан
Комментировать
akzhan
@akzhan
смотрите в сторону libev, livevent, libux.

можете посмотреть исходные тексты Node.JS. Или просто писать на Node.JS, скорость удивит.
Ответ написан
ramilexe
@ramilexe
Попробуйте посмотреть исходники проекта raknet. Это опенсорсный движок для сетевых игр. Может поможет.
Ответ написан
@Masterkey
А вы точно сделаете все лучше команды, которая сделала erlang?
Советую на него посмотреть он как раз разрабатывался под ваши запросы + там много плюшек, которые вам пригодятся в ходе обновления и эксплуатации системы.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы