У меня есть служба WCF, размещенная в IIS, которая по запросу выполняет запрос на другой сервер с использованием асинхронных запросов сокетов. Запрос должен быть быстрым (5 секунд), иначе время ожидания истечет. Когда много пользователей отправляют запросы одновременно (я думаю, около 10), то происходит то, что запросы сокетов к другому серверу не обрабатываются в течение этих 5 секунд. Журналы на другом сервере говорят, что запрос получен и обработан почти сразу, а ответ отправлен обратно, но асинхронное событие не запускается до 5-10 секунд, что приводит к тайм-ауту службы wcf (обратите внимание, что это не тайм-аут из сам wcf, но внутренний тайм-аут при вызове на другой сервер). Мы думаем, что этот пул либо слишком медленный, чтобы порождать новые потоки, либо имеет какие-то причины этого не делать, что приводит к ситуации, когда нет ни одного потока, доступного для получения асинхронного получения сокета. Насколько я понимаю, обработчики сокетов WCF и async используют для этого ThreadPool, поэтому они действительно борются за один и тот же ресурс. Кто-то сталкивался с подобной ситуацией? Каков наилучший способ справиться с этим?
Я вижу два простых выхода:
1) Ограничьте количество максимальных одновременных запросов в службе wcf до 5 или что-то еще, что может замедлить ее работу, поскольку некоторым запросам придется ждать в очереди.
2) Увеличить количество MinSize в ThreadPool Буду рад любым предложениям по этому поводу.
P.S. Процессор имеет 8 ядер, что означает, что минимальный размер пула потоков по умолчанию равен 8, поэтому я начинаю видеть проблему, когда происходит более 8 одновременных запросов.
Task<T>, и использовать async/await в своем сервисном методе. Если вам нужна масштабируемость, это единственный путь. blogs.msdn.com/b/endpoint/archive/2010/11/13/ - person spender schedule 06.12.2013