В вашем сценарии по умолчанию узел службы WCF (объект, на котором размещается ваш класс обслуживания) будет создавать новый экземпляр класса обслуживания для каждого входящего запроса и позволять ему обрабатывать запрос (активация «по вызову») .
Вы можете настроить максимальное количество одновременно работающих экземпляров класса обслуживания, используя поведение serviceThrottling
на вашем сервере.
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="ThrottledServiceBehavior">
<serviceThrottling
maxConcurrentCalls="25"
maxConcurrentSessions="25"
maxConcurrentInstances="25"/>
</behavior>
</serviceBehaviors>
</behaviors>
В блоге Кенни Вольфа здесь .
есть действительно хорошее объяснение опций поведения регулирования сервиса и его значений по умолчанию.
Кроме того, установка InstanceContextMode
и ConcurrencyMode
в вашем классе обслуживания (который реализует контракт на обслуживание) сильно влияет на то, как ваша служба будет обрабатывать параллелизм и множественные запросы.
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall,
ConcurrencyMode=ConcurrencyMode.Single)]
class YourServiceClass : IYourService
{
.....
}
InstanceContextMode
должно быть PerCall
(каждый вызывающий запрос получает новый отдельный экземпляр), а затем ConcurrencyMode
может быть Single
(который проще всего разрабатывать).
InstanceContextMode
также может быть PerSession
, если вам нужен подход, основанный на сеансах (не очень распространенный), или Single
(ваш класс обслуживания будет одноэлементным - настоятельно не рекомендуется использовать это, если вы абсолютно, положительно и знать обо всех причудах и проблемах с ним!).
ConcurrencyMode
также может быть Reentrant
(актуально только для дуплексных контрактов и привязок) или Multiple
(многопоточный одноэлементный класс обслуживания - очень рискованный и сложный в разработке!).
Марк