[krisadr]

Сообщение от n3k0nation

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

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

Из вики:

Свернуть ↑
Nginx опирается на управляемую событиями архитектуру (асинхронную архитектуру) , вместо потоков, чтобы обрабатывать запросы[1]
Lighttpd опирается на асинхронную архитектуру обработки запросов[2]
Cherokee HTTP Server, лёгкий веб-сервер[3]
Tornado, неблокирующий веб-сервер и веб-фреймворк[4]
Node.js, асинхронный, неблокирующий веб-сервер, основанный на JavaScript-движке V8[5]
Yaws использует концепцию легковесных процессов языка Erlang, даёт возможность использовать большое их количество с высокой конкурентностью.

Свернуть ↑Развернуть ↓

можно сказать что большинство решений опирается именно на асинхронную обработку соединений... я честно говоря не знаю реализации пула потоков во фреймверке от мс, но все таки думаю что там не дураки сидят, и сделали все максимально оптимально, насколько это возможно... изначально в пуле для приложения на нет выдается 1023 потока... добавить еще пару тысяч и думаю все попрет как по маслу xDDD разумеется все это будет тестироваться.

Добавлено через 2 минуты

Сообщение от n3k0nation

Призыв меня удался


В то время, когда это все писалось, еще не было NIO2.0 (async network), был выбор: писать на cpp для каждой платформы свою библиотеку (poll/epoll для линуксов и WSA для вин; про бздю вообще молчу), которую потом еще придется поддерживать, или же писать все на первом NIO.
До выхода J7 (в котором появился NIO2.0), особого смысла от нескольких RW Selector-воркеров не было, т.к. нативный поток полинга оставался одним. С вводом NIO2.0 JVM научилась их масштабировать (даже если не использовать async), поэтому, именно, после релиза J7, имело смысл что-то и как-то делать, но не раньше.


Конечно же, до выхода J7 существовал Netty, Grizzly и другие, но их использование... Хм... Об одном только Netty я могу много рассказать, особенно, про замечательный баг 100% CPU Use, который у них лежит на багтрекере уже лет десять, в состоянии Open.
В общем и грубо говоря: они предназначены для веб-серверов, но уж никак не для гейм лоад сети.

То было одно время, сейчас другое, почему бы не использовать новые доступные технологии)