Procedimientos recomendados de hospedaje de Internet Information Services

En este tema se describen algunos procedimientos recomendados para hospedar los servicios de Windows Communication Foundation (WCF).

Implementación de servicios WCF como DLL

Implementar un servicio de WCF como una DLL que se implementa en el directorio \bin de una aplicación web permite reutilizar el servicio fuera del modelo de aplicación web, por ejemplo, en un entorno de pruebas que no puede tener implantad Internet Information Services (IIS).

Hosts de servicio de aplicaciones hospedadas en IIS

No utilice las API de autohospedaje imperativo para crear nuevos hosts de servicio que realicen escuchas en transportes de red no admitidos nativamente por el entorno de hospedaje de IIS (por ejemplo, IIS 6.0 para hospedar servicios TCP, porque la comunicación TCP no se admite de manera nativa en IIS 6.0). Éste enfoque no se recomienda. Los hosts de servicio creados de manera imperativa no se conocen dentro del entorno de hospedaje de IIS. El punto crítico es que el procesamiento realizado por servicios creados imperativamente no se tiene en cuenta por parte de IIS cuando determina si el grupo de aplicaciones de hospedaje está inactivo. El resultado es que las aplicaciones que tienen hosts de servicio creados de esta manera imperativa tienen un entorno de hospedaje de IIS que elimina de manera agresiva los procesos de host de IIS.

URI y extremos hospedados en IIS

Los extremos para un servicio hospedado en IIS se deberían configurar utilizando Identificadores uniformes de recursos relativos (URI), no direcciones absolutas. Esto garantiza que la dirección de extremo cae dentro del conjunto de direcciones URI que pertenecen a la aplicación de hospedaje y asegura que la activación basada en mensaje ocurre tal y como se esperaba.

Administración de estado y reciclaje de procesos

El entorno de hospedaje de IIS se optimiza para servicios que no mantienen el estado local en memoria. IIS recicla el proceso del host en respuesta a diversos eventos externos e internos, produciendo que se pierda cualquier estado volátil almacenado exclusivamente en memoria. Los servicios hospedados en IIS deberían almacenar su estado externo al proceso (por ejemplo, en una base de datos) o en una caché en memoria que se puede recrear con facilidad si tiene lugar un evento de reciclaje de aplicación.

Nota:

Los protocolos que WCF utiliza para la confiabilidad del nivel de mensaje y seguridad utilizan el estado en memoria volátil. Las sesiones confiables y de seguridad de WCF pueden finalizarse de manera inesperada debido a reciclajes de las aplicaciones. Las aplicaciones hospedadas en IIS que hacen uso de estos protocolos no deberían depender de la clave de sesión proporcionada por WCF para correlacionar el estado de nivel de aplicación (por ejemplo, una construcción del nivel de aplicación o un encabezado de correlación personalizado) o deshabilitar el reciclaje de procesos de IIS para la aplicación hospedada.

Optimización del rendimiento en escenarios de nivel medio

Para un rendimiento óptimo en un escenario de nivel medio, un servicio que llama a otros servicios en respuesta a los mensajes entrantes, cree una instancia del cliente de servicio de WCF para el servicio remoto una vez y reutilícelo en varias solicitudes entrantes. Crear instancias de los clientes del servicio de WCF es una operación costosa relativa a hacer una llamada de servicio en una instancia de un cliente preexistente, y los escenarios de nivel medio generan ganancias de rendimiento distintas almacenando en memoria caché los clientes remotos de las solicitudes. Los clientes del servicio de WCF son seguros para subprocesos, por lo que no es necesario sincronizar el acceso a un cliente en varios subprocesos.

Los escenarios de nivel medio también generan ganancias de rendimiento utilizando API asincrónicas generadas por la opción svcutil /a. La opción /a hace que Herramienta de utilidad de metadatos de ServiceModel (Svcutil.exe) genere métodos BeginXXX/EndXXX para cada operación del servicio, que permite llamadas potencialmente de ejecución prolongada para los servicios remotos, que se van a realizar en subprocesos de fondo.

WCF en escenarios multitarjeta o de varios nombres

Puede implementar servicios de WCF dentro de una granja de servidores web de IIS, donde un conjunto de equipos comparte un nombre externo común (como https://www.contoso.com) pero son direccionados individualmente por nombres de host diferentes (por ejemplo, https://www.contoso.com podría dirigir el tráfico a dos equipos diferentes denominados (http://machine1.internal.contoso.com y http://machine2.internal.contoso.com). WCFadmite totalmente este escenario de implementación, pero requiere una configuración especial del sitio web de IIS que hospeda los servicios de WCF para mostrar el nombre del host correcto (externo) en los metadatos del servicio (lenguaje de descripción de servicios Web).

Para asegurarse de que el nombre del host correcto aparece en los metadatos de servicio que WCF genera, configure la identidad predeterminada para que el sitio web de IIS que hospeda los servicios de WCF utilice un nombre de host explícito. Por ejemplo, los equipos que residen dentro de la granja www.contoso.com deberían utilizar un enlace de sitio de IIS de *:80:www.contoso.com para HTTP y *:443:www.contoso.com para HTTPS.

Puede configurar los enlaces de sitio web de IIS utilizando el complemento de Microsoft Management Console (MMC).

Los grupos de aplicaciones que se ejecutan en contextos de usuario diferentes sobrescriben los ensamblados desde otras cuentas en la carpeta temporal

Para asegurarse de que los grupos de aplicaciones que se ejecutan en diferentes contextos de usuario no pueden sobrescribir los ensamblados desde otras cuentas en la carpeta de archivos ASP.NET temporales, utilice identidades diferentes y carpetas temporales para las aplicaciones diferentes. Por ejemplo, si tiene dos aplicaciones virtuales /Application1 y / Application2, puede crear dos grupos de aplicaciones, A y B, con dos identidades diferentes. El grupo de aplicaciones A se puede ejecutar bajo una identidad de usuario (user1), mientras que el grupo de aplicaciones B se puede ejecutar bajo otra identidad de usuario (user2) y configurar /Application1 para que use A y /Application2 para que use B.

En Web.config, puede configurar la carpeta temporal mediante <system.web/compilation/@tempFolder>. Para /Application1, puede ser "c:\tempForUser1" y para application2 puede ser "c:\tempForUser2". Conceda el permiso de escritura correspondiente a estas carpetas para las dos identidades.

A continuación, user2 no puede cambiar la carpeta de generación de código para /application2 (bajo c:\tempForUser1).

Habilitar el procesamiento asincrónico

De forma predeterminada, los mensajes enviados a un servicio de WCF hospedado en IIS 6.0 y versiones anteriores se procesan de forma sincrónica. ASP.NET llama a WCF en su propio subproceso (el subproceso de trabajo de ASP.NET) y WCF usa otro subproceso para procesar la solicitud. WCF acapara el subproceso de trabajo de ASP.NET hasta que este complete su procesamiento. Esto lleva a un procesamiento sincrónico de las solicitudes. El procesamiento de las solicitudes de forma asincrónica ofrece una mayor escalabilidad, ya que reduce el número de subprocesos necesarios para procesar una solicitud. WCF no acapara el subproceso de ASP.NET mientras procesa la solicitud. No se recomienda el uso del comportamiento asincrónico en equipos que ejecuten IIS 6.0, ya que no es posible limitar las solicitudes entrantes que exponen al servidor a ataques por denegación de servicio (DOS). A partir de IIS 7.0, se ha presentado un acelerador de solicitudes simultáneas: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0]“MaxConcurrentRequestsPerCpu. Con este nuevo acelerador, el procesamiento asincrónico se puede usar de forma segura. De forma predeterminada en IIS 7.0, se registran el controlador y el módulo asincrónicos. Si se ha deshabilitado, puede habilitar manualmente el procesamiento asincrónico de las solicitudes en el archivo Web.config de la aplicación. La configuración que se use depende de la configuración de aspNetCompatibilityEnabled. Si ha establecido aspNetCompatibilityEnabled en false, configure el objeto ServiceHttpModule tal y como se muestra en el fragmento de código de configuración siguiente.

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="false" />    
  </system.serviceModel>
  <system.webServer>
    <modules>
      <remove name="ServiceModel"/>
      <add name="ServiceModel" 
           preCondition="integratedMode,runtimeVersionv2.0" 
           type="System.ServiceModel.Activation.ServiceHttpModule, System.ServiceModel,Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
    </modules>
    </system.webServer>

Si ha establecido aspNetCompatibilityEnabled en true, configure el objeto ServiceHttpHandlerFactory tal y como se muestra en el fragmento de código de configuración siguiente.

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />    
  </system.serviceModel>
  <system.webServer>
    <handlers>
          <clear/>
          <add name="TestAsyncHttpHandler" 
               path="*.svc" 
               verb="*" 
               type="System.ServiceModel.Activation.ServiceHttpHandlerFactory, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"         
               />
    </handlers>    
  </system.webServer>

Vea también

Otros recursos

Service Hosting Samples
Características de hospedaje de Windows Server App Fabric