Best practices voor het hosten van Internet Information Services
In dit onderwerp vindt u een overzicht van enkele aanbevolen procedures voor het hosten van WCF-services (Windows Communication Foundation).
WCF-services implementeren als DLL's
Door een WCF-service te implementeren als een DLL die is geïmplementeerd in de map \bin van een webtoepassing, kunt u de service buiten het webtoepassingsmodel opnieuw gebruiken, bijvoorbeeld in een testomgeving waarop Mogelijk geen IIS (Internet Information Services) is geïmplementeerd.
Servicehosts in IIS-gehoste toepassingen
Gebruik de imperatieve self-host-API's niet om nieuwe servicehosts te maken die luisteren naar netwerktransporten die niet systeemeigen worden ondersteund door de IIS-hostingomgeving (bijvoorbeeld IIS 6.0 voor het hosten van TCP-services, omdat TCP-communicatie niet systeemeigen wordt ondersteund op IIS 6.0). Deze methode wordt niet aanbevolen. Servicehosts die imperatief zijn gemaakt, zijn niet bekend in de IIS-hostingomgeving. Het kritieke punt is dat de verwerking die wordt uitgevoerd door imperatief gemaakte services, niet wordt verantwoordelijk voor IIS wanneer wordt bepaald of de groep van hostingtoepassingen niet actief is. Het resultaat is dat toepassingen met dergelijke imperatief gemaakte servicehosts een IIS-hostingomgeving hebben waarmee IIS-hostprocessen agressief worden verwijderd.
URI's en IIS-gehoste eindpunten
Eindpunten voor een iis-gehoste service moeten worden geconfigureerd met behulp van relatieve Uniform Resource Identifiers (URI's), niet absolute adressen. Dit garandeert dat het eindpuntadres binnen de set URI-adressen valt die deel uitmaken van de hostingtoepassing en ervoor zorgt dat activering op basis van berichten gebeurt zoals verwacht.
Statusbeheer en procesrecycling
De IIS-hostingomgeving is geoptimaliseerd voor services die geen lokale status in het geheugen onderhouden. IIS recyclet het hostproces als reactie op een verscheidenheid aan externe en interne gebeurtenissen, waardoor vluchtige status die uitsluitend in het geheugen is opgeslagen, verloren gaat. Services die worden gehost in IIS, moeten hun status buiten het proces opslaan (bijvoorbeeld in een database) of in een cache in het geheugen die eenvoudig opnieuw kunnen worden gemaakt als een gebeurtenis voor het recyclen van een toepassing plaatsvindt.
Notitie
De protocollen die WCF gebruikt voor betrouwbaarheid en beveiliging van berichtenlagen maken gebruik van de vluchtige in-memory status. Betrouwbare WCF-sessies en beveiligingssessies kunnen onverwacht worden beëindigd vanwege prullenbakken van toepassingen. Toepassingen die worden gehost door IIS die gebruikmaken van deze protocollen, moeten afhankelijk zijn van iets anders dan de sessiesleutel van WCF voor het correleren van de status van de toepassingslaag (bijvoorbeeld een construct op toepassingslaag of aangepaste correlatieheader) of het recyclen van IIS-processen uitschakelen voor de gehoste toepassing.
Prestaties optimaliseren in scenario's met middelste lagen
Voor optimale prestaties in een scenario met de middelste laag: een service die andere services aanroept als reactie op binnenkomende berichten, maakt u de WCF-serviceclient eenmalig instantiëer naar de externe service en gebruikt u deze opnieuw voor meerdere binnenkomende aanvragen. Het instantiëren van WCF-serviceclients is een dure bewerking ten opzichte van het maken van een serviceaanroep op een bestaand clientexemplaren en scenario's in de middelste laag produceren unieke prestatieverbeteringen door externe clients in de cache op te slaan in aanvragen. WCF-serviceclients zijn thread-veilig, dus het is niet nodig om de toegang tot een client over meerdere threads te synchroniseren.
Scenario's in de middelste laag produceren ook prestatieverbeteringen met behulp van de asynchrone API's die door de svcutil /a optie worden gegenereerd. De /a optie zorgt ervoor dat het Hulpprogramma voor metagegevens van ServiceModel (Svcutil.exe) methoden genereert BeginXXX/EndXXX voor elke servicebewerking, waardoor mogelijk langlopende aanroepen naar externe services kunnen worden uitgevoerd op achtergrondthreads.
WCF in multi-homed- of multi-named scenario's
U kunt WCF-services implementeren binnen een IIS-webfarm, waarbij een set computers een gemeenschappelijke externe naam (zoals http://www.contoso.com) delen, maar afzonderlijk worden geadresseerd door verschillende hostnamen (bijvoorbeeld http://www.contoso.com mogelijk verkeer naar twee verschillende computers met de naam http://machine1.internal.contoso.com en http://machine2.internal.contoso.com). Dit implementatiescenario wordt volledig ondersteund door WCF, maar vereist speciale configuratie van de IIS-website die als host fungeert voor WCF-services om de juiste (externe) hostnaam weer te geven in de metagegevens van de service (Web Services Description Language).
Om ervoor te zorgen dat de juiste hostnaam wordt weergegeven in de servicemetagegevens die WCF genereert, configureert u de standaardidentiteit voor de IIS-website die als host fungeert voor WCF-services voor het gebruik van een expliciete hostnaam. Computers die zich in de www.contoso.com farm bevinden, moeten bijvoorbeeld een IIS-sitebinding van *:80:www.contoso.com voor HTTP en *:443:www.contoso.com voor HTTPS gebruiken.
U kunt IIS-websitebindingen configureren met behulp van de MODULE IIS Microsoft Management Console (MMC).
Toepassingsgroepen die worden uitgevoerd in verschillende gebruikerscontexten overschrijven assembly's van andere accounts in de tijdelijke map
Gebruik verschillende identiteiten en tijdelijke mappen voor verschillende toepassingen om ervoor te zorgen dat toepassingsgroepen die in verschillende gebruikerscontexten worden uitgevoerd, geen assembly's van andere accounts in de map tijdelijke ASP.NET bestanden kunnen overschrijven. Als u bijvoorbeeld twee virtuele toepassingen hebt /Application1 en/Application2, kunt u twee toepassingsgroepen maken, A en B, met twee verschillende identiteiten. Groep A van toepassingen kan worden uitgevoerd onder één gebruikersidentiteit (gebruiker1), terwijl groep B van toepassingen kan worden uitgevoerd onder een andere gebruikersidentiteit (gebruiker2) en /Application1 zo configureren dat A en /Application2 worden gebruikt om B te gebruiken.
In Web.config kunt u de tijdelijke map configureren met system.web </compilation/@tempFolder>. Voor /Application1 kan het 'c:\tempForUser1' zijn en voor application2 kan het 'c:\tempForUser2' zijn. Verdeel de bijbehorende schrijfmachtigingen voor deze mappen voor de twee identiteiten.
Vervolgens kan gebruiker2 de map voor het genereren van code voor /application2 (onder c:\tempForUser1) niet wijzigen.
Asynchrone verwerking inschakelen
Standaard worden berichten die worden verzonden naar een WCF-service die wordt gehost onder IIS 6.0 en eerder, synchroon verwerkt. ASP.NET aanroepen naar WCF op een eigen thread (de ASP.NET werkrolthread) en WCF gebruikt een andere thread om de aanvraag te verwerken. WCF houdt de ASP.NET werkrolthread vast totdat de verwerking is voltooid. Dit leidt tot synchrone verwerking van aanvragen. Het asynchroon verwerken van aanvragen maakt een grotere schaalbaarheid mogelijk, omdat het aantal threads dat nodig is voor het verwerken van een aanvraag vermindert. WCF houdt tijdens het verwerken van de aanvraag niet vast aan de ASP.NET thread. Het gebruik van asynchroon gedrag wordt niet aanbevolen voor machines met IIS 6.0, omdat er geen manier is om binnenkomende aanvragen te beperken die de server openen voor DOS-aanvallen (Denial Of Service ). Vanaf IIS 7.0 is een gelijktijdige aanvraagbeperking geïntroduceerd: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0]"MaxConcurrentRequestsPerCpu. Met deze nieuwe beperking is het veilig om de asynchrone verwerking te gebruiken. Standaard worden de asynchrone handler en module in IIS 7.0 geregistreerd. Als dit is uitgeschakeld, kunt u handmatig asynchrone verwerking van aanvragen inschakelen in het web.config-bestand van uw toepassing. De instellingen die u gebruikt, zijn afhankelijk van uw aspNetCompatibilityEnabled instelling. Als u dit hebt aspNetCompatibilityEnabled ingesteld false, configureert u de System.ServiceModel.Activation.ServiceHttpModule configuratie zoals weergegeven in het volgende configuratiefragment.
<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>
Als u dit hebt aspNetCompatibilityEnabled ingesteld true, configureert u de System.ServiceModel.Activation.ServiceHttpHandlerFactory configuratie zoals wordt weergegeven in het volgende configuratiefragment.
<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>