Здравствуйте, <Аноним>, Вы писали:

А>Возможно для этого лучше использовать какие-то иные технологии, тоже было бы интересно.
В 3.5 и ниже пул реализуется посредством Monitor.Wait() + Monitor.Pulse()
В 4.0 есть BlockingCollection<T> с нужным функционалом.
Более подробно — есть отличная серия статей Албахари. Threading in C#
По Wait/Pulse в 4-й части Signaling with Wait and Pulse
По BlockingCollection в 5-й BlockingCollection&lt;T&gt; — там прям конкретно пример кода для реализации пула.

Здравствуйте, Suigintou, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Потоки из пула и есть довольно эффективное планирование. Самое главное в APM то что в большинстве случаев поток из пула будет браться только для исполнения callback функции при завершении операции. Это тысячная часть от общего времени асинхронных операций.
S>То есть использование APM-методов более эффективно, чем создание (или взятие из пула) потоков и вызова в них синхронных методов?
Конечно

Здравствуйте, Аноним, Вы писали:

G>>Надо использовать асинхронное программирование. На время ожидания на клиенте никаких ресурсов не будет использоваться.

А>Тоже верно, но все равно пул придется огранизовывать чтобы на сервер вдруг откуда не возьмись не посыпалось 1000 запросов. Это как лучше сделать — просто List<WebHttpRequest> или есть что-то более подходящее для таких целей.

У вас какой-то свой сервер или IIS стоит?

Здравствуйте, Аноним, Вы писали:



А>>>Тоже верно, но все равно пул придется огранизовывать чтобы на сервер вдруг откуда не возьмись не посыпалось 1000 запросов. Это как лучше сделать — просто List<WebHttpRequest> или есть что-то более подходящее для таких целей.

G>>Не переживай, внутренние механизмы ограничат число одновременных запросов на сервер.

А>А что за механизмы, как регулируются. Например нужно задать не более 5ти подключений одновременно.

http://msdn.microsoft.com/ru-ru/library/system.net.servicepointmanager.aspx

Тебя будут интересовать

http://msdn.microsoft.com/ru-ru/library/system.net.servicepointmanager.defaultconnectionlimit.aspx
http://msdn.microsoft.com/ru-ru/library/system.net.servicepointmanager.defaultpersistentconnectionlimit.aspx

Есть http запрос, выполняется он достаточно долго ~30 секунд. В основном тормозит серверная сторона, клиент ждет ответа.
На клиент сыпятся эти запросы, соотвественно есть смысл их распаралелить , но нужно и органичить их чтобы не создавалось сразу 1000 потоков. То есть создать некоторый пул потоков=запросов например не более 20 одновременно , как это лучше организовать в рамках .net framework 3.5, 4.0.
Возможно для этого лучше использовать какие-то иные технологии, тоже было бы интересно.

Здравствуйте, Аноним, Вы писали:

А>Есть http запрос, выполняется он достаточно долго ~30 секунд. В основном тормозит серверная сторона, клиент ждет ответа.
А>На клиент сыпятся эти запросы, соотвественно есть смысл их распаралелить , но нужно и органичить их чтобы не создавалось сразу 1000 потоков. То есть создать некоторый пул потоков=запросов например не более 20 одновременно , как это лучше организовать в рамках .net framework 3.5, 4.0.
А>Возможно для этого лучше использовать какие-то иные технологии, тоже было бы интересно.
Надо использовать асинхронное программирование. На время ожидания на клиенте никаких ресурсов не будет использоваться.

лучше организовать в рамках .net framework 3.5, 4.0.
А>>Возможно для этого лучше использовать какие-то иные технологии, тоже было бы интересно.
G>Надо использовать асинхронное программирование. На время ожидания на клиенте никаких ресурсов не будет использоваться.

Тоже верно, но все равно пул придется огранизовывать чтобы на сервер вдруг откуда не возьмись не посыпалось 1000 запросов. Это как лучше сделать — просто List<WebHttpRequest> или есть что-то более подходящее для таких целей.

Здравствуйте, Аноним, Вы писали:

А>лучше организовать в рамках .net framework 3.5, 4.0.
А>>>Возможно для этого лучше использовать какие-то иные технологии, тоже было бы интересно.
G>>Надо использовать асинхронное программирование. На время ожидания на клиенте никаких ресурсов не будет использоваться.

А>Тоже верно, но все равно пул придется огранизовывать чтобы на сервер вдруг откуда не возьмись не посыпалось 1000 запросов. Это как лучше сделать — просто List<WebHttpRequest> или есть что-то более подходящее для таких целей.

Не переживай, внутренние механизмы ограничат число одновременных запросов на сервер.

L>У вас какой-то свой сервер или IIS стоит?

Не сервер вообще не наш, некий веб сервер стороний на который перенаправляются запросы.

Здравствуйте, Аноним, Вы писали:

L>>У вас какой-то свой сервер или IIS стоит?

А>Не сервер вообще не наш, некий веб сервер стороний на который перенаправляются запросы.

Узнайте какой. Тот же IIS уже реализует то, что вы хотите, "ис каропки".

А>>Тоже верно, но все равно пул придется огранизовывать чтобы на сервер вдруг откуда не возьмись не посыпалось 1000 запросов. Это как лучше сделать — просто List<WebHttpRequest> или есть что-то более подходящее для таких целей.

G>Не переживай, внутренние механизмы ограничат число одновременных запросов на сервер.

А что за механизмы, как регулируются. Например нужно задать не более 5ти подключений одновременно.

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Аноним, Вы писали:

L>>>У вас какой-то свой сервер или IIS стоит?

А>>Не сервер вообще не наш, некий веб сервер стороний на который перенаправляются запросы.

L>Узнайте какой. Тот же IIS уже реализует то, что вы хотите, "ис каропки".

Интересно, допустим у них будет IIS, то как будет выглядеть схема взаимодествия ?
Просто очень сомневаюсь что они будут для нас что-то на нем настраивать или есть возможность поставить например IIS у себя и организовать через него пересылку запросов на тот сервер.

Здравствуйте, Аноним, Вы писали:

L>>Узнайте какой. Тот же IIS уже реализует то, что вы хотите, "ис каропки".

А>Интересно, допустим у них будет IIS, то как будет выглядеть схема взаимодествия ?

Я так навскидку не скажу а под рукой IIS-а нет. То ли в настройках IIS-а было, то ли в web.config-е. Точнее не помню.

G>>>Не переживай, внутренние механизмы ограничат число одновременных запросов на сервер.

А>>А что за механизмы, как регулируются. Например нужно задать не более 5ти подключений одновременно.

G>http://msdn.microsoft.com/ru-ru/library/system.net.servicepointmanager.aspx

G>Тебя будут интересовать

G>http://msdn.microsoft.com/ru-ru/library/system.net.servicepointmanager.defaultconnectionlimit.aspx
G>http://msdn.microsoft.com/ru-ru/library/system.net.servicepointmanager.defaultpersistentconnectionlimit.aspx

Спасиб ! То что нужно .

Здравствуйте, gandjustas, Вы писали:

G>Надо использовать асинхронное программирование. На время ожидания на клиенте никаких ресурсов не будет использоваться.
А если использовать APM методы (BeginXXX/EndXXX), будут ли создаваться (или браться из пула) потоки или же будет использовано какое-то более эффективное планирование?

Здравствуйте, Аноним, Вы писали:

А>Есть http запрос, выполняется он достаточно долго ~30 секунд. В основном тормозит серверная сторона, клиент ждет ответа.
А>На клиент сыпятся эти запросы, соотвественно есть смысл их распаралелить , но нужно и органичить их чтобы не создавалось сразу 1000 потоков. То есть создать некоторый пул потоков=запросов например не более 20 одновременно , как это лучше организовать в рамках .net framework 3.5, 4.0.
А>Возможно для этого лучше использовать какие-то иные технологии, тоже было бы интересно.

В 4 есть задачи в которых для шедулера можно указать что данная задача продолжительная.
Иногда стоит определить две очереди для быстрых запросов и продолжительных запросов, т.к. последние могут забить всю очередь.

Здравствуйте, Suigintou, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Надо использовать асинхронное программирование. На время ожидания на клиенте никаких ресурсов не будет использоваться.
S>А если использовать APM методы (BeginXXX/EndXXX), будут ли создаваться (или браться из пула) потоки или же будет использовано какое-то более эффективное планирование?

Потоки из пула и есть довольно эффективное планирование. Самое главное в APM то что в большинстве случаев поток из пула будет браться только для исполнения callback функции при завершении операции. Это тысячная часть от общего времени асинхронных операций.

Здравствуйте, gandjustas, Вы писали:

G>Потоки из пула и есть довольно эффективное планирование. Самое главное в APM то что в большинстве случаев поток из пула будет браться только для исполнения callback функции при завершении операции. Это тысячная часть от общего времени асинхронных операций.
То есть использование APM-методов более эффективно, чем создание (или взятие из пула) потоков и вызова в них синхронных методов?

Здравствуйте, Suigintou, Вы писали:

G>>Потоки из пула и есть довольно эффективное планирование. Самое главное в APM то что в большинстве случаев поток из пула будет браться только для исполнения callback функции при завершении операции. Это тысячная часть от общего времени асинхронных операций.
S>То есть использование APM-методов более эффективно, чем создание (или взятие из пула) потоков и вызова в них синхронных методов?

Использование APM-методов более эффективно, чем создание потоков и врял ли более эффективно, чем использование пула (т.к. они сами через пул и работают).

Здравствуйте, gandjustas, Вы писали:

S>>То есть использование APM-методов более эффективно, чем создание (или взятие из пула) потоков и вызова в них синхронных методов?
G>Конечно

Можно подробнее почему APM эффективнее, чем использование пула?

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, gandjustas, Вы писали:

S>>>То есть использование APM-методов более эффективно, чем создание (или взятие из пула) потоков и вызова в них синхронных методов?
G>>Конечно

L>Можно подробнее почему APM эффективнее, чем использование пула?

Еще раз: apm вызывает асинхронные операции ОС, которые вообще не требуют ресурсов приложения до завершения.

Здравствуйте, gandjustas, Вы писали:

L>>Можно подробнее почему APM эффективнее, чем использование пула?

G>Еще раз: apm вызывает асинхронные операции ОС, которые вообще не требуют ресурсов приложения до завершения.

Ступил. Почему-то думал, что APM — это про асинхронный вызов делегатов.