Como são Caros ???-Hospedado Serviços WCF?

Question

Um colega e eu estamos tendo uma discussão sobre o WFC serviços, quando o tópico de "custo" vem à tona.

A questão é esta:

Dado que uma hospedado no IIS serviço WCF e um Serviço hospedado serviço WCF fazer exatamente a mesma coisa, que o serviço vai ser mais "caro" no que diz respeito à memória e ciclos de CPU se ambos estão aceitando a mesma carga?

Não estamos preocupados sobre o start-up inicial de codificação, de instalação ou de configuração (para que o IIS parece voltado para fornecer uma experiência mais simples), apenas o de nu-ossos custo de execução dos serviços.

Answer 1

Não posso fornecer números concretos, embora, se isso for uma grande preocupação, você definitivamente deve fazer testes de desempenho para ter certeza. Para um serviço WCF baseado em HTTP típico, todas as solicitações serão tratadas inicialmente pelo http.sys dentro do Windows e depois despachadas para o processo apropriado. Se o seu serviço está hospedado ou não no IIS ou no Standalone não importará tanto quanto as configurações específicas do WCF que você usa, com relação à configuração por chamada, por sessão ou singleton, e a solicitação de limites de tamanho e solicitação de redução.

Eu me concentraria na usabilidade e no que faz mais sentido do que estritamente nos números de desempenho, pois eles deveriam ser quase os mesmos.

Conclusão: use o que for mais conveniente, teste de desempenho quando necessário.

Answer 2

Uma consideração de desempenho muito significativa entre o IIS ou a hospedagem baseada em serviço do Windows para o WCF é o tipo de ligação. O IIS suporta apenas ligações de WCF que funcionam sobre HTTP, como wsHttpBinding. basicHttpBinding, etc.

Sabe-se que as ligações não-HTTP têm melhor desempenho, como o nettcpBinding (exige que o serviço e o cliente sejam baseados em WCF, acredito) ou NetNamedPipeBinding (mais rápido, mas serviço/cliente deve estar na mesma máquina). Obviamente, eles têm suas próprias limitações, especialmente com flexibilidade.

Aqui está uma boa visão geral: http://weblogs.asp.net/spano/archive/2007/10/02/choosing-the-tlight-wcf-binding.aspx

Houve uma discussão muito semelhante aqui: Desempenho de ligação a WCF

Answer 3

Eu sei que este não responder sua pergunta completamente, mas eu gostaria de compartilhar minha experiência.

Eu tenho um aplicativo de console do windows que, quando está agendada a chamar os serviços WCF hospedados no IIS.Nesta arquitetura do IIS, na verdade, é completamente desnecessário e apenas um componente adicional para a solução global.Foi realmente incluído na solução por motivos de mercado, para reforçar o produto, e não por razões técnicas.

Estes são os principais problemas que estou enfrentando, e por isso que eu teria evitado usando o IIS, se eu pudesse, por razões de ordem técnica, e isso se aplica a minha experiência.Por favor, note:Eu não estou dizendo hospedagem de serviços WCF no IIS é uma má idéia.Eu apenas estou dando os meus pensamentos do produto que eu estou trabalhando no momento.

1. Ter o IIS no loop significa ter o outro sistema na solução geral.Este por sua vez aumenta a complexidade de sua implantação.Alguns clientes têm IIS6 outros executado 7.Embora essas diferenças possam parecer pequenas na superfície.Não se enganem, eles ainda estão diferentes, significando que você está adicionando mais potencial para o ambiente de diferenças se você estiver implantando o produto para diferentes clientes.NÃO subestime essas diferenças.Eu mesmo tenho clientes de tentar executar a minha serviços WCF dentro de um conjunto de Sites do SharePoint (duh!) o ponto é MUITO mais do que você acha que pode dar errado.
2. O IIS também tem um AppPool consideração, o que pode precisar ser configurado, dependendo da complexidade de seu produto.Que AppPool precisa de uma identidade para ser executado em, acrescentando mais complexidade novamente para sua solução geral.
3. Eu tive alguns problemas, onde um único thread de serviço tem, por vezes, "interessante" - anulação de Thread de mensagens.Enquanto eu ainda estou tentando descobrir a causa exata, no fundo da minha mente eu estou sinceramente esperando que este não é, de alguma forma, relacionadas com o IIS.O ponto é que eu não teria essa consideração se eu eliminei o IIS a partir da solução geral.
4. Eu já ouvi discussões que o IIS é um mais robusto ambiente de hospedagem de serviços WCF vs auto-hospedado.Eu não sou inteiramente certo de que este detém qualquer peso.Se você souber o que você está fazendo não deve haver nenhuma razão para a sua auto-serviço hospedado ser confiável.Mas eu acho que é mais trabalho inicial para implementar algumas das funcionalidades automáticas você chegar no IIS, por exemplo WP reciclagem.
5. Eu não estou geral insatisfeito com o IIS no loop, mas a sua dor quando eu entregar o produto para a implantação e consultores sem uma forte formação técnica tem que configurar o aplicativo de IIS.Geralmente algo que pode e vai dar errado, e envolve alguém com mais experiência técnica para intervir e resolver.Se você é auto-hospedagem você pode muito mais facilmente do pacote de seu aplicativo para a implantação.
6. Desculpe reiterar mas se você ir para o IIS, você vai ter 2 aplicações na solução ao invés de 1, mesmo que o lado do negócio de sua organização só ver o aplicativo como uma unidade de negócios, essencialmente não entender toda a complexidade da solução que está sendo implementado.Por exemplo:Por que temos 2 arquivos de configuração?Por que temos que configurar o correio duas vezes?Por que temos que implantar DLLs para 2 locais.Estas perguntas ficam muito questionados.
7. Por último, eu pensei que eu iria mencionar, se você estiver trabalhando remotamente ou através de VPN para distribuir para clientes, a situação fica ainda pior, às vezes, o consultor tem acesso às áreas sensíveis, não.Como um desenvolvedor tente eliminar o máximo de bagagem possível, a partir de sua solução geral.Permite, também, mencionar, o administrador de sistemas pode, às vezes, um problema conveniente redefinir o IIS, se o seu aplicativo está hospedado ao lado de outros, eles vão repor os seus serviços.

Menos sistemas em minha experiência = menos pode dar errado.Mas você precisa decidir se você tem as habilidades necessárias para implementar a auto-confiança dos serviços hospedados.Esta tudo em volta se relaciona diretamente com o custo de desenvolvimento, implantação e manutenção.