2011-02-10 4 views
3

Чтобы оптимизировать некоторые вызовы базы данных на стороне сервера, я решил использовать System.Threading.Tasks.Task для параллелизации нескольких вызовов базы данных, а затем использовать Task.WaitAll(), чтобы получить все результаты, упаковать их и отправить их клиенту через WCF. Кажется, что это хорошо работает при тестировании на веб-сервере dev в Visual Studio (cassini), но не работает при развертывании в IIS. Профилирование вызовов клиента (с помощью firebug) показывает, что вызовы поступают в IIS, но соответствующие вызовы не отправляются на SQL Server.Использование задачи TPL из WCF

Кто-нибудь испытал это? Есть ли ограничение в использовании задач в IIS?

ответ

3

Не существует прямого ограничения - однако, когда вы используете задачу, она планирует задачу на ThreadPool. IIS по умолчанию использует один пул потоков для всего процесса IIS, который может (особенно на занятом сервере) вызвать голодание потока. Это означает, что при работе с задачами применяется то же руководство по использованию ThreadPool. См. this post for details.

Чтобы узнать, является ли эта проблема, вы можете, по крайней мере, в качестве теста, сгенерировать все экземпляры своей задачи с помощью подсказки TaskCreationOptions.LongRunning. Это приведет к тому, что TaskScheduler по умолчанию будет создавать задачу на своей собственной выделенной (новой) теме вместо использования ThreadPool. Хотя я не думаю, что это хорошая идея для долгосрочного решения, вы сможете проверить, что это головоломка пула потоков, вызывающая вашу проблему. Если это так, вы можете определить другие параметры, например, потенциально используя специальный TaskScheduler для управления потоками/задачами для этой операции.

+0

Thanks Reed - некоторая хорошая информация. Я довольно уверен, что это не голодный голод, но мне нужно сделать еще немного исследований. Я отправлю свои выводы, когда я продвигаюсь вперед. –

+1

@arch Какие-нибудь выводы? У меня похожие проблемы, и мне интересно, каков был результат этого? – Tyson

Смежные вопросы