У меня есть служба WCF, которая используется синхронно, но для ее ConcurrencyMode установлено значение ConcurrencyMode.Multiple, поскольку на самом деле служба не имеет состояния. Сколько накладных расходов накладывает этот режим? Есть ли смысл менять режим на ConcurrencyMode.Single?
WCF. Накладные расходы ConcurrencyMode.Multiple
Ответы (1)
На самом деле это не требует каких-либо накладных расходов, кроме того факта, что один экземпляр службы должен обрабатывать одновременный доступ, он должен быть на 200% потокобезопасным, а это довольно сложное программирование.
Переключение на ConcurrencyMode.Single упрощает программирование — больше не нужно беспокоиться о параллелизме в классе обслуживания. Но он сериализует все запросы - только один за раз может быть обработан, и поэтому быстро станет узким местом в производительности.
Вы упомянули, что ваша служба не имеет гражданства, так почему бы не использовать обычно согласованную передовую практику - не одноэлементный, а обычный класс обслуживания "за вызов". В этом режиме каждый запрос получает новый новый экземпляр вашего класса обслуживания, нет необходимости суеты по поводу необходимости многопоточного программирования (вся многопоточность обрабатывается средой выполнения WCF), вы получаете параллельную обработку нескольких запросов - для меня это только преимущества и минусов нет!
person
marc_s
schedule
30.06.2010
Спасибо за ответ. Что касается режима для каждого вызова, я планирую позже добавить в службу некоторые потокобезопасные зависимости. Поэтому я не думаю, что это лучший вариант для использования режима per call.
- person Andrei Sedoi; 30.06.2010
@bsnote: почему бы и нет?? Если служба действительно не имеет состояния, почему бы вам не использовать для этого самую простую возможную модель? Почему вы излишне усложняете и усложняете себе задачу?
- person marc_s; 30.06.2010
Проблема в том, что зависимости будут вводиться в службу каждый раз при ее создании. Вероятно, время создания невелико, но какие плюсы в режиме per call в этом случае, если нет необходимости заниматься вопросами параллелизма?
- person Andrei Sedoi; 01.07.2010
Программирование службы для каждого вызова будет намного проще, чем многопоточная одноэлементная служба; и если у вас есть синглтон с ConcurrencyMode-Single, вы очень сильно ограничиваете себя сериализованной обработкой - один запрос за другим - никакого параллелизма. Это серьезно ограничит способность службы обрабатывать звонки.
- person marc_s; 01.07.2010
