Масштабирование службы WCF, которая делает вызовы Http

Question

У меня есть служба WCF, размещенная в IIS, которая является адаптером для различных API-интерфейсов ThirdParty.Все, что делает эта служба: - принимает синхронный вызов операции из GUI - запускает синхронный Http-запрос третьей стороне - конвертирует результат в канонический формат - возвращает в GUI

На практике он тратит большую часть ожидания в сетиI / O для завершения.Каков наилучший шаблон для масштабирования такого сервиса при сохранении синхронного интерфейса для графического интерфейса?Я знаю, что для приложений ASP.NET, которые имеют много операций ввода / вывода, рекомендуется использовать асинхронные обработчики для освобождения потока, выполняющего запрос.

Есть ли хороший шаблон для WCF?

Спасибо, Петр

Answer 1

Я сталкивался с этим «AsyncPattern», который может быть решением этой проблемы (http://msdn.microsoft.com/en-us/library/system.servicemodel.operationcontractattribute.asyncpattern.aspx)

Я выгляжу как способ «освободить» поток службы, пока он ожидает на I /O будет завершено. В то же время он сохраняет синхронный характер операции с точки зрения вызывающей стороны (т.е. это строго детали реализации на стороне службы). Недостатком является сложность кода на стороне службы: все внешние вызовынеобходимо использовать API начала / конца.

Некоторые полезные ссылки: Для чего используется свойство "AsyncPattern" в "OperationContractAttribute" + wcf? WCF - Производительность AsyncPattern http://blogs.msdn.com/b/wenlong/archive/2009/02/09/scale-wcf-application-better-with-asynchronous-programming.aspx

Answer 2

Как вы уже описали, это потенциальная проблема масштабируемости.

ASP.NET имеет пул потоков, который (в прошлый раз, когда я проверял, был 250, но мог увеличиться до 1000 - настраивается, но более 1000 не рекомендуется), обслуживает запросы. HTTP-запросы в ASP.NET имеют thread-affinity , поэтому между этими потоками и запросами существует однозначное отношение.

Когда вы вызываете внешние службы, поток запросов продолжает зависать, а если у вас заканчиваются потоки, ваш клиент получит ошибку 503.

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

Вам также нужно подумать о:

• Сохранение результата, чтобы клиент мог его получить.
• Отбрасывание результата, если клиент не возвращается на сервер за результатом.