Возникли проблемы в нагруженных WCF-сервисах — большое количество исключений по таймауту. После некоторых поисков выяснилось, что проблема в "длительных операциях", т.е. в сервисе есть несколько методов: некоторые выполняются относительно кратко, а некоторые долго. Долгие операции — это вызовы других WCF-сервисов и вызовы БД.

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

В ASP.NET есть асинхронные операции, которые возвращают рабочий поток (Worker Thread) в общий пул, пока асинхронные операции выполняются. Хотелось бы в WCF-сервисе использовать нечто подобное — чтобы длительные операции на все wait'ы освобождали пул рабочих потоков WCF.

Сразу оговорюсь, что я в курсе про OperationContractAttribute.AsyncPattern, однако он не решает проблемы нескольких wait'ов в сервисе + не хочется менять вид контракта с синхронного на асинхронный (и тем самым ещё и клиентов переписывать).

P.S. Понятно, что можно разделить долгие/короткие операции в разные сервисы и с помощью throttling регулировать загрузку (для котортких меньше, для долгих больше), но на мой взгляд это не очень "красиво".

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

М>P.S. Понятно, что можно разделить долгие/короткие операции в разные сервисы и с помощью throttling регулировать загрузку (для котортких меньше, для долгих больше), но на мой взгляд это не очень "красиво".

Это как раз самое правильное. Очередь в которой запросы разной длины — очень-очень плохая ситуация.

A>Это как раз самое правильное. Очередь в которой запросы разной длины — очень-очень плохая ситуация.
Это даёт клиенту как бы лишнее знание о том, что происходит внутри.

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

A>>Это как раз самое правильное. Очередь в которой запросы разной длины — очень-очень плохая ситуация.
М>Это даёт клиенту как бы лишнее знание о том, что происходит внутри.

Знаю

A>>>Это как раз самое правильное. Очередь в которой запросы разной длины — очень-очень плохая ситуация.
М>>Это даёт клиенту как бы лишнее знание о том, что происходит внутри.
A>Знаю

А всё-таки. Есть механизм внутренней асинхронности в WCF?

Здравствуйте, Митяй, Вы писали:
М>А всё-таки. Есть механизм внутренней асинхронности в WCF?

я давно делаю асинхронные вызовы в сервисе — опиши делегат, вызови BeginInvoke и в конце вызови EndInvoke

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

М>Возникли проблемы в нагруженных WCF-сервисах — большое количество исключений по таймауту.

А какие у Вас настройки пула? Что возвращают ThreadPool.GetMinThreads, GetMaxThreads, GetAvailableThreads в нормальном состоянии и при проблемной ситуации?

JR>А какие у Вас настройки пула? Что возвращают ThreadPool.GetMinThreads, GetMaxThreads, GetAvailableThreads в нормальном состоянии и при проблемной ситуации?

Думаю, что эта информация вряд ли поможет. Поскольку проблема идентифицирована: расширяем количество потоков — увеличивается конкуренция (слишком много переключений контекста и т.п.), уменьшаем — уменьшается утилизация ЦПУ (поскольку много потоков просто в wait'е).

Нужен именно способ сказать WCF, что пока не выполнится этот wait — можешь использовать этот поток для обработки входящего запроса.

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

М>Думаю, что эта информация вряд ли поможет. Поскольку проблема идентифицирована: расширяем количество потоков — увеличивается конкуренция (слишком много переключений контекста и т.п.), уменьшаем — уменьшается утилизация ЦПУ (поскольку много потоков просто в wait'е).

Это всё конечно правильно, но есть кое-какие нюансы. Пул базируется на Completion port, а этот механизм довольно хорошо оптимизирует использование процессаров своими потоками. Перегрузить планировщик скорее можно созданием своих потоков, неподконтрольных пулу. Я как-то проводил небольшие тесты, и мне не удалось заставить пул активировать потоков более, чем имеется процессоров, разумеется при условии, что потоки активны, не уходят в спячку.

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

Но Вам на месте, несомненно, лучше видно и проще оценить ситуацию