HAVIT Knowledge Base

Vývoj webových aplikací, .NET, SQL, návrh
Welcome to HAVIT Knowledge Base Sign in | Join | Help
-
Home Články Forums Obrázky Soubory

ASP.NET

Vývoj webových aplikací ASP.NET

Pozor na IIS Application pool: Maximum Worker Processes (Web Garden)

V nastavení application poolu na IIS je zastrčeno jedno nastavení s výchozí hodnotou 1, které je poměrně zrádné, pokud ho někdo změní a neví, co to přesně znamená.

Jde o volbu "Maximum Worker Processes" a neznalé svádí tuto hodnotu z jedničky zvětšit na vyšší číslo.

Co to však ve skutečnosti znamená - jde o to, že IIS pustí pro Application Pool více instancí Worker Processu (w3wp.exe), které jsou navzájem izolované. Vznikne tak více nezávislých instancí aplikací běžících na daném Application Poolu a celé se to začne chovat jako Web Garden (= lokální virtuální Web Farm na jednom serveru). Následky jsou pak prakticky stejné, jako běh aplikace na webové famě - instance aplikace mezi sebou nezdílí kontext (Application, Cache, in-proc Session, atp.).

Protože každý Váš request pak může vyřdit jiná instance aplikace, projevy mohou být např. následující:

- ztrácí se Vám Session, pokud používáte výchozí InProc session (hodnoty Session jsou uloženy na jiném "serveru", než který vyřizuje aktuální request),

- nefunguje dobře cachování (každý "server" si udržuje vlastní cache a musí se tedy naplnit tolik cachí, kolik "serverů" Vám běží),

- ztrácí se Vám hodnoty Application contextu (opět stejný důvod),

- nefungují Vám grafy DevXpress (protože si obrázek ukládají do lokálního contextu v okamžiku renderování stránky s grafem a požadavek browseru na obrázek grafu se dostane na jiný "server"),

- atp. atp.

Osobně v běžném provozu nenacházím scénář, kde by Maximum Worker Processes mělo být nastaveno jinak než na 1. Dokážu si představit jedině, že někdo chce záměrně testovat chování své aplikace na webové farmě, nebo nějaké obskurní důvody s unmanaged componentami, nebo řešením nedostatečné thread-safety aplikace).

Published 23. října 2009 12:25 by Robert Haken

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Kamil said:

Mozna, ze jsem tedy nepochopil princip Web Garden. Chapal jsem to tak, ze kdyz mam napr quad core CPU, tak mohu nastavit 4 WP a tim padem se mi budou paralelne zpracovavat 4 pozadavky. Kdyz dam pocet WP na 1, tak se v jednom okamziku bude zpracovavat jen 1 pozadavek. Je tam myslenka OK, nebo jsem mimo? Pokud je to takhle, tak prece ma smysl nastavovat hodnotu vetsi nez 1.

října 23, 2009 18:08
 

Robert Haken said:

to Kamil: Ne, tak to jste opravdu mimo. Paralelní zpracování requestů je založeno na threadech (vláknech), a jeden WP může paralelně obsluhovat na více procesorech více requestů ve více threadech. Viz též thread-pool.

října 23, 2009 20:02
 

thread said:

prosbicka , jakym zpusobem se da zvysit pocet threadu zpracovavajici pozadavky ? mam aplikaci , ktera vygeneruje 50 pozadavku na webservice , ale v task manageru je u procesu w3wpnapsano jen 30 threadu ??? copak s tim ???

dik

března 3, 2010 0:09
 

Marek G. said:

prosbicka , jakym zpusobem se da zvysit pocet threadu zpracovavajici pozadavky ? mam aplikaci , ktera vygeneruje 50 pozadavku na webservice , ale v task manageru je u procesu w3wpnapsano jen 30 threadu ??? copak s tim ???

dik

března 3, 2010 0:12
 

Robert Haken said:

to Marek G.: počet threadů se řídí nastavením atributů maxWorkerThreads a maxIoThreads v elementu <processModel> ve web.configu, viz MSDN: http://msdn.microsoft.com/en-us/library/7w2sway1(VS.71).aspx

března 3, 2010 8:45
 

Marek G. said:

Tyka se to i  IIS 7.5 ? mam nastaveno v machine.config autoconfig=false

a v aspnet.config

<system.web>

<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"/>

<httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"/>

</system.web>

<system.net>

<connectionManagement>

<add address="*" maxconnection="96"/>

</connectionManagement

a w3wp. ma stale je 30 treadu . neni jeste mozne ze je omezeni na strane webservice ?

března 3, 2010 14:48
 

Robert Haken said:

Marek G. - já bych se v první řadě vykašlal na Task Manager (všeobecný sedmilhář :-)) a podíval se do Perfmonu.

Jinak ještě otázka, jestli opravdu generujete takovou zátěž serveru, která vám vytvoření těch threadů vyvolá?

března 3, 2010 17:07
 

Marek G. said:

zdravim mam prosbicku nemuzeme to probrat treba na icq ? nebo jinem messengeru ? jinak muj mejl je grolms@volny.cz .dik .jinak opravdu ta aplikace generuje 200 threadu , koukal jsem nna pc , ktere generuje tu zatez tak tam je 200 threadu ... ted alenevim zda tyto volani dojdou na server . da se to nejak overit ? Je nejake omezeni na webservicu ze je mozne volat jen 2  webservice a ostatni cekaji ?

března 3, 2010 21:30
 

Robert Haken said:

to Marek G.: Privátní komunikaci mohu nabídnout jedině jako placenou konzultaci, pokud byste měl o něco takového zájem, můj mail je haken_havit_cz. Samostatného omezení na WS si nejsem vědom. Jinak se podívejte opravdu do Performance Monitoru, do sekce ASP.NET, konkrétně countery "Requests Executing", "Requests In Application Queue", resp. "Requests Current" a "Requests Queued" a taky countery v sekci ".NET CLR LocksAndThreads", konkrétně "# current logical Threads".

března 3, 2010 23:36
 

Kamil said:

Skoro přesně po roce jsem narazil na článek, který možná vysvětluje, proč mě zprovoznění web garden zabralo na výkonnostní problémy aplikace (přestože se quad-core CPU flákalo):

http://abhijitjana.net/2010/10/01/what-is-the-difference-between-web-farm-and-web-garden/

http://www.iis-aid.com/articles/performance_testing/boosting_performance_using_an_iis_web_garden

října 18, 2010 21:43
 

Robert Haken said:

to Kamil: Ty články nemají podle mě kvalitu, podle které by se dal udělat závěr, že WebGarden je cesta k lepšímu výkonu.

WebGarden je použitelné tam, kde chcete na jednom počítači udělat virtuální webovou farmu z aplikace, která je napsána tak blbě, že ani konfigurační úpravy jeidné její instance neposkytnou potřebný výkon.

Jinak povolit větší množství threadů a více paměti pro aplikaci se dá i na jedné instancí příslušným nastavením processModelu a dalších voleb, přičemž potom aplikace dokáže využít nejenom CPU (díky vyššímu počtu threadů) a více paměti (díky navýšeným limitům), ale hlavně dokáže dobře napsaná aplikace díky jediné své instanci sdílet cache a další zdroje, které přináší mnohem větší výkonové zisky, než rozsekání aplikace do web-garden izolovaných instancí.

října 19, 2010 9:27

What do you think?

(required) 
(optional)
(required) 
Enter the code you see below

Submit