Bepalen wat IIS onder druk zet

Ik heb een dedicated server met zowel IIS 7.5 als SQL Server 2010. Server CPU-belasting is vaak bijna 100%. DeSQL-serverneemt niet te veel in beslag, maar het w3wp-proces neemt een aanzienlijke hoeveelheid CPU in beslag (vaak 70 +%).

Ik zou graag willen weten wat deze druk veroorzaakt: * Te veel verzoeken van statische bestanden (er kan een CDN aan worden toegevoegd) * Te veel ajax-verzoeken (ik denk sowieso aan comet/web-sockets) * Enkele asp.net-pagina's verbruiken te veel verwerkingskracht (moeten gemakkelijk te optimaliseren zijn)

Waar zou u beginnen om uit te zoeken waar u moet beginnen met optimaliseren?

5
Dit zijn niet zo veel informatie's. Hoeveel web heeft u ingesteld? hoeveel gebruikers zijn op hetzelfde moment verbonden? Hoeveel database en hoe groot zijn ze? Hoe threads is jouw cpu en hoeveel geheugen heb je? Ik heb een geval gezien waarbij de server werd aangevallen en een bot gebruikers aan het maken was op een niet goed beveiligde web-app en miljoenen blogs maakte met slechte dingen. Kun je kijken of je zo'n geval hebt? of alles wat afkomstig is van normale gebruikers?
toegevoegd de auteur Aristos, de bron
Alles is normaal, geen aanval. Er is voldoende RAM (16 GB, IIS gebruikt minder dan 1 GB, 3 GB is ongebruikt)
toegevoegd de auteur Sparhawk, de bron
toegevoegd de auteur gbjbaanb, de bron

4 antwoord

De eenvoudigste manier is om de app in productie te profileren. Ik weet niet zeker of dat mogelijk is in jouw geval. Sommige opties:

  • kijk in de logboeken en bekijk de duur van de aanvragen. Lange verzoeken laden waarschijnlijk het systeem in
  • Foutopsporing op afstand w3wp met Visual Studio en pauzeer de foutopsporing 10 keer om te kijken waar deze het meest stopt. Dat is de hot spot
  • Gebruik XPerf of PerfView om (beheerde) stapels vast te leggen. Dit heeft bijna geen invloed op de productieprestaties
1
toegevoegd

Ik vond een eenvoudige manier om te zien wat er op de server gebeurt. Toch is de professionele manier waarschijnlijk om een ​​profileergereedschap te gebruiken.

Wat heb ik gedaan? In IIS Console kunt u een lijst met alle huidige worker-threads krijgen en als u er een kiest, kunt u zien waar deze thread aan werkt. Dus ik was in staat om te zien dat de thread 100 aanvragen tegelijkertijd behandelde, 70 daarvan volgden dezelfde ajax-oproep.

De onmiddellijke oplossing was om de frequentie van die oproep te verminderen (van elke 10 tot elke 30 seconden). De volgende stap is om de aanroep aan de server verder te optimaliseren, omdat ik andere ajax-oproepen met dezelfde frequentie (elke 10 seconden) heb die bijna nooit in de lijst met actieve verzoeken zijn weergegeven omdat ze zo snel waren.

0
toegevoegd
Nu je een idee hebt wat je zoekt, bekijk dan de Eqatec profiler die ik in mijn antwoord noem. Ze hebben een gratis versie.
toegevoegd de auteur Steve Wortham, de bron

Waarschijnlijk de gemakkelijkste manier om dit te achterhalen is om New Relic op de server te installeren. De proef duurt 30 dagen, ik denk dat het je voldoende tijd moet geven om tot op de bodem uit te komen. Het toont u langlopende SQL-queries, .NET-methoden en zo ongeveer alles wat u maar kunt bedenken. Het maakt het heel eenvoudig om knelpunten te identificeren.


Trouwens, ik heb New Relic voorgesteld omdat het klinkt alsof je probleem zich in een productieomgeving bevindt. Nieuwe Relic is geen ongelooflijk gedetailleerde profiler. Het verzamelt voldoende informatie om behulpzaam te zijn, maar niet zozeer om de server te vertragen. Dat maakt het geschikt voor dit doel.

Als je het probleem echter in een ontwikkelomgeving zou kunnen reproduceren, zou je iets als de gratis Eqatec profiler kunnen proberen.

0
toegevoegd

Een goed uitgangspunt zou zijn om de ontwikkelingshulpmiddelen (F12 in IE/Chrome) in te schakelen en naar de tijdstippen onder het netwerktabblad te kijken. Dat toont je een waterval-achtig diagram voor hoe de pagina is geladen en zou je moeten helpen bij het identificeren van bijzonder traag ladende statische bestanden die verstandig naar een cdn kunnen worden verplaatst, onnodige verzoeken worden gedaan, hoeveel tijd wordt besteed aan het krijgen van de eigenlijke pagina zelf, etc.

Visualiseer daarna de applicatie met een performance profiler. Een goede profiler zoals ANTS Performance Profiler laat je kijken bij zaken als executietijd/hitaantallen voor verschillende methoden, evenals welke databasequery's worden uitgevoerd en hoe lang ze in beslag nemen. Een nieuwe versie van ANTS (momenteel in EAP ) groepeert die activiteit ook door http-aanvraag, zodat u kunt zien of specifieke pagina's moeten worden geoptimaliseerd of te vaak worden geraakt.

U doet er ook goed aan te controleren of caching werkt zoals u van plan bent, zodat gebruikers niet onnodig pagina's opnieuw aanvragen.

Er is ook een leuk artikel over de ASP.NET-prestaties dat u mogelijk wilt lezen op http://aspalliance.com/1533_ASPNET_Performance_Tips. 7 .

Disclaimer: ik werk voor Red Gate en dat maakt ANTS.

0
toegevoegd
Vanuit het oogpunt van de gebruiker is de site snel, dus de ontwikkelaarstools aan de browser helpen niet. Maar ja, ik zou een tool als ANTS gaan gebruiken. (of dotTrace :)) maar tot nu toe was ik niet zeker of en hoe ik dat op de productieserver moest gebruiken. Ik heb jaren geleden wat rondgezwommen op de ontwikkelingsserver, maar daar heb ik geen relevante gebruiksgegevens.
toegevoegd de auteur Sparhawk, de bron
Als vuistregel moet je proberen waar mogelijk profilering op productie te vermijden vanwege de extra invloed op de prestaties van een al zwaar beladen systeem. Dat gezegd hebbende, het is soms een noodzakelijk kwaad en in werkelijkheid doen mensen het met succes de hele tijd. Als je dit in de toekomst doet, kun je de 'Attach to Process' optie gebruiken om te voorkomen dat IIS opnieuw moet worden opgestart. U kunt ook een strategie voor lagere steekproeven gebruiken om de impact op de prestaties te verminderen: u wilt bijvoorbeeld de timing op lijnniveau in de productie vermijden, tenzij dat echt nodig is, terwijl de timing van de methoden waarschijnlijk goed is.
toegevoegd de auteur Ben Emmett, de bron