Eu sempre pensei que definir InstanceContextMode para PerCall torna o modo de simultaneidade irrelevante, mesmo se estiver usando uma ligação consciente da sessão como net.tcp. Isto é o que o MSDN dizhttp://msdn.microsoft.com/pt-br/library/ms731193.aspx "No PerCallinstancing, a simultaneidade não é relevante, porque cada mensagem é processada por um novo InstanceContext e, portanto, nunca mais de um thread está ativo no InstanceContext."

Mas hoje eu estava passando pelo livro Programming WCF Services de Juval Lowy e ele escreve no Capítulo 8

Se o serviço por chamada tiver uma sessão de nível de transporte, se o processamento simultâneo de chamadas for permitido, isso é um produto do modo de simultaneidade de serviço. Se o serviço estiver configurado com ConcurrencyMode.Single, o processamento simultâneo das chamadas pendentes não será permitido e as chamadas serão despachadas uma de cada vez. [...] eu considero isso um design defeituoso. Se o serviço for configurado com ConcurrencyMode.Multiple, o processamento simultâneo será permitido. As chamadas são enviadas conforme chegam, cada uma para uma nova instância, e são executadas simultaneamente. Uma observação interessante aqui é que, no interesse do throughput, é uma boa idéia configurar um serviço por chamada com ConcurrencyMode.Multiple - a instância em si ainda será thread-safe (portanto, você não incorrerá no passivo de sincronização) , mas você permitirá chamadas simultâneas do mesmo cliente.

Isso está contradizendo minha compreensão e o que o MSDN diz. Qual é correto ? No meu caso, eu tenho um serviço WCF Net.Tcp usado meus muitos aplicativos cliente que cria um novo objeto proxy, faz a chamada e, em seguida, fecha imediatamente o proxy. O serviço tem PerCall InstanceContextMode. Terei uma taxa de transferência aprimorada se eu alterar o InstanceContextMode para Multiple sem pior comportamento de segurança de thread do que percall?