Извините, ничего не найдено.

pax · 31.03.2011, 18:35

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

(1 поток - прием\отправка пакетов, 2 поток - обработка данных)

Однопоточный сервер плохо масштабируемый. Подумайте о использовании многопоточного или асинхронного сервера.

ffinder · 31.03.2011, 20:05

пахомыч, не соглашусь с твоим советом.
реально нужно 2-3 потока на ядро процессора, никак не больше.

moka · 31.03.2011, 20:08

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

пахомыч, не соглашусь с твоим советом.
реально нужно 2-3 потока на ядро процессора, никак не больше.

Чем это обосновано? Если например нужен проверяльщик timeout соединений? Его проще запустить отдельным потоком, не так ведь?
Плюс, ещё различные рутинные функции, лучше сделать потоком, если они нужны периодически, просто отправляется поток в сон, и выполняется рутина время от времени?
Я сам как бы не знаю, может это и имеет плохие стороны, но для меня очевидно удобно. Если есть тут "подводные камни", подскажите.

pax · 31.03.2011, 21:37

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

пахомыч, не соглашусь с твоим советом.
реально нужно 2-3 потока на ядро процессора, никак не больше.

И это говорит сторонник эрланга и гипермногопоточности?

Вот тут читал по реализации серверов: http://msdn.microsoft.com/ru-ru/library/dd335942.aspx
Вот что написано про однопоточную систему:

У этого подхода есть и другие недостатки, связанные с производительностью. После подключения примерно тысячи клиентов быстродействие метода Select значительно снижается. Это объясняется тем, что для определения того, доступны ли сокетам данные, ядро должно опросить каждый сокет.

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

Относится конечно к дотнету, но не думаю что есть большие отличия по работе с сокетами под windows

ffinder · 31.03.2011, 22:41

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

И это говорит сторонник эрланга и гипермногопоточности?

дело в том что VM эрланга:
1. создает 2 системных потока на ядро: один для ввода/вывода (сеть, диск), второй для логики
2. в эрланге процессы легковесные (легко запустить 100500 процессов, даже 300000 не проблема вовсе), в отличии от дотнета.

ffinder · 31.03.2011, 22:50

из статьи "про доднед и сокеты":

Как насчет масштабируемости?
Какую бы серверную модель я ни применял, на своем компьютере я не сумел создать более 4000 одновременных соединений или около того.
В этот момент в ответ на новые клиентские запросы начинали генерироваться довольно бесполезные сообщения об ошибках, извещавшие о нехватке места в буфере или о переполнении очередей.
Ясно, что этот предел неприемлем, если ваш сервер должен работать в какой-либо требовательной среде.
Почему же мы упираемся в этот потолок?
Оказывается, ограничивающим фактором является объем доступных ресурсов памяти, а именно, пул неподкачиваемой памяти (nonpaged pool).
Если процесс исчерпал свой пул этой памяти, создать новое соединение с сокетом не удастся.

как-то жалко смотрятся его потуги на фоне эрланка.
на эрланге поставлен рекорд с 1000000 (прописью: ОДИН МИЛЛИОН) одновременных TCP/IP соединений.

pax · 31.03.2011, 22:55

Да и компилятор эрланга заточен под это. Но что делать при использовании не Erlang в качестве ЯП для программирования сетей?
Вообще в статье не сказано про то, какая машина у него, сколько памяти и т.д.

ffinder · 31.03.2011, 23:00

просьба модераторам вынести часть обсуждения в отдельную тему, и я с удовольствием продолжу.
тут вообще-то тема обсуждения онлайн-игры Epica Online

Randomize · 31.03.2011, 23:35

Продолжаем

ffinder · 31.03.2011, 23:48

Существует так называемая "проблема 10000 соединений"
Подробно описана вот здесь: http://www.kegel.com/c10k.html
Вот хорошее "содержание" (взято отсюда)

Рассуждения на тему проблемы обслуживания соединений от 10000 клиентов на одной машине. Разбираются такие технологии как select(), poll(), /dev/poll, kqueue, thread, nonblocking I/O, Realtime Signals, /dev/epoll, asynchronous I/O, ограничение числа filehandler и тредов, использование Zero-Copy, sendfile() и writev. Многочисленные примеры приложений реализующих вышеописанные механизмы.

Кратко резюмирую:

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

Подход вида "1 клиент - 1 поток" тоже нежизнеспособны, так как 1 системный поток требует 1 мб оперативной памяти. Легко посчитать сколько RAM необходимо для 100 000 подключений.

Есть только несколько технологий, которые позволяют преодолеть этот барьер.
Это kqueue/epoll (linux/freebsd), io completion port (windows server).
Для их работы хватает одного потока.

pax · 31.03.2011, 23:55

2ffinder Ты кстати обещал статью по эрлангу написать

Я с удовольствием почитаю

UPD: ставлю Eclipce и erlide, буду иногда пробовать эрланг по мере возможности

HolyDel · 01.04.2011, 06:44

я бы тоже почитал что нить про эрланг от булочника

FDsagizi · 01.04.2011, 10:08

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

Есть только несколько технологий, которые позволяют преодолеть этот барьер.
Это kqueue/epoll (linux/freebsd), io completion port (windows server).
Для их работы хватает одного потока.

еще есть UDP.

Randomize · 01.04.2011, 12:05

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

еще есть UDP.

Udp - протокол. А мы говорим про технологии, которые этими самыми протоколами и управляют. Вернее работают через них, но хитро.

ffinder · 01.04.2011, 13:16

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

еще есть UDP.

Да, UDP классный протокол. Для шутеров - видимо единственный вариант.
Но, неупорядоченная доставка пакетов и нет контроля доставки с последующей перепосылкой.
Но там где нужна гарантированная доставка пакетов: чаты, магазины (внутриигровые) - нужно либо изобретать tcp поверх udp, либо...