[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single,
ConcurrencyMode =ConcurrencyMode.Multiple)]
Указывает количество экземпляров службы, доступных для обработки вызовов, содержащихся во входящих сообщениях: InstanceContextMode.Single - только один объект InstanceContext используется для всех входящих вызовов и не перерабатывается после вызовов.Если объект службы не существует, он создается.
Указывает, поддерживает ли класс службы однопоточные или многопоточные режимы работы: ConcurrencyMode.Multiple - экземпляр службы является многопоточным.Никаких гарантий синхронизации не сделано.Поскольку другие потоки могут изменить ваш сервисный объект в любое время, вы должны постоянно обрабатывать синхронизацию и согласованность состояний.Вы несете ответственность за охрану своего государства с помощью замков.Реализация сервиса должна быть поточно-ориентированной, чтобы использовать этот режим параллелизма.
Вы можете попробовать добавить UseSynchronizationContext = false
к вашему ServiceBehavior
.Если это не поможет, попробуйте добавить ReleaseServiceInstanceOnTransactionComplete=true
или false
к вашему ServiceBehavior
.Я не уверен, что вы можете установить значение true, если InstanceContextMode является кратным.
Поскольку с ConcurrencyMode.Multiple Нет гарантий синхронизации, и значение по умолчанию для UseSynchronizationContext равно true, возможно, он пытается обработать все вызовы натот же поток, вызывающий очередь.
Также может быть некоторая проблема с кодом, который вы используете для вызова службы.Не видя этого, мы бы не узнали.
Может потребоваться немного времени, чтобы раскрутить поток для каждого вызова ??На вашей картинке самый длинный запрос - всего 5,5 секунд.(Я знаю, это просто для простого звонка.)
Это также может быть загадочным: https://stackoverflow.com/a/4698956/2016162