В образовательных целях задумал разработать IM-сервер, если быть точнее XMPP-сервер.
Так вот. На этапе проектирования возник такой вопрос: какой метод, в данном случае, более пригоден для реализации параллельной работы?
Сейчас я рассматриваю несколько вариантов, но возможно вы предложите лучше.
1. Не постоянное число процессов/потоков. Один мастер-процесс обрабатывает запросы на соединение и для каждого создает новый поток/процесс. С каждым клиентом ассоциирован один процесс который и обрабатывает поступающие от него запросы.
2. Постоянное число потоков/процессов. Один мастер-процесс создает число потоков равное числу процессоров (или ядер) в системе или близкое к нему. Каждый из таких потоков/процессов обрабатывает несколько соединений с клиентами.
Я более склоняюсь к первому (его, как минимум, проще реализовать) но хотелось бы узнать и ваше мнение.
Заранее спасибо за ответ.
P.S. В качестве языка программирования использую Си (С99), ОС: Unix-like, в частности GNU/Linux.
Здравствуйте, The Phantom Daemon, Вы писали:
TPD>1. Не постоянное число процессов/потоков. Один мастер-процесс обрабатывает запросы на соединение и для каждого создает новый поток/процесс. С каждым клиентом ассоциирован один процесс который и обрабатывает поступающие от него запросы.
TPD>2. Постоянное число потоков/процессов. Один мастер-процесс создает число потоков равное числу процессоров (или ядер) в системе или близкое к нему. Каждый из таких потоков/процессов обрабатывает несколько соединений с клиентами.
Второй способ способен обеспечить большую производительность, чем первый, т.к. создание процесса/потока — достаточно затратная операция, и чем их больше, тем больше накладные расходы на переключение между ними. От себя могу порекомендовать сначала сделать по первому варианту, а потом, когда всё будет работать — заменить на второй (при этом, естественно, сразу учитывать возможность замены, т.е. абстрагировать способ работы с многопоточностью от остального кода).
Я бы сделал однопотоный сервер. В данном случае не вижу причины для многопоточности, если честно. Какая обработка данных предполагается? Просто гонять данные из соединения в соединение, и/или сохранять в базе для последующей отправки?
Здравствуйте, Marty, Вы писали:
M>Я бы сделал однопотоный сервер. В данном случае не вижу причины для многопоточности, если честно. Какая обработка данных предполагается? Просто гонять данные из соединения в соединение, и/или сохранять в базе для последующей отправки?
Поскольку сервер делается в образовательных целях, то вполне возможно, что одна из них — научиться писать многопоточный код.
Здравствуйте, Marty, Вы писали:
M>Я бы сделал однопотоный сервер. В данном случае не вижу причины для многопоточности, если честно. Какая обработка данных предполагается? Просто гонять данные из соединения в соединение, и/или сохранять в базе для последующей отправки?
Вообще, для взаимодействия между потоками, в случае многопоточности, планировал использовать общий пул для "сообщений". Т.е. да, сохранять в "базе", но временно.
Здравствуйте, 24, Вы писали:
24>Второй способ способен обеспечить большую производительность, чем первый, т.к. создание процесса/потока — достаточно затратная операция, и чем их больше, тем больше накладные расходы на переключение между ними. От себя могу порекомендовать сначала сделать по первому варианту, а потом, когда всё будет работать — заменить на второй (при этом, естественно, сразу учитывать возможность замены, т.е. абстрагировать способ работы с многопоточностью от остального кода).
IMHO. Но в случае с таким типом серверов, я думаю, затраты не создание новых потоков и переключение между ними не настолько велики как, например в случае http сервера. Так как в отличии от него, соединение с клиентов в IM-сетях имеет большую продолжительность жизни.
Скорее всего последую вашему совету и буду ориентироваться на второй, сначала реализовав первый.
Здравствуйте, 24, Вы писали:
24>Поскольку сервер делается в образовательных целях, то вполне возможно, что одна из них — научиться писать многопоточный код.
Понятно. Тогда можно и многопоточный. Но в образовательных целях можно бы написать и однопоточную версию — просто для того, чтобы уметь использовать один поток там, где кажется, что надо несколько.
Здравствуйте, The Phantom Daemon, Вы писали:
TPD>IMHO. Но в случае с таким типом серверов, я думаю, затраты не создание новых потоков и переключение между ними не настолько велики как, например в случае http сервера. Так как в отличии от него, соединение с клиентов в IM-сетях имеет большую продолжительность жизни.
Хттп серверу совсем не обязательно создавать отдельный поток для каждого соединения. Что касается данного ИМ-сервера — при разработке и тестовом использовании разница в производительности не будет заметна вообще, т.к. слишком мало соединений для этого (пока кол-во соединений не будет измеряться тысячами или десятками тысяч можно вполне обойтись и без многопоточности). Т.е. если цель — написать ИМ-сервер, то можно с многопоточностью и не заморачиваться, а если научиться писать многопоточный код — то без второго варианта в итоге не обойтись, т.к. он позволяет добиться большей производительности, если она нужна.
Здравствуйте, The Phantom Daemon, Вы писали:
TPD>IMHO. Но в случае с таким типом серверов, я думаю, затраты не создание новых потоков и переключение между ними не настолько велики как, например в случае http сервера. Так как в отличии от него, соединение с клиентов в IM-сетях имеет большую продолжительность жизни.
Современные HTTP сервера не стараются не использовать модель соединение-поток. Во-первых, HTTP соединение имеет режим keep-alive, к-ый активно используется браузерами. Во-вторых, есть куча Comet/Server-push/AJAX веб-сайтов, к-ые держат соединение с сервером постоянно с целью немедленного получения обновлений. 30 000 активных соединений не совсем уж редкая ситуация, точнее раньше такое встречалось на сильно нагруженных сайтах, сейчас достаточно часто.
Относительно затрат тоже стоит подумать. Вы думаете, что основные завтраты это процессор в момент запуска потока. Это не совсем так. Каждый поток должен обслуживать планировщик, каждый поток должен иметь свой стек. Стоимость неактивного потока далеко не 0.
Насколько я помню, на 1024 потоках 1 ядерный сервер уже работает в критическом режиме: ощутимое время проводит в планировщике и перебросе контекстов. Опять же вам нужно для каждого потока выделить стек, выделить управляющие структуры. А ловить баги в таких монстрах вообще песня.
Коммутация сообщений по количеству соединений гораздо хуже http -> гораздо требовательнее в плане правильности написания многопоточного кода. Если писать по настоящему. На самом деле только коммутация медиапотоков сложнее — там еще самописный сшедулинг добавляется.
Здравствуйте, Marty, Вы писали:
M>Я бы сделал однопотоный сервер. В данном случае не вижу причины для многопоточности, если честно. Какая обработка данных предполагается? Просто гонять данные из соединения в соединение, и/или сохранять в базе для последующей отправки?
XMPP не такой уж тривиальный протокол, если делать понастоящему. Парсинг XML только будет стоить. А еще аутентификация, авторизация, ростер, чат-румы и т.д.
Здравствуйте, The Phantom Daemon, Вы писали:
TPD>Так вот. На этапе проектирования возник такой вопрос: какой метод, в данном случае, более пригоден для реализации параллельной работы?
Основное, что следует знать про параллельную работу — это то, что она стоит ресурсов.
Каждый поток в винде, к примеру, отжирает по дефолту 1 мегабайт адресного пространства под стек. Таким образом, 2000 потоков — и всё, в 32х разрядах память кончилась.
Процесс, висящий в памяти — тоже не радость.
Тем более, что потребности в этих потоках/процессах, в общем-то, нет. Большую часть времени соединение простаивает.
Поэтому все современные коммуникационные сервера пишутся на основе IOCP. То есть имеется пул потоков фиксированного размера (подобранного исходя из используемоей железки), который обслуживает неограниченное количество соединений. Пришли данные — вытащили поток из пула, отдали ему данные, он их обработал — и снова в пул.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
