Форум: "Сети";
Текущий архив: 2004.09.12;
Скачать: [xml.tar.bz2];
ВнизПотоки или порты завершения? Найти похожие ветки
← →
atruhin © (2004-07-03 13:46) [0]До какого кол-ва коннектов целесообразно обрабатывать каждого
клиента в отдельном потоке, и когда необходимо переходить на порты завершения.
Какие есть мнения ?
← →
Digitman © (2004-07-03 14:07) [1]
> atruhin
эти вещи не связаны непосредственно
использование/неиспользование доп.трэдов и использование/неиспользование портов завершения можно комбинировать любым образом
здесь гораздо более важна сложность/длительность обработки кл.запросов
при однопоточной логике сервера обработка запросов одного и того же или разных клиентов происходит последовательно, запрос за запросом, вне зависимости от использования/неиспользования портов завершения (равно как и иных допустимых механизмов нотификации о трансп.событиях - ивенты, оконные сообщения)
при мультипоточной логике события кл.транспорта для каждого из клиентов обрабатываются параллельно в отдельном трэде, при этом реакция сервера на очередной запрос клиента становится немедленной, вне зависимости от сложности исполняемых в этот момент запросов других активных клиентов
← →
atruhin © (2004-07-03 14:59) [2]>>события кл.транспорта для каждого из клиентов обрабатываются >>параллельно в отдельном трэде, при этом реакция сервера на >>очередной запрос клиента становится немедленной
Ведь чаще всего использование портов завершения как раз в том что ограниченное кол-во потоков по мере освобождения обрабатывают события ожидающие в порту.
--
Я может неточно сформулировал вопрос.
Есть N клиентов, коннект с клиентом длится 30-90 сек. В принцепе допускается некоторое ожидание клиентом обработки. Для кокого кол-ва можно создовать отдельный поток для каждого клиента, а когда желательно переходить на обработку ограниченным числом потоков например через порты завершения.
Я понимаю что поток ожидающий в.в. спит и не расходует процессорное время. Но он расходует память, дескрипторы и т.д.
Т.е. 100 потоков систему не перегрузят, а 10000?
← →
Digitman © (2004-07-03 15:13) [3]
> Т.е. 100 потоков систему не перегрузят, а 10000?
а 10000 ты и создать не сможешь на практике
каждый новый поток, несмотря на то что он может "спать", занимает немало и общесистемных ресурсов и ресурсов процесса-владельца
в кл-серв архитектуре, где от сервера требуется эффективный баланс производительности/времени отклика/ресурсоемкости обычно поступают так : создается пул потоков, при получении запроса данные, составляющие запрос, передаются транспортным потоком сервера на обработку первому найденному свободному потоку из состава пула, этот поток считается занятым; после отработки запроса исполняющий поток передает транспортному потоку результаты обработки и вновь помещается в пул как свободный, транспортный поток передает результат клиенту
← →
atruhin © (2004-07-03 15:31) [4]Дак это я и имею ввиду с самого начала, порты завершения я и упомянул как механизм огранизации пула. Я и спрашиваю до какого предела можно обходится без пула, а когда создать пул, и как определить сколько потоков обработки нужно для
>>эффективный баланс производительности/времени >>отклика/ресурсоемкости
← →
Polevi © (2004-07-03 22:17) [5]пул можно и на семафорах отлично организовать, без всяких copmletion ports
насчет до какого предела и сколько нужно потоков в пуле - это определяется в рантайме, я анализирую время простоя запроса клиента в очереди. если при очередном запросе в очереди лежит запрос со времением ожилания больше некой константы - добавляю поток в пул. если наоборот очередь пуста и колво потоков в пуле превышает некую константу - удаляю поток из пула
← →
atruhin © (2004-07-04 11:16) [6]>>Polevi
Спасибо за конкретный совет.
← →
atruhin © (2004-07-04 13:05) [7]К ответу Polevi.
Еще вопрос. Правильный ли алгоритм?
Делаем на семафоре пул потоков. Один поток обрабатывает SeverSocket и при коннекте клиента он делает Accept для сокета и
1)помещает полученный клиентский сокет TThreadList (в очередь ожидания)
2)вызывает ReleaseSemaphore
Один из ожидающих потоков
1) Извлекает из очереди клиентский сокет и удаляет его из TThreadList (здесь нужен атомарный доступ? как его лучше организовать?)
2) обрабатывает
3) ожидает семафор
← →
Polevi © (2004-07-04 19:18) [8]правильно, работу со списком защищай критической секцией
Страницы: 1 вся ветка
Форум: "Сети";
Текущий архив: 2004.09.12;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.036 c