Я всегда думал, что установка InstanceContextMode в PerCall делает режим параллелизма нерелевантным, даже если используется привязка, учитывающая сеанс, как net.tcp. Это то, что говорит MSDN http://msdn.microsoft.com/en-us/library/ms731193.aspx & quot; В PerCallinstancing параллелизм не имеет значения, поскольку каждое сообщение обрабатывается новым InstanceContext и, следовательно, в InstanceContext никогда не активируется более одного потока. & quot;

Но сегодня я просматривал книгу Ювала Лоуи «Программирование служб WCF», и он пишет в главе 8

If the per-call service has a transport-level session, whether concurrent processing of calls is allowed is a product of the service concurrency mode. If the service is configured with ConcurrencyMode.Single, concurrent processing of the pending calls is not al lowed, and the calls are dispatched one at a time. [...] I consider this to be a flawed design. If the service is configured with ConcurrencyMode.Multiple, concurrent pro- cessing is allowed. Calls are dispatched as they arrive, each to a new instance, and execute concurrently. An interesting observation here is that in the interest of through- put, it is a good idea to configure a per-call service with ConcurrencyMode.Multiple— the instance itself will still be thread-safe (so you will not incur the synchronization liability), yet you will allow concurrent calls from the same client.

Это противоречит моему пониманию и тому, что говорит MSDN. Что правильно ? В моем случае у меня есть служба WCF Net.Tcp, которая использовала мои многочисленные клиентские приложения, которые создают новый объект прокси, совершают вызов, а затем немедленно закрывают прокси. Служба имеет PerCall InstanceContextMode. Получу ли я улучшенную пропускную способность, если я изменю InstanceContextMode на Multiple с безопасным поведением потока не хуже, чем percall?