Многопоточная служба Singleton WCF

Question

В своей книге «Программирование служб WCF» Джувал Лоури выражает обеспокоенность по поводу использования Singleton Services из-за влияния на производительность.

В одном из моих проектов я использую одноэлементную WCF-службу без состояния, объявленную так:

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single,
   ConcurrencyMode = ConcurrencyMode.Multiple)]
public class FooService : IFoo
{
}

Доступ к службе осуществляется с нескольких клиентов Silverlight через httpsTransport.Я выбрал синглтон, потому что не вижу необходимости загружать систему GC, когда она действительно не нужна.Я что-то упустил или это не самый эффективный способ реализовать сервис без сохранения состояния, который одинаково быстр, если не быстрее, чем инстанцированный сервис PerCall?

Answer 1

Ваше предположение, вероятно, справедливо для службы WCF, настроенной для basicHttpBinding без SSL (см. здесь для получения дополнительной информации ), но это вряд ли верно для других привязок.Хотя код вашего приложения действительно может быть без сохранения состояния и / или потокобезопасным, WCF использует сессий внутри для функциональной поддержки других привязок.Это подразумевает, что только один сеанс на запрос может быть обработан, поскольку существует только один экземпляр службы.

Похоже, что выбор одноэлементного шаблона - это случай преждевременной оптимизации.Оптимизация эффективности ГХ должна быть проблемой, только когда у вас есть доказанная потребность.

Answer 2

Ты ничего не пропустил.Если в вашем классе обслуживания нет переменных-членов экземпляра, которые представляли бы состояние, которое, очевидно, могло быть повреждено многопоточным доступом, нечего бояться.

Лично я всегда использую режим Single + Mulitple, потому что все мои состояниявсегда приходит из кеша или базы данных SQL или другого общего ресурса, где вам все равно нужны шаблоны для защиты от параллелизма.Я никогда не обнаруживал потребность в членских переменных в моих сервисах.Статика?Конечно, может быть, но тогда вы все равно знаете, как защитить их.

Теперь это все мое личное мнение о PerCall против Single. PerSession сервисы, с другой стороны, могли / скорее всего поддерживали бы состояние в этом экземпляре, но лично я не нахожу себя пишущим многие из них, и в редком случае это ConcurrencyMode..

Ознакомьтесь с этой статьей MSDN для более подробного обсуждения и сравнения фактической производительности diff.Режимы.

Answer 3

Одна из причин, по которой вам следует избегать синглетонов, заключается в том, что обычно у вас есть общий ресурс, который вы ДОЛЖНЫ сделать потокобезопасным.Как только вы это сделаете, у вас есть возможность складывать вызовы службы в последовательной очереди, так как в этом критическом разделе будет разрешен только один вызов одновременно.быть проблемой.Это, однако, облегчит для такого рода вещи позже.