Pregunta

Un compañero de trabajo y yo estamos teniendo una discusión acerca de los servicios WFC cuando el tema de "costo" aparece.

La pregunta es la siguiente:

Teniendo en cuenta que un servicio WCF alojado en IIS y un servicio WCF alojado en Windows-Servicio hacen exactamente lo mismo, que el servicio será más "cara" con respecto a los ciclos de CPU y memoria si ambos están aceptando la misma carga?

No estamos preocupados por la codificación inicial de puesta en marcha, la instalación o configuración (a la que IIS parece dirigido a proporcionar una experiencia más simple), sólo el costo escueto de funcionamiento de los servicios.

¿Fue útil?

Solución

No puedo dar cifras concretas, aunque si esto es de gran preocupación, que sin duda debe hacer pruebas de rendimiento para estar seguro. Para un servicio WCF basado en HTTP típica, todas las solicitudes serán manejados inicialmente por http.sys dentro de Windows, y luego enviados al proceso apropiado. Sea o no su servicio está alojado en IIS o independiente, no importará tanto como los ajustes de configuración de WCF específicos que utiliza, con respecto a la llamada por llamada, por sesión o configuración Singleton, y los límites de tamaño de la petición y la solicitud de estrangulación.

Me centrarse en la usabilidad y lo que tiene más sentido que estrictamente en los números de rendimiento, ya que deberían ser casi lo mismo.

En pocas palabras:. Uso de lo que sea más conveniente, prueba de rendimiento cuando sea necesario

Otros consejos

Una consideración actuación muy significativa entre IIS o servicio basado en Windows de alojamiento para WCF, es de tipo vinculante. IIS sólo es compatible con los enlaces de WCF que funcionan a través de HTTP, como wsHttpBinding. basicHttpBinding, etc.

No-Http enlaces son generalmente conocidos por tener un mejor rendimiento, tales como el netTcpBinding (requiere tanto el servicio y el cliente que se basa en WCF creo) o netNamedPipeBinding (el más rápido, pero el servicio / cliente debe estar en la misma máquina). Estos, por supuesto, tienen sus propias limitaciones, especialmente con flexibilidad.

Aquí hay una buena visión de conjunto: http://weblogs.asp.net/spano/archive/2007/10/02/choosing-the-right-wcf-binding.aspx

Ha habido un debate muy similar aquí: WCF Encuadernación Rendimiento

Sé que esto no responde a su pregunta por completo, pero me gustaría compartir mi experiencia.

Tengo una aplicación de consola ventanas que cuando programado está llamando a los servicios WCF alojados en IIS. En esta arquitectura del IIS es en realidad completamente innecesario y sólo un componente adicional a la solución global. Fue realmente incluido en la solución por razones de marketing, para reforzar el producto, y no por razones técnicas.

Estos son los principales problemas que estoy enfrentando, y por lo que habrían evitado el uso de IIS si pudiera, por razones técnicas, y esto se aplica a mi experiencia. Tenga en cuenta: No estoy diciendo que los servicios de alojamiento de WCF en IIS es una mala idea. Estoy dando mis pensamientos del producto que estoy trabajando en la actualidad.

  1. Tener IIS en el bucle significa tener otro sistema en la solución global. Esto a su vez aumenta la complejidad de la implementación. Algunos clientes tienen IIS6 otros corren 7. Si bien estas diferencias pueden parecer pequeñas en la superficie. No se equivoquen, siguen siendo diferentes, lo que significa que va a añadir más potencial para las diferencias de entorno si va a implementar su producto a diferentes clientes. No hay que subestimar estas diferencias. Ive siquiera tiene clientes tratando de correr mis servicios WCF dentro de una colección de sitios de SharePoint (la!) El punto es mucho más de lo que cree que puede salir mal.
  2. IIS también tiene una consideración AppPool, lo que podría necesitar ser configurado en función de la complejidad de su producto. AppPool que necesita una identidad para correr bajo, añadiendo más complejidad de nuevo para su solución global.
  3. he tenido algunos problemas en un único servicio de rosca a veces tiene "interesante" - Hilo de abortar mensajes. Aunque todavía estoy tratando de averiguar la causa exacta, en el fondo de mi mente Estoy sinceramente esperando que esto no es de alguna manera relacionada IIS. El punto es no tener esta consideración si he eliminado IIS desde la solución global.
  4. He escuchado discusiones que IIS es un entorno de alojamiento más robusto para los servicios WCF vs auto organizada. No estoy del todo seguro de esto es cualquier peso. Si sabes lo que estás haciendo no debería haber ninguna razón para su auto servicio alojado de ser poco fiables. Pero supongo que es más trabajo por adelantado para poner en práctica algunas de las características automáticas que recibe en IIS, por ejemplo, el reciclaje de WP.
  5. No estoy satisfecho en general con IIS en el circuito, pero es un dolor cuando entregue el producto para su despliegue, y los consultores sin una sólida formación técnica que tenga que configurar la aplicación de IIS. Por lo general, algo que puede y va a salir mal, e involucra a alguien con más experiencia técnica para intervenir y resolver. Si usted trabaja por cuenta de alojamiento puede empaquetar mucho más fácilmente su aplicación para la implementación.
  6. Lo sentimos reiterar pero si vas para IIS, podrás tener 2 aplicaciones en su solución en lugar de 1, a pesar de que la parte comercial de su organización sólo podrá ver la aplicación como una unidad de negocio, esencialmente sin comprender toda la complejidad de la solución que se va a implementar. Por ejemplo: ¿Por qué tenemos 2 archivos de configuración? ¿Por qué tenemos que configurar el correo dos veces? ¿Por qué tenemos que desplegar DLL a 2 lugares. Estas preguntas me preguntan mucho.
  7. Por último, pensé que me gustaría mencionar si está trabajando de forma remota a través de VPN o de desplegar a los clientes, la situación es aún peor, a veces el consultor tiene acceso a áreas sensibles que no lo hacen. Como desarrollador tratar de eliminar la mayor cantidad de exceso de equipaje como sea posible de su solución global. Permite también mencionar el administrador del sistema podría a veces realizar un reinicio de IIS conveniente, si su aplicación está alojado al lado de otros, van a restablecer sus servicios.

Menos sistemas en mi experiencia = menos pueden ir mal. Pero tiene que decidir si usted tiene las habilidades para implementar servicios confiables auto organizada. Todo esto a su vez se relaciona directamente con el coste de desarrollo, despliegue y mantenimiento.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top