Pull to refresh

Comments 16

Давно искал статью по этой теме. Спасибо.
1) Судя по описанию, вы придумали Long Polling. Это решение крайне плохо масштабируется.

2) Неоптимальная синхронизация. lock не нужен для чтения примитивных типов, а для записи вместо него достаточен вызов Thread.MemoryBarrier()
1) Судя по описанию, вы придумали Long Polling. Это решение крайне плохо масштабируется.

ты серьезно бротюнь? Или ты про принципиалную неспособность дотнета решать C10K?
Я серьёзно. Вот тут например
tomasz.janczuk.org/2009/08/performance-of-http-polling-duplex.html
результаты замеров. Банально Worker Threads заканчиваются.

Что касается неуместного выпада в сторону .Net… Ты серьёзно бротюнь?
С10К задача решаемая веб-сервером, в данном случае IIS (Hostable WebCore, http.sys), а не языком программирования или платчормой. Apache (написанный на Си) или TomCat не справляются с ней точно так же как и IIS, как, впрочем, и любой другой сервер приложений. Язык тут не при чём.
всю жизнь думал что асинхрнное io на стороне приложения, делает long polling и вообще C10K не проблемой для 98% веб приложений.
ну при чем тут .net?!

возьмем ту же Java. Так вот, например, чтобы BlazeDS или LCDS держали long polling более 10K клиентов необходимо использовать Java NIO, а лучше NIO2.
так вот в .net, начиная с версии 1.0 асинхронный IO поддерживается из коробки.

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

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

однако, учитывая и это, главная проблема все-таки кроется в использовании threaded-server'ов. т.к. цитата
>>Банально Worker Threads заканчиваются

чтобы не разводить холивар на тему threaded vs evented сервера и т.д., скажу, что оба подхода достойны и должны использоваться каждый для своих целей.
Асинхронный I/O .Net тут не при чём, WCF для HTTP использует компонент операционной системы — HTTP.sys
>>Асинхронный I/O .Net тут не при чём
вы действительно считаете, что async не при чем? тогда как же происходит long polling в WCF, если он хостится вне IIS, например?

и

>>WCF для HTTP использует компонент операционной системы — HTTP.sys
понятное дело, однако все-таки WCF работает через стандартные механизмы самого I/O .NET'a, но никак не напрямую с драйвером системы.
Именно для HTTP работа идёт со специализированным драйвером. Используется класс-обёртка HttpListener
msdn.microsoft.com/en-us/library/system.net.httplistener.aspx

Нарошной ститьи я сейчас с ходу не нашёл, но по ссылкам ниже упоминается использование HTTP.sys и вызванные этим особенности.
msdn.microsoft.com/en-us/library/ms733768.aspx
msdn.microsoft.com/en-us/magazine/cc163570.aspx
именно HttpListener имел ввиду. скажу больше — благодаря ему (http.sys) IIS может шарить порты с WCF
Ну так асинхронный I/O .Net — это обёртка над IOCP, Socket.BeginSend/Socket.BeginReceive.

HttpListener это вообще не API ввода-вывода, вы там с HttpListenerContext работаете и уже распарсенным HttpListenerRequest. Никакого Read/Receive или Write/Send там нет. HttpListener — это расширяемая платформа веб-сервера.
>>Ну так асинхронный I/O .Net — это обёртка над IOCP, Socket.BeginSend/Socket.BeginReceive.
кто спорит?
>>HttpListener — это расширяемая платформа веб-сервера.
его использует и Cassini, да сами делали на нем сервер.
>>Никакого Read/Receive или Write/Send там нет.
вы же начинаете асинхронно принимать и отпускать запросы. а если асинхронно записываете в response? что представляет собой response? system.io.stream. а этот класс разве не имеет async. вообще на счет и async и java я начал, чтобы показать, что никакого отставания .net как такого нет по сравнению с др. платформами.
WCF для работы с HTTP всегда исспользует модуль HTTP.sys.
Попытайтесь запустить свой сервис без привилегий админа, сразу получите исключение, которое лечится конфигурированием urlacl именно для модуля HTTP.sys.
я не говорю, что HTTP.sys не используется — просто под стандартными механизмами имелся ввиду тот же самый HttpListener, который и есть wrapper вокруг драйвера.
хотелось показать, что WCF полностью написан с использованием managed кода.
Sign up to leave a comment.

Articles