fork() || threads?

Переключение между потоками быстрее. Так что лучше их использовыать.

без рута человек так просто не создаст 20к тредов или процессов.

есть большое подозрение на кривизну архитектуры приложения.

а на тему что лучше: треды быстрее а с fork-ами меньше проблем.

возможно автору имеет смысл пользовать их комбинацию

Если не секрет, почему возникло подозрение на кривизну приложения? На основании каких фактов (которых я привел вроде бы совсем немного) возможно сделать такие выводы ?

Возможно стоит использовать что-то в стиле prefork в Apache

"Кривизна" заключается в том, что для большого (а > 100 - это много) количества клиентов и усолвно простых сеансов связи можно обойтись одинм потоком и epoll. Или, например, N/50 потоками и poll/select.

-> man

прояодк бкув неажвен, лшиь бы пвреая и псолендяя сотяли на свиох метсах

> Количество потоков может варьироваться от 5к до 20-30к.

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

Но я бы сделал так, как посоветовал erDiZz (02.09.2005 20:16:57)

Ок, спасибо за совет.

Вдогонку насчет "кривизны"

Если возникает желание на одном (ок, двух, ... 32) процессоре распараллелиться на 10k потоков, это говорит о некоторой кривизне реализации. Именно потакание подобным прихотям привело к интенсивной эксплуатации "MxN" моделей, что IMHO есть зло.

Если _действительно_ сервер способен параллельно обрабатывать запросы 10k клиентов, то это значит, что клиенты не грузят процессор, а просто ждут некоторых событий. Тогда логичнее форкаться не на коннект с клиентом, а на события (или даже сразу создавать пул по числу возможных событий), а клиентов просто ставить в очереди.

Вы совершенно правы, это не числодробильная программа и процессор потоки не грузят никак. Но я не совсем понял фразу "Тогда логичнее форкаться не на коннект с клиентом, а на события (или даже сразу создавать пул по числу возможных событий), а клиентов просто ставить в очереди" ? У каждого процесса СВОИ данные, каждый делает свое дело (есснно одноипное, такое же как все, но данные разные). Или я неправильно понял вашу мысль ?

Если я правильно его понял, то он говорит, что незачем обрабатывать по 10k клиентов одновременно, достаточно обрабатывать по 100 -- по очереди!

Ok, спасибо, но все же надо именно одновременно, потому что вычислений на процессоре почти нету. Тогда буду делать потоки

> потому что вычислений на процессоре почти нету.

Вот именно потому что вычислений нету можно успеть и поочереди обработать!

Да, я кажется понял что вы имеете ввиду :) Как то сам не додумался, но это намного усложняет реализацию. Спасибо за идею, буду думать :)

Прошу прощения, некоторая запарка, сюда лишь урывками заглядываю.

unDEFER (03.09.2005 11:02:13):

> ...незачем обрабатывать по 10k клиентов одновременно, достаточно обрабатывать по 100 -- по очереди!

Немного не то я имел в виду. Не искусственное разбиение на чанки по 100 (кстати, по 100 -- слишком много), а разбиение по группам, ждущим одинаковое "событие".

Я бы сделал так:

Пусть процессы-обработчики клиентов начинают активно шуршать при наступлении, скажем, одного из 10 возможных "событий".

Тогда я должен вместо "обработчика клиентского запроса" запускать "Обработчик собития", и ставить клиентские запросы в очередь к обработчикам соответствующих событий.

Это касательно логики. На практике обычно делается более извращенно.

Ключевой момент тут таков: если стартовать обновременно 5k нитей, половина из которых могут вдруг одновременно пробудиться, то система будет работать нестабильно, поскольку при одновременном пробуждении большого числа нитей все CPU сожрет шедулер, даже если по памяти не вылетишь.

Из фразы anonymous (*) (03.09.2005 14:20:34):

> все же надо именно одновременно, потому что вычислений на процессоре почти нету.

можно заключить, что все гораздо проще. Скорее всего, надо просто иметь 2 процесса, один коннектится с клиентом и ставит его в FIFO, а второй эту очередь последовательно обрабатывает. С точки зрения клиентских запросов подобная конструкция будет вести себя "одновременнее", чем параллельная обработка в независимых тредах.