Az Internet Information Services üzemeltetési ajánlott eljárásai
Ez a témakör a Windows Communication Foundation (WCF) szolgáltatásainak üzemeltetéséhez ajánlott eljárásokat ismerteti.
WCF-szolgáltatások megvalósítása DLL-ként
Ha a WCF-szolgáltatást DLL-ként implementálja, amely egy webalkalmazás \bin könyvtárában van üzembe helyezve, lehetővé teszi, hogy a szolgáltatást a webalkalmazás-modellen kívül is újra felhasználja, például olyan tesztkörnyezetben, amelyben nincs telepítve az Internet Information Services (IIS).
Szolgáltatás-gazdagépek az IIS által üzemeltetett alkalmazásokban
Ne használja az imperatív önkiszolgáló API-kat olyan új szolgáltatás gazdagépek létrehozására, amelyek az IIS-üzemeltetési környezet által natív módon nem támogatott hálózati átviteleket figyelnek (például az IIS 6.0 tcp-szolgáltatások üzemeltetéséhez, mivel az IIS 6.0 nem támogatja natív módon a TCP-kommunikációt). Ez a megközelítés nem ajánlott. Az imperatív módon létrehozott szolgáltatás-gazdagépek nem ismertek az IIS üzemeltetési környezetében. A kritikus pont az, hogy az imperatívan létrehozott szolgáltatások által végzett feldolgozást az IIS nem veszi figyelembe, amikor megállapítja, hogy az üzemeltetési alkalmazáskészlet tétlen-e. Ennek az az eredménye, hogy az ilyen imperatívan létrehozott szolgáltatás gazdagépekkel rendelkező alkalmazások olyan IIS-üzemeltetési környezettel rendelkeznek, amely agresszíven megsemmisíti az IIS-gazdagépfolyamatokat.
URI-k és IIS által üzemeltetett végpontok
Az IIS által üzemeltetett szolgáltatások végpontjait relatív egységes erőforrás-azonosítókkal (URI-kkal) kell konfigurálni, nem pedig abszolút címekkel. Ez garantálja, hogy a végpontcím az üzemeltetési alkalmazáshoz tartozó URI-címek csoportjába tartozik, és biztosítja, hogy az üzenetalapú aktiválás a várt módon történjen.
Állapotkezelés és folyamat-újrahasznosítás
Az IIS üzemeltetési környezet olyan szolgáltatásokhoz van optimalizálva, amelyek nem tartják fenn a helyi állapotot a memóriában. Az IIS számos külső és belső eseményre reagálva újrahasznosítja a gazdafolyamatot, ami a kizárólag a memóriában tárolt változékony állapot elvesztését okozza. Az IIS-ben üzemeltetett szolgáltatásoknak a folyamaton kívül (például egy adatbázisban) vagy egy memórián belüli gyorsítótárban kell tárolniuk az állapotukat, amely könnyen újra létrehozható, ha egy alkalmazás újrafeldolgozási esemény történik.
Feljegyzés
A WCF protokollok az üzenetréteg megbízhatóságára és biztonságára használják a memóriabeli változó állapotot. A WCF megbízható munkamenetei és biztonsági munkamenetei az alkalmazás-újrahasznosítás miatt váratlanul leállhatnak. Az ilyen protokollokat használó IIS-alapú alkalmazásoknak vagy mástól kell függenie, mint a WCF által biztosított munkamenetkulcs az alkalmazásréteg állapotának korrelálásához (például egy alkalmazásréteg-szerkezethez vagy egyéni korrelációs fejléchez), vagy tiltsa le az IIS-folyamatok újrahasznosítását a üzemeltetett alkalmazáshoz.
A teljesítmény optimalizálása a középső rétegbeli forgatókönyvekben
Az optimális teljesítmény érdekében egy középső szintű forgatókönyvben – amely a bejövő üzenetekre válaszul más szolgáltatásoknak hív meg – példányosíthatja a WCF szolgáltatásügyfélt a távoli szolgáltatásba, és újra felhasználhatja több bejövő kérés között. A WCF-szolgáltatásügyfelek példányosítása költséges művelet ahhoz képest, hogy szolgáltatáshívást kezdeményezünk egy már meglévő ügyfélpéldányon, és a középső szintű forgatókönyvek eltérő teljesítménynövekedést eredményeznek a távoli ügyfelek kérések közötti gyorsítótárazásával. A WCF szolgáltatásügyfelek szálbiztosak, ezért nem szükséges több szálon szinkronizálni az ügyfélhez való hozzáférést.
A középső szintű forgatókönyvek a lehetőség által létrehozott aszinkron API-k használatával is teljesítménynövekedést svcutil /a eredményeznek. Ez /a a beállítás azt eredményezi, hogy a ServiceModel Metadata Segédprogram (Svcutil.exe) metódusokat hoz létre BeginXXX/EndXXX minden egyes szolgáltatásművelethez, ami lehetővé teszi, hogy a távoli szolgáltatásokra irányuló, esetleg hosszan futó hívások háttérszálakon fussanak.
WCF többhelyes vagy több nevesített forgatókönyvekben
A WCF-szolgáltatásokat egy IIS-webfarmon belül is üzembe helyezheti, ahol egy számítógépcsoport közös külső nevet (például http://www.contoso.com) használ, de a különböző gazdagépnevek külön-külön kezelik (például http://www.contoso.com átirányíthatja a forgalmat két különböző nevű http://machine1.internal.contoso.com és http://machine2.internal.contoso.comnevű gépre). Ezt az üzembehelyezési forgatókönyvet a WCF teljes mértékben támogatja, de a WCF-szolgáltatásokat üzemeltető IIS-webhely speciális konfigurációját igényli a megfelelő (külső) gazdagépnév megjelenítéséhez a szolgáltatás metaadataiban (webszolgáltatások leírási nyelve).
Annak érdekében, hogy a WCF által létrehozott szolgáltatás metaadataiban megjelenjen a megfelelő gazdagépnév, konfigurálja a WCF-szolgáltatásokat üzemeltető IIS-webhely alapértelmezett identitását explicit gazdagépnév használatára. A farmon belül www.contoso.com található számítógépeknek például *:80:www.contoso.com IIS-helykötést kell használniuk HTTP-hez és *:443:www.contoso.com HTTPS-hez.
Az IIS-webhelykötéseket az IIS Microsoft Management Console (MMC) beépülő modullal konfigurálhatja.
A különböző felhasználói környezetekben futó alkalmazáskészletek felülírják az ideiglenes mappában lévő más fiókokból származó szerelvényeket
Annak érdekében, hogy a különböző felhasználói környezetekben futó alkalmazáskészletek ne tudják felülírni az ideiglenes ASP.NET fájlok mappájában lévő más fiókokból származó szerelvényeket, használjon különböző identitásokat és ideiglenes mappákat a különböző alkalmazásokhoz. Ha például két virtuális alkalmazással /Application1 és/Application2, két különböző identitással rendelkező alkalmazáskészletet hozhat létre: A és B. Az A alkalmazáskészlet egy felhasználói identitás (felhasználó1) alatt futtatható, míg a B alkalmazáskészlet egy másik felhasználói identitás (felhasználó2) alatt futhat, és az /Application1-et úgy konfigurálhatja, hogy az A és az /Application2 a B-t használja.
A Web.config alkalmazásban konfigurálhatja az ideiglenes mappát a system.web/compilation/@tempFolder> használatával<. Az /Application1 esetében lehet "c:\tempForUser1", az application2 esetében pedig "c:\tempForUser2". Adjon megfelelő írási engedélyt ezekhez a mappákhoz a két identitáshoz.
Ezután a user2 nem tudja módosítani az /application2 kódgenerációs mappáját (a c:\tempForUser1 területen).
Aszinkron feldolgozás engedélyezése
Alapértelmezés szerint az IIS 6.0-s és korábbi verzióiban üzemeltetett WCF-szolgáltatásnak küldött üzenetek feldolgozása szinkron módon történik. ASP.NET a WCF-be irányuló hívások a saját szálán (a ASP.NET feldolgozói szálon) és a WCF egy másik szál használatával dolgozza fel a kérést. A WCF a feldolgozás befejezéséig a ASP.NET feldolgozó szálra marad. Ez a kérések szinkron feldolgozásához vezet. A kérelmek aszinkron feldolgozása nagyobb méretezhetőséget tesz lehetővé, mivel csökkenti a kérés feldolgozásához szükséges szálak számát – a WCF nem tartja meg a ASP.NET szálat a kérés feldolgozása során. Az Aszinkron viselkedés használata nem ajánlott az IIS 6.0 rendszert futtató gépek esetében, mert nem lehet szabályozni a kiszolgálót szolgáltatásmegtagadási (DOS) támadásokra megnyitó bejövő kéréseket. Az IIS 7.0-tól kezdve egyidejű kérés-szabályozást vezetünk be: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0]"MaxConcurrentRequestsPerCpu. Ezzel az új szabályozással biztonságosan használható az aszinkron feldolgozás. Az IIS 7.0 alapértelmezés szerint regisztrálja az aszinkron kezelőt és modult. Ha ez ki van kapcsolva, manuálisan engedélyezheti a kérések aszinkron feldolgozását az alkalmazás Web.config fájljában. A használt beállítások a aspNetCompatibilityEnabled beállítástól függenek. Ha be van aspNetCompatibilityEnabled állítva false, konfigurálja az System.ServiceModel.Activation.ServiceHttpModule alábbi konfigurációs kódrészletben látható módon.
<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>
Ha be van aspNetCompatibilityEnabled állítva, truekonfigurálja az System.ServiceModel.Activation.ServiceHttpHandlerFactory alábbi konfigurációs kódrészletben látható módon.
<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>