Насколько Дорогой??? - размещенная WCF Services?
У коллеги и меня есть дискуссия о сервисах WFC, когда тема "стоимости" подходит.
Вопрос - это:
Учитывая, что размещенный IIS сервис WCF и Размещенный службой Windows сервис WCF делают ту же самую вещь, какой сервис будет более "дорогим" относительно памяти и циклов ЦП, если они оба примут ту же загрузку?
Мы не обеспокоены начальным кодированием запуска, установкой или конфигурацией (которому IIS кажется приспособленным для обеспечения более простого опыта), просто базовая стоимость выполнения сервисов.
3 ответа
Я не могу предоставить конкретных цифр, хотя, если это вызывает серьезную озабоченность, вам обязательно нужно провести тестирование производительности, чтобы быть уверенным. Для типичной службы WCF на основе HTTP все запросы будут первоначально обрабатываться http.sys внутри Windows, а затем отправляться соответствующему процессу. Независимо от того, размещена ли ваша служба в IIS или автономно, не имеет почти такого значения, как используемые вами параметры конфигурации WCF в отношении конфигурации для каждого вызова, сеанса или одноэлементной конфигурации, а также ограничений размера запроса и регулирования запросов.
Я бы сосредоточился на удобстве использования и том, что имеет больше смысла, чем просто на показателях производительности, поскольку они должны быть почти одинаковыми.
Итог: используйте то, что удобнее, при необходимости проверьте производительность.
Я знаю, что это не полностью отвечает на ваш вопрос, но я хотел бы поделиться своим опытом.
У меня есть консольное приложение windows, которое по расписанию вызывает WCF сервисы, размещенные в IIS. В этой архитектуре IIS фактически совершенно не нужен и является просто дополнительным компонентом к общему решению. На самом деле он был включен в решение по маркетинговым причинам, чтобы приукрасить продукт, а не по техническим причинам.
Это основные проблемы, с которыми я столкнулся, и почему я бы избегал использования IIS, если бы мог, по техническим причинам, и это относится к моему опыту. Обратите внимание: я не говорю, что размещение служб WCF в IIS - плохая идея. Я просто излагаю свои мысли по продукту, над которым я работаю в настоящее время.
- Наличие IIS в цикле означает наличие еще одной системы в общем решении. Это, в свою очередь, добавляет сложности в развертывание. У одних клиентов стоит IIS6, у других - 7. Хотя эти различия могут показаться незначительными на первый взгляд. Не заблуждайтесь, они все равно разные, а это значит, что вы добавляете больше возможностей для различий в окружении, если вы развертываете свой продукт на разных клиентах. НЕ недооценивайте эти различия. У меня даже были клиенты, пытающиеся запустить мои WCF службы внутри коллекции сайтов SharePoint (да!), суть в том, что гораздо больше, чем вы думаете, может пойти не так.
- В IIS также есть рассмотрение AppPool, которое может потребоваться настроить в зависимости от сложности вашего продукта. Этому AppPool требуется идентификатор для работы, что еще больше усложняет общее решение.
- У меня были некоторые проблемы, когда однопоточная служба иногда получала "интересные" сообщения - сообщения о прерывании потока. Хотя я все еще пытаюсь выяснить точную причину, в глубине души я искренне надеюсь, что это не связано с IIS. Дело в том, что у меня не было бы этой проблемы, если бы я исключил IIS из общего решения.
- Я слышал обсуждения, что IIS - более надежная среда хостинга для служб WCF по сравнению с самостоятельным хостингом. Я не совсем уверен, что это имеет какой-либо вес. Если вы знаете, что вы делаете, то не должно быть причин для ненадежности вашей самостоятельно размещенной службы. Но я полагаю, что для реализации некоторых автоматических функций, которые вы получаете в IIS, например, рециркуляции WP, придется потрудиться.
- В целом я не недоволен IIS, но мне неприятно, когда я передаю продукт для развертывания, а консультанты без сильного технического образования должны настроить приложение IIS. Обычно что-то может пойти не так, и это требует вмешательства человека с большим техническим опытом для решения проблемы. При самостоятельном хостинге вы можете гораздо легче упаковать свое приложение для развертывания.
- Извините, что повторяюсь, но если вы выберете IIS, у вас будет 2 приложения в вашем решении, а не 1, хотя деловая сторона вашей организации будет рассматривать приложение только как одну бизнес-единицу, по сути, не понимая всей сложности реализуемого вами решения. Например: Почему у нас 2 файла конфигурации? Почему мы должны дважды настраивать почту? Почему мы должны развернуть библиотеки DLL в двух местах. Эти вопросы задают часто.
- Наконец, я решил упомянуть, что если вы работаете удаленно или через VPN для развертывания у клиентов, ситуация становится еще хуже, иногда консультант имеет доступ к конфиденциальным областям, к которым вы не имеете доступа. Как разработчик постарайтесь исключить как можно больше лишнего багажа из вашего общего решения. Следует также упомянуть, что системный администратор иногда может выдать удобный сброс IIS, если ваше приложение размещено вместе с другими, они сбросят ваши службы.
По моему опыту, меньше систем = меньше проблем. Но вам нужно решить, есть ли у вас навыки для реализации надежных саморазмещаемых сервисов. Все это, в свою очередь, напрямую связано со стоимостью разработки, развертывания и обслуживания.
Одно очень существенное соображение производительности между IIS или Windows service based hosting для WCF, является типом привязки. IIS поддерживает только привязки WCF, которые функционируют через HTTP, такие как wsHttpBinding. basicHttpBinding, etc.
Связки, не использующие HTTP, как правило, имеют лучшую производительность, например netTcpBinding (требует, чтобы служба и клиент были основаны на WCF, как я полагаю) или netNamedPipeBinding (самая быстрая, но служба/клиент должны находиться на одной машине). Конечно, у них есть свои ограничения, особенно в отношении гибкости.
Вот хороший обзор: http://weblogs.asp.net/spano/archive/2007/10/02/choosing-the-right-wcf-binding.aspx
Здесь было очень похожее обсуждение: WCF Binding Performance