Wat is de beste werkwijze om te bepalen hoeveel werkprocessen een ASP.NET-webtoepassing toestaan?
Op één server die ik beheer, is het maken van een nieuwe AppPool standaard ingesteld op 10 (maximum) werkprocessen. Andere mensen suggereren dat de normale instelling één is.
Welk probleem lost meerdere werkprocessen op en wat zijn de technieken om te beslissen hoeveel?
Antwoord 1, autoriteit 100%
Werkprocessen zijn een manier om de uitvoering van uw website te segmenteren over meerdere exe’s. Je doet dit om een aantal redenen: als een van de werkers wordt belaagd door runtime-problemen, worden de anderen niet uitgeschakeld. Als er bijvoorbeeld een html-verzoek binnenkomt waardoor het proces op niets uitloopt, worden alleen de andere verzoeken die door die ene werkprocessor worden afgehandeld, gedood. Een ander voorbeeld is dat één verzoek kan leiden tot blokkering van de andere threads die door dezelfde werknemer worden afgehandeld.
Voor zover je er zoveel nodig hebt, kun je wat belastingstests doen. Druk hard op de app en kijk wat er gebeurt met slechts één. Voeg er dan wat meer aan toe en druk er opnieuw op. Op een gegeven moment zul je een punt bereiken waarop het netwerk, de schijf, de cpu en het ram van de machine echt verzadigd zijn. Dan weet je dat je de juiste balans hebt.
Overigens kunt u het aantal threads dat per werkproces wordt gebruikt, beheren via het bestand machine.config. Ik geloof dat de sleutel maxWorkerThreads is.
Pas op, als u sessie gebruikt, wordt de sessiestatus niet gedeeld tussen werkprocessen. Over het algemeen raad ik aan om toch een sessie te vermijden, maar het is iets om te overwegen.
In alle opzichten kunt u elk werkproces beschouwen als een eigen afzonderlijke webserver. Behalve dat ze op dezelfde box draaien.
Antwoord 2, autoriteit 9%
Geheugenlekken
Het andere grootste voordeel is het omgaan met geheugenlekken. Soms, hoe vaak je ook probeert om je code te optimaliseren, maar er zijn geheugenlekken in het framework zelf en andere bibliotheken van derden. We hebben gemerkt dat onze applicatie uiteindelijk een zeer hoog geheugen bereikt en geen geheugenuitzonderingen begint te geven.
Dus we moesten een maximale virtuele geheugenlimiet voor het werkproces instellen op 1 GB en meerdere processen laten draaien. Je zou zelfs een maximale virtuele limiet kunnen instellen voor een enkelvoudig werkproces, maar dit leidt tot pieken van vertraging, omdat wanneer het werkproces wordt gerecycled, alle verzoeken traag zijn totdat het werkproces een goede snelheid bereikt. Omdat onze applicatie interne caching heeft (Entity Framework Query Cache, sommige objectpools), vertraagt elk van deze dingen het starten van de applicatie. Dit is waar het proces van één enkele werknemer het meest pijn doet.
Als er meerdere werkprocessen zijn, is slechts één proces in de recyclemodus traag, maar andere behouden een goede snelheid.
Antwoord 3, autoriteit 5%
Een ander geval waarin het zinvol is om veel werkprocessen te hebben, is als uw toepassing vergrendelingen bevat die de parallellisatie ervan verhinderen. Op GDI+ gebaseerde beeldverwerking is een van de voorbeelden.
Ik vond het toen ik een oplossing probeerde te vinden voor mijn probleem.