Procedure consigliate per l'hosting di Internet Information Services

2025-06-17

In questo argomento vengono descritte alcune procedure consigliate per l'hosting di servizi Windows Communication Foundation (WCF).

Implementazione di servizi WCF come DLL

L'implementazione di un servizio WCF come DLL distribuita nella directory \bin di un'applicazione Web consente di riutilizzare il servizio all'esterno del modello di applicazione Web, ad esempio in un ambiente di test che potrebbe non avere Internet Information Services (IIS).

Host del servizio nelle applicazioni IIS-Hosted

Non usare le API imperative self-host per creare nuovi host di servizi che ascoltano su trasporti di rete non supportati nativamente dall'ambiente di hosting IIS (ad esempio, IIS 6.0 per ospitare servizi TCP, poiché la comunicazione TCP non è supportata nativamente in IIS 6.0). Questo approccio non è consigliato. Gli host del servizio creati in modo imperativo non sono noti all'interno dell'ambiente di hosting IIS. Il punto critico è che l'elaborazione eseguita da servizi creati in modo imperativo non viene in considerazione da IIS quando determina se il pool di applicazioni di hosting è inattiva. Il risultato è che le applicazioni con host del servizio creati in modo imperativo hanno un ambiente di hosting IIS che elimina in modo aggressivo i processi host IIS.

URI ed endpoint di IIS-Hosted

Gli endpoint per un servizio ospitato in IIS devono essere configurati usando URI (Uniform Resource Identifier) relativi, non indirizzi assoluti. Ciò garantisce che l'indirizzo dell'endpoint sia compreso nel set di indirizzi URI che appartengono all'applicazione host e garantisce che l'attivazione basata su messaggi venga eseguita come previsto.

Gestione dello stato e riciclo dei processi

L'ambiente di hosting IIS è ottimizzato per i servizi che non mantengono lo stato locale in memoria. IIS ricicla il processo host in risposta a un'ampia gamma di eventi esterni e interni, causando la perdita di qualsiasi stato volatile archiviato esclusivamente in memoria. I servizi ospitati in IIS devono archiviare lo stato esterno al processo (ad esempio, in un database) o in una cache in memoria che può essere facilmente ricreata se si verifica un evento di riciclo dell'applicazione.

Annotazioni

I protocolli usati da WCF per l'affidabilità e la sicurezza a livello di messaggio usano lo stato volatile in memoria. Le sessioni affidabili WCF e le sessioni di sicurezza possono terminare in modo imprevisto a causa del riciclo delle applicazioni. Le applicazioni ospitate in IIS che usano questi protocolli devono dipendere da un elemento diverso dalla chiave di sessione fornita da WCF per correlare lo stato del livello applicazione (ad esempio, un costrutto a livello di applicazione o un'intestazione di correlazione personalizzata) o disabilitare il riciclo del processo IIS per l'applicazione ospitata.

Ottimizzazione delle prestazioni negli scenari di Middle-Tier

Per ottenere prestazioni ottimali in uno scenario di livello intermedio, ovvero un servizio che effettua chiamate ad altri servizi in risposta ai messaggi in arrivo, creare un'istanza del client del servizio WCF al servizio remoto una sola volta e riutilizzarla tra più richieste in ingresso. La creazione di istanze dei client del servizio WCF è un'operazione costosa rispetto all'esecuzione di una chiamata al servizio su un'istanza client preesistente e gli scenari di livello intermedio producono miglioramenti distinti delle prestazioni memorizzando nella cache i client remoti tra le richieste. I client del servizio WCF sono thread-safe, pertanto non è necessario sincronizzare l'accesso a un client tra più thread.

Gli scenari di livello intermedio producono anche miglioramenti delle prestazioni usando le API asincrone generate dall'opzione svcutil /a . L'opzione /a fa sì che lo strumento Utilità metadati ServiceModel (Svcutil.exe) generi BeginXXX/EndXXX metodi per ogni operazione del servizio, che consente di effettuare chiamate potenzialmente a esecuzione prolungata ai servizi remoti nei thread in background.

WCF in scenari con più connessioni di rete o con più nomi

È possibile distribuire servizi WCF all'interno di una Web farm IIS, in cui un set di computer condividono un nome esterno comune (ad esempio http://www.contoso.com) ma vengono indirizzati singolarmente da nomi host diversi( ad esempio, http://www.contoso.com potrebbe indirizzare il traffico a due computer diversi denominati http://machine1.internal.contoso.com e http://machine2.internal.contoso.com). Questo scenario di distribuzione è completamente supportato da WCF, ma richiede una configurazione speciale del sito Web IIS che ospita i servizi WCF per visualizzare il nome host corretto (esterno) nei metadati del servizio (Linguaggio di descrizione dei servizi Web).

Per assicurarsi che il nome host corretto venga visualizzato nei metadati del servizio generato da WCF, configurare l'identità predefinita per il sito Web IIS che ospita i servizi WCF per l'uso di un nome host esplicito. Ad esempio, i computer che risiedono all'interno della www.contoso.com farm devono usare un'associazione del sito IIS di *:80:www.contoso.com for HTTP and *:443:www.contoso.com for HTTPS.

È possibile configurare le associazioni di siti Web IIS usando lo snap-in IIS Microsoft Management Console (MMC).

I pool di applicazioni in esecuzione in contesti utente diversi sovrascrivono gli assembly provenienti da altri profili nella cartella temporanea.

Per assicurarsi che i pool di applicazioni in esecuzione in contesti utente diversi non possano sovrascrivere assembly da altri account nella cartella dei file temporanei ASP.NET, usare identità diverse e cartelle temporanee per applicazioni diverse. Ad esempio, se si dispone di due applicazioni virtuali /Application1 e /Application2, è possibile creare due pool di applicazioni, A e B, con due identità diverse. Il pool di applicazioni A può essere eseguito con un'identità utente (user1) mentre il pool di applicazioni B può essere eseguito con un'altra identità utente (user2) e configurare /Application1 per usare A e /Application2 per l'uso di B.

In Web.configè possibile configurare la cartella temporanea usando <system.web/compilation/@tempFolder>. Per /Application1, può essere "c:\tempForUser1" e per application2 può essere "c:\tempForUser2". Concedere l'autorizzazione di scrittura corrispondente a queste cartelle per le due identità.

Quindi user2 non può modificare la cartella di generazione del codice per /application2 (in c:\tempForUser1).

Abilitazione dell'elaborazione asincrona

Per impostazione predefinita, i messaggi inviati a un servizio WCF ospitato in IIS 6.0 e versioni precedenti vengono elaborati in modo sincrono. ASP.NET chiamate a WCF nel proprio thread (il thread di lavoro ASP.NET) e WCF usa un altro thread per elaborare la richiesta. WCF mantiene il thread di lavoro ASP.NET fino a quando non completa l'elaborazione. Ciò comporta l'elaborazione sincrona delle richieste. L'elaborazione delle richieste in modo asincrono consente una maggiore scalabilità perché riduce il numero di thread necessari per elaborare una richiesta : WCF non è in possesso del thread ASP.NET durante l'elaborazione della richiesta. L'uso del comportamento asincrono non è consigliato per i computer che eseguono IIS 6.0 perché non è possibile limitare le richieste in ingresso che aprono il server agli attacchi Denial Of Service (DOS). A partire da IIS 7.0, è stato introdotto lo strumento di limitazione delle richieste simultanee: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0]"MaxConcurrentRequestsPerCpu. Con questo nuovo acceleratore, è sicuro utilizzare l'elaborazione asincrona. Per impostazione predefinita in IIS 7.0, vengono registrati il gestore asincrono e il modulo. Se questa opzione è stata disattivata, è possibile abilitare manualmente l'elaborazione asincrona delle richieste nel file di Web.config dell'applicazione. Le impostazioni usate dipendono dall'impostazione aspNetCompatibilityEnabled . Se hai aspNetCompatibilityEnabled impostato su false, configura System.ServiceModel.Activation.ServiceHttpModule come illustrato nel seguente frammento di configurazione.

<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>

Se hai impostato aspNetCompatibilityEnabled su true, configura System.ServiceModel.Activation.ServiceHttpHandlerFactory come illustrato nel frammento di configurazione seguente.

<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>

Condividi tramite