Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Сети";
Текущий архив: 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.034 c
14-1093088582
YurikGL
2004-08-21 15:43
2004.09.12
16 цветов


4-1091041350
Sulimxar
2004-07-28 23:02
2004.09.12
Окно между курсором и формой


4-1091031843
Slaga
2004-07-28 20:24
2004.09.12
Работа с WinAPI


14-1093149042
ААМ
2004-08-22 08:30
2004.09.12
А ?


3-1092649459
Alek
2004-08-16 13:44
2004.09.12
По поводу выборок





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский