Metodtips för internetinformationstjänster
I det här avsnittet beskrivs några metodtips för att hantera WCF-tjänster (Windows Communication Foundation).
Implementera WCF-tjänster som DLL:er
Genom att implementera en WCF-tjänst som en DLL som distribueras till katalogen \bin i ett webbprogram kan du återanvända tjänsten utanför webbprogrammodellen, till exempel i en testmiljö som kanske inte har Distribuerat Internet Information Services (IIS).
Tjänstvärdar i IIS-värdbaserade program
Använd inte imperativa API:er för självvärdar för att skapa nya tjänstvärdar som lyssnar på nätverkstransporter som inte stöds internt av IIS-värdmiljön (till exempel IIS 6.0 som värd för TCP-tjänster, eftersom TCP-kommunikation inte stöds internt på IIS 6.0). Den här metoden rekommenderas inte. Tjänstvärdar som skapas imperativt är inte kända i IIS-värdmiljön. Den kritiska punkten är att bearbetning som utförs av imperativt skapade tjänster inte redovisas av IIS när den avgör om värdprogrampoolen är inaktiv. Resultatet är att program som har sådana imperativt skapade tjänstvärdar har en IIS-värdmiljö som aggressivt tar bort IIS-värdprocesser.
URI:er och IIS-värdbaserade slutpunkter
Slutpunkter för en IIS-värdbaserad tjänst ska konfigureras med hjälp av relativa URI:er (Uniform Resource Identifiers), inte absoluta adresser. Detta garanterar att slutpunktsadressen ligger inom den uppsättning URI-adresser som tillhör värdprogrammet och ser till att meddelandebaserad aktivering sker som förväntat.
Tillståndshantering och processåtervinning
IIS-värdmiljön är optimerad för tjänster som inte upprätthåller lokalt tillstånd i minnet. IIS återvinner värdprocessen som svar på en mängd olika externa och interna händelser, vilket gör att alla flyktiga tillstånd som lagras uteslutande i minnet går förlorade. Tjänster som finns i IIS bör lagra sitt tillstånd utanför processen (till exempel i en databas) eller i ett minnesinternt cacheminne som enkelt kan återskapas om en programåtervinnelsehändelse inträffar.
Kommentar
Protokollen som WCF använder för tillförlitlighet och säkerhet på meddelandenivå använder det flyktiga minnesinterna tillståndet. WCF-tillförlitliga sessioner och säkerhetssessioner kan avslutas oväntat på grund av programåtervinn. IIS-värdbaserade program som använder dessa protokoll bör antingen vara beroende av något annat än den WCF-tillhandahållna sessionsnyckeln för korrelering av programnivåtillstånd (till exempel en konstruktion på programnivå eller ett anpassat korrelationshuvud) eller inaktivera IIS-processåtervinning för det värdbaserade programmet.
Optimera prestanda i scenarier på mellannivå
För optimala prestanda i ett scenario på mellannivå – en tjänst som anropar andra tjänster som svar på inkommande meddelanden – instansierar WCF-tjänstklienten till fjärrtjänsten en gång och återanvänder den över flera inkommande begäranden. Instansiering av WCF-tjänstklienter är en dyr åtgärd i förhållande till att göra ett tjänstanrop på en befintlig klientinstans, och scenarier på mellannivå ger distinkta prestandavinster genom att cachelagra fjärrklienter mellan begäranden. WCF-tjänstklienter är trådsäkra, så det är inte nödvändigt att synkronisera åtkomsten till en klient över flera trådar.
Scenarier på mellannivå ger också prestandavinster med hjälp av de asynkrona API:er som genereras av svcutil /a
alternativet. Alternativet /a
gör att verktyget ServiceModel Metadata Utility (Svcutil.exe) genererar BeginXXX/EndXXX
metoder för varje tjänståtgärd, vilket gör att potentiellt långvariga anrop till fjärrtjänster kan göras i bakgrundstrådar.
WCF i scenarier med flera hem eller flera namngivna
Du kan distribuera WCF-tjänster i en IIS-webbgrupp, där en uppsättning datorer delar ett gemensamt externt namn (till exempel ) men hanteras individuellt av olika värdnamn (till exempel http://www.contoso.com
kan dirigera trafik till två olika datorer med http://www.contoso.com
namnet http://machine1.internal.contoso.com
och http://machine2.internal.contoso.com
). Det här distributionsscenariot stöds fullt ut av WCF, men kräver särskild konfiguration av IIS-webbplatsen som är värd för WCF-tjänster för att visa rätt (externt) värdnamn i tjänstens metadata (Web Services Description Language).
För att säkerställa att rätt värdnamn visas i tjänstens metadata som WCF genererar konfigurerar du standardidentiteten för IIS-webbplatsen som är värd för WCF-tjänster för att använda ett explicit värdnamn. Datorer som finns i www.contoso.com
servergruppen bör till exempel använda en IIS-platsbindning av *:80:www.contoso.com för HTTP och *:443:www.contoso.com för HTTPS.
Du kan konfigurera IIS-webbplatsbindningar med hjälp av snapin-modulen IIS Microsoft Management Console (MMC).
Programpooler som körs i olika användarkontexter skriver över sammansättningar från andra konton i den tillfälliga mappen
För att säkerställa att programpooler som körs i olika användarkontexter inte kan skriva över sammansättningar från andra konton i mappen temporära ASP.NET filer använder du olika identiteter och tillfälliga mappar för olika program. Om du till exempel har två virtuella program /Application1 och /Application2 kan du skapa två programpooler, A och B, med två olika identiteter. Programpool A kan köras under en användaridentitet (användare1) medan programpool B kan köras under en annan användaridentitet (användare2) och konfigurera /Application1 att använda A och /Application2 för att använda B.
I Web.config kan du konfigurera den tillfälliga mappen med hjälp av <system.web/compilation/@tempFolder>. För /Application1 kan det vara "c:\tempForUser1" och för application2 kan det vara "c:\tempForUser2". Bevilja motsvarande skrivbehörighet till dessa mappar för de två identiteterna.
Sedan kan user2 inte ändra kodgenereringsmappen för /application2 (under c:\tempForUser1).
Aktivera asynkron bearbetning
Som standard bearbetas meddelanden som skickas till en WCF-tjänst som finns under IIS 6.0 och tidigare på ett synkront sätt. ASP.NET anropar till WCF i en egen tråd (ASP.NET-arbetstråden) och WCF använder en annan tråd för att bearbeta begäran. WCF håller i ASP.NET-arbetstråden tills bearbetningen har slutförts. Detta leder till synkron bearbetning av begäranden. Bearbetning av begäranden möjliggör asynkront större skalbarhet eftersom det minskar antalet trådar som krävs för att bearbeta en begäran – WCF håller inte kvar i den ASP.NET tråden när begäran bearbetas. Användning av asynkront beteende rekommenderas inte för datorer som kör IIS 6.0 eftersom det inte finns något sätt att begränsa inkommande begäranden som öppnar servern för DoS-attacker (Denial Of Service ). Från och med IIS 7.0 har en samtidig begränsning av begäran införts: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0]"MaxConcurrentRequestsPerCpu
. Med den här nya begränsningen är det säkert att använda asynkron bearbetning. Som standard i IIS 7.0 registreras den asynkrona hanteraren och modulen. Om detta har inaktiverats kan du aktivera asynkron bearbetning av begäranden manuellt i programmets Web.config-fil. Vilka inställningar du använder beror på din aspNetCompatibilityEnabled
inställning. Om du har aspNetCompatibilityEnabled
angett till false
konfigurerar du System.ServiceModel.Activation.ServiceHttpModule
enligt följande konfigurationsfragment.
<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>
Om du har aspNetCompatibilityEnabled
angett till true
konfigurerar du enligt System.ServiceModel.Activation.ServiceHttpHandlerFactory
följande konfigurationsfragment.
<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>