Konflikty, sníženého výkonu a zablokování při volání webové služby z aplikace technologie ASP.NET

Příznaky

Pokud provedete volání webové služby z aplikace Microsoft ASP.NET, může dojít k konflikty, sníženého výkonu a zablokování. Klienti mohou hlásit, že požadavky přestat reagovat (nebo "zavěsit"), nebo trvat velmi dlouhou dobu spuštění. Pokud podezření na zablokování, může být pracovní proces recyklován. Může se zobrazit následující zprávy v protokolu událostí aplikace.
  • Pokud používáte Internetová informační služba (IIS) 5.0, můžete zobrazit následující zprávy v protokolu aplikace:
  • Pokud používáte službu IIS 6.0, můžete zobrazit následující zprávy v protokolu aplikace:
  • Pokud používáte službu IIS 6.0, můžete zobrazit následující zprávy v protokolu systému:
Také zobrazí následující chybová zpráva výjimka při volání HttpWebRequest.GetResponse metody:
"Výjimka System.InvalidOperationException: nebyl dostatek volných vláken ve fondu podprocesů objektu k dokončení této operace."
V prohlížeči můžete obdržet také následující chybová zpráva Výjimka:
"HttpException (0x80004005): Vypršel časový limit žádosti."
Poznámka: Tento článek se týká také aplikace, které přímo požádat HttpWebRequest .

Příčina

Tomuto problému může dojít, protože technologie ASP.NET omezuje počet pracovních podprocesů a dokončení port podprocesů volání můžete použít k provedení požadavků.

Volání webové služby se obvykle používá jeden podproces spuštění kódu, který odesílá požadavek a jeden podproces dokončení port pro příjem zpětného volání z webové služby. Pokud však požadavek přesměrován, nebo vyžaduje ověření, volání může použít až dva pracovní podprocesy a oba podprocesy port dokončení. Proto můžete vyčerpat spravované zachovalo, při současně dojít k více voláním webové služby.

Předpokládejme například, že zachovalo je omezena na 10 pracovních podprocesů a všech 10 pracovních podprocesů aktuálně prováděných kód, který čeká na zpětné volání spustit. Zpětné volání lze nikdy spustit, protože všechny pracovní položky, které jsou ve frontě fondu podprocesů jsou blokovány, dokud nebude k dispozici podproces.

Další potenciální zdroj konfliktu je maxconnection parametr, který používá obor názvů System.Net omezit počet připojení. Obecně platí tento limit funguje podle očekávání. Však pokud mnoho aplikací se pokusí provést mnoho požadavků na jedinou adresu IP ve stejné době, může mít podprocesy čekání na připojení k dispozici.

Řešení

Chcete-li vyřešit tyto potíže, můžete optimalizovat následující parametry v souboru Machine.config, která nejlépe vyhovuje dané situaci:
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • maxconnection
  • executionTimeout
Chcete-li tyto problémy vyřešit úspěšně, můžete proveďte následující akce:
  • Omezení počtu požadavků technologie ASP.NET, které mohou být prováděny ve stejnou dobu přibližně 12 na jeden procesor.
  • Povolte webové služby zpětná volně použít vlákna zachovalo.
  • Vyberte odpovídající hodnotu parametru maxconnections . Počet adres IP a součástí AppDomain, které jsou používány založte svůj výběr.
Poznámka: Doporučení omezit počet žádostí technologie ASP.NET 12 každý procesor je poněkud svévolné. Toto omezení však ukázala dobře fungovat pro většinu aplikací.

maxWorkerThreads a maxIoThreads

Technologie ASP.NET používá následující dvě konfigurace nastavení omezit maximální počet pracovních podprocesů a ukončení podprocesů, které jsou používány:
<processModel maxWorkerThreads="20" maxIoThreads="20">
Parametr maxWorkerThreads a maxIoThreads parametru se implicitně násobí počet procesorů. Například pokud máte dva procesory, maximální počet pracovních podprocesů je následující:
2*maxWorkerThreads

minFreeThreads a minLocalRequestFreeThreads

Technologie ASP.NET obsahuje také následující nastavení konfigurace, které určují počet pracovních podprocesů a podprocesy port dokončení musí být k dispozici pro spuštění vzdáleného požadavku nebo místní požadavek:
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
Pokud nejsou k dispozici dostatečné vláken, žádost je zařazen do fronty dokud dostatečně vlákna jsou zdarma k provedení požadavku. Proto technologie ASP.NET nebude možné spustit více než následující počet požadavků současně:
(maxWorkerThreads*počet procesorů)-minFreeThreads
Poznámka: Parametru minFreeThreads a pomocí parametru minLocalRequestFreeThreads nejsou implicitně násobí počtem procesorů.

minWorkerThreads

Technologie ASP.NET k ASP.NET 1.1 a ASP.NET 1.0 Service Pack 3 také obsahuje následující nastavení konfigurace, která určuje, kolik pracovních podprocesů může být k dispozici okamžitě služby vzdáleného požadavku.
<processModel minWorkerThreads="1">
Podprocesů, které jsou ovládány pomocí tohoto nastavení lze vytvořit rychlostí mnohem rychlejší než pracovních podprocesů, které jsou vytvořeny z možnosti "vlákno ladění" výchozí modul CLR. Toto nastavení umožňuje požadavky technologie ASP.NET do služby, které mohou být náhle naplnění fronty požadavků ASP.NET kvůli zpomalování na serveru back-end, náhlé shlukového přenosu požadavků koncového klienta nebo něco podobného, který by způsobil náhlým nárůstem počtu požadavků ve frontě. Výchozí hodnota pro parametr minWorkerThreads je 1. Doporučujeme nastavit hodnotu pro parametr minWorkerThreads na následující hodnotu.
minWorkerThreads = maxWorkerThreads / 2
Ve výchozím parametr minWorkerThreads není v souboru Web.config nebo Machine.config. Toto nastavení implicitně násobí počet procesorů.

maxconnection

Maxconnection parametr určuje, kolik připojení lze provádět určitou adresu IP. Parametr se zobrazí takto:
<connectionManagement>    <add address="*" maxconnection="2">
<add address="http://65.53.32.230" maxconnection="12">
</connectionManagement>
Pokud kód aplikace odkazuje aplikace podle názvu hostitele namísto adresy IP, parametr by měl vypadat takto:
<connectionManagement>    <add address="*" maxconnection="2">
<add address="http://hostname" maxconnection="12">
</connectionManagement>
Nakonec-pokud aplikace je umístěn na jiný port než 80, parametr musí obsahovat nestandardní port v identifikátoru URI je podobná následující:
<connectionManagement>    <add address="*" maxconnection="2">
<add address="http://hostname:8080" maxconnection="12">
</connectionManagement>
Nastavení parametrů, které jsou popsány dříve v tomto článku budou na úrovni procesu. Nastavení parametru maxconnection však platí na úrovni domény aplikace. Ve výchozím nastavení vzhledem k tomu, že toto nastavení platí pro úroveň domény aplikace, můžete vytvořit maximálně dvě připojení na konkrétní adresu IP z každé domény aplikace v procesu.

executionTimeout

Technologie ASP.NET používá následující nastavení konfigurace omezit doba provádění požadavku:
<httpRuntime executionTimeout="90"/>
Tento limit lze nastavit také pomocí vlastnosti Server.ScriptTimeout .

Poznámka: Pokud zvýšíte hodnotu položky executionTimeout parametru, bude pravděpodobně také změnit nastavení parametru processModel responseDeadlockInterval .

Doporučení

Nastavení, které se doporučuje v této části nemusí fungovat u všech aplikací. Však následující doplňkové informace vám mohou pomoci provádět příslušné úpravy.

Pokud provádíte jednu volání webové služby na jedinou adresu IP z každé stránky ASPX, společnost Microsoft doporučuje použít následující nastavení konfigurace:
  • Hodnoty parametru maxWorkerThreads a maxIoThreads parametru nastavena na hodnotu 100.
  • Nastavte hodnotu maxconnection parametr 12 *N (kde N je počet procesorů, které máte k dispozici).
  • Nastavte hodnoty parametru minFreeThreads 88 *N a pomocí parametru minLocalRequestFreeThreads 76 *N.
  • Nastavte hodnotu minWorkerThreads na 50. Nezapomeňte, že minWorkerThreads není ve výchozím nastavení konfiguračního souboru. Je třeba ji přidat.
Některé z těchto doporučení se týkají jednoduchý vzorec, který zahrnuje počet procesorů na serveru. Proměnná, která představuje počet procesorů ve vzorcích je N. Pro tato nastavení máte hyperthreading povoleno, je nutné použít počet logických procesorů místo počet fyzických procesorů. Například pokud máte čtyřprocesorových server s povoleným hyperthreading, pak hodnota N ve vzorcích budou 8 místo 4.

Poznámka: Při použití této konfigurace lze provést maximálně 12 ASP.NET požadavky na procesor ve stejnou dobu, protože 100 88 = 12. Tedy minimálně 88 *N pracovních podprocesů a 88 *N dokončení port vlákna jsou k dispozici pro další použití (například konkrétní zpětná volání webové služby).

Například používáte server se čtyřmi procesory a hyperthreading povoleno. Na základě těchto vzorců, použili byste následující hodnoty pro nastavení konfigurace, které jsou zmíněny v tomto článku.
<system.web><processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"/>
<httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"/>
</system.web>

<system.net>
<connectionManagement>
<add address="[ProvideIPHere]" maxconnection="96"/>
</connectionManagement>
</system.net>

Navíc při použití této konfigurace 12 připojení jsou k dispozici na procesor jedné IP adrese pro jednotlivé domény aplikace. Proto v následující situaci velmi málo soupeření dojde k požadavků čeká na připojení a není vyčerpán fondu podprocesů:
  • Na webu je hostitelem pouze jedna aplikace (AppDomain).
  • Každý požadavek na stránku ASPX je jeden požadavek webové služby.
  • Všechny požadavky se stejnou IP adresou.
Však při použití této konfigurace scénářích, které obsahují jednu z následujících akcí bude pravděpodobně používat příliš mnoho připojení:
  • Požadavky jsou na více adres IP.
  • Požadavky jsou přesměrované (302 stavový kód).
  • Požadavky vyžadují ověřování.
  • Požadavky jsou vyrobeny z více součástí AppDomain.
V těchto situacích je vhodné použít nižší hodnotu maxconnection parametr a vyšší hodnoty parametru minFreeThreads a pomocí parametru minLocalRequestFreeThreads .

Stav

Toto chování je záměrné.

Další informace

Pokud dochází k nedostatečný výkon a soupeření ve službě IIS 7.0 a ASP.NET, přejděte na následující Microsoft blogy:

Odkazy

Další informace naleznete na následujícím webu Microsoft Developer Network (MSDN):
Vlastnosti

ID článku: 821268 - Poslední kontrola: 16. 1. 2017 - Revize: 1

Váš názor