[.NET] Performance analysis

[Sybr_E-N]

Op dit moment ben ik nogal veel bezig met analyseren van bestaande webapplicaties op hun performance. Kortom het uit zoeken waarom de webserver regelmatig volledig dichtklapt en waar zich het probleem bevindt (in de source code).

Ik maak zelf onderscheid in 3 zaken: Database Server, General Performance, Coding style

Database Server
Hieronder valt bij mij ook bijvoorbeeld een slecht genormaliseerde database, langzame queries (in stored procedures), verkeerde indexen.

General Performance
Hierbij denk ik dan vooral aan zaken zoals het niet vrijgeven van de gebruikte resources, denk bijvoorbeeld een Sql Connection object. Waardoor als het even tegen zit honderden zoniet duizenden connecties naar de database onnodig open blijven staan. Maar ook het niet disposen of direct op null zetten van objecten die je echt niet meer nodig hebt, zodat de GC ze zo snel mogelijk uit je geheugen kan verwijderen en dus je geheugen over een langere periode onnodig vol blijft.

Coding style
Behalve ontwerp fouten, spaghetticode, verkeerde benamingen, inefficiënte string concatenation, ongeoorloofd gebruik van try-catch, slecht geïmplementeerde eigen geschreven authorisatie-mechanismes (En die van .NET niet of half gebruiken.)

Gebruikte tools (tot nu toe)
Microsoft FxCop
Met behulp van deze applicatie is het mogelijk om allerlei performance, coding style, zaken op te laten zoeken en aan te pakken. Dit programma werkt met zogenaamde rules, het zoekt bijvoorbeeld naar inconsistente naamgeving - niet gebruikte variabelen - verkeerde (algemene) exception's afvangen - globalization toepassen - te pas en te onpas allerlei objecten lopen aanmaken.

Microsoft Application test center
Hiermee heb ik een aantal stress test's uitgevoerd en enkele performance counters gelogd. Hiermee kon ik een x aantal concurrent gebruikers op de website simuleren. Heb hier nog maar even kort naar gekeken.

Ook heb ik gekeken naar, Microsoft CLR Debugger en CLR Profiler. Ik vond het nogal moeilijk om uit de gegevens van vooral de laatstgenoemde bruikbare informatie te halen. Het geeft een heleboel leuke grafieken weer met info over de verschillende objecten.

Nu denk je misschien dat de voorbeelden die ik hierboven heb gegeven wel meevallen, maar als je al die voorbeelden in 1 applicatie tegenkomt... mag je 3x raden wat er gebeurt.

Nu is dit voor mij redelijk nieuw, al helemaal in .NET (webapplicaties). Nu vroeg ik mij af, hoe pakken jullie dit aan? Wat voor methodieken passen jullie toen? Welke tools zijn hiervoor handig?

[Alarmnummer]

Je zou misschien eens kunnen kijken naar dotTrace Profiler. Ik heb er zelf geen ervaring mee (ook weinig met het .NET platform).

[pjvandesande]

Alarmnummer schreef op maandag 09 januari 2006 @ 11:39:
Je zou misschien eens kunnen kijken naar dotTrace Profiler. Ik heb er zelf geen ervaring mee (ook weinig met het .NET platform).

De profiler van Jetbrains mist nog een aantal dingen. Je kunt niet makkelijk door statements van je eigen source bladeren en tegelijkertijd je results zien.

Als ik je 1 profiler wel kan aanbevelen is het wel die van Redgate: http://www.red-gate.com/products/ANTS_Profiler/index.htm

[EfBe]

allereerst METEN, dan profilen.

Dus eerst de windows performance monitor openen, en tellers toevoegen die betrekking hebben op .NET, sqlserver etc. Dan kun je zien waar wat fout gaat. Bv of er memory gelekt wordt, of dat er veel queries uitgevoerd worden.

Verder is code paths volgen erg belangrijk. Als je bv je applicatie gebruikt als een normale gebruiker en je constateert dat het openen van een edit scherm voor een element traag is, volg dan het pad vanaf de editor totaan de database en terug en MEET ieder onderdeel apart. Alleen dan kun je constateren waar precies veel tijd gespendeerd wordt. Je kunt nl. wel procs gaan optimaliseren maar als de meeste tijd verstookt wordt in het omzetten van een datareader in een setje objects, dan ben je verkeerd bezig.

[Alarmnummer]

EfBe schreef op maandag 09 januari 2006 @ 12:49:
allereerst METEN, dan profilen.

Onzin: met een profiler krijg je namelijk meetgegevens. Je kunt gerust beginnen met profiler en daar achterhalen waar de oorzaak van het probleem zit (je weet in welke stukken de meeste tijd komt te zitten). Dus op basis van deze informatie zou je eens kunnen kijken bij bv de db als blijkt dat je 80% van de tijd spendeert aan een db call.

[ Voor 15% gewijzigd door Alarmnummer op 09-01-2006 14:13 ]

[EfBe]

Alarmnummer schreef op maandag 09 januari 2006 @ 13:43:
[...]

Onzin: met een profiler krijg je namelijk meetgegevens. Je kunt gerust beginnen met profiler en daar achterhalen waar de oorzaak van het probleem zit (je weet in welke stukken de meeste tijd komt te zitten). Dus op basis van deze informatie zou je eens kunnen kijken bij bv de db als blijkt dat je 80% van de tijd spendeert aan een db call.

Nee geen onzin. Ga jij maar eens uitzoeken waarom je grote webapplicatie traag is of memory leakt. Ga jij dan profilen? Veel plezier . Ik zou echt beginnen met performance counters want dan heb je tenminste inzicht in waar de bottlenecks zitten en DAN kun je gaan profilen, nl. die bottleneck onderdelen en ben je dus gericht aan het profilen.

[Alarmnummer]

EfBe schreef op maandag 09 januari 2006 @ 15:05:
[...]

Nee geen onzin. Ga jij maar eens uitzoeken waarom je grote webapplicatie traag is of memory leakt. Ga jij dan profilen? Veel plezier .

Waarschijnlijk hebben we een verschil van mening over wat een profiler doet. Ik kan in een profiler exact zien in welke methodes de tijd komt te zitten. Als ik dus echt geen flauw idee heb waar de traagheid door veroorzaak wordt, dan wil ik eerst een lijst met methodes die verantwoordelijk zijn voor de tijdkosten. Als ik zie dat er 80% van de tijd in een webservice call wordt gestoken hoef ik nergens anders te kijken. De profiler is dus voor mij de allereerste stap om te achterhalen waar de problemen zitten.

Ik zou echt beginnen met performance counters want dan heb je tenminste inzicht in waar de bottlenecks zitten en DAN kun je gaan profilen, nl. die bottleneck onderdelen en ben je dus gericht aan het profilen.

Je bent ook gericht bezig met mijn aanpak. Je achterhaalt eerst waar het ongeveer zit en dan ga je daar dieper op onderzoek uit.

[EfBe]

Dat werkt alleen als je complete applicatie in 1 enkele taal is gemaakt. Als de bottleneck in de database blijkt te zitten ben jij aan het profilen voor niets en vice versa: als je je database profiler gaat draaien terwijl de bottleneck in de applicatie zit dan zit je te zoeken naar iets wat je niet zult vinden, dat was eigenlijk mn punt .

[Luuk1983]

Om te beginnen is het afvangen van veelvoorkomende fouten natuurlijk erg handig. Als voorbeeld: wij hebben een database classe om database connecties te openen en sluiten en dergelijke. Elke keer als de connectie door de garbage collector wordt wegegooid krijgt de beheerder een mailtje met de foutmelding, laatste query etc. Hiermee kunnen we dus altijd zien of alle connecties, readers etc goed worden afgesloten. Ik denk dat je met wat creativiteit meer van dit soort constructies kunt bedenken. Veel zijn het de databaseconnecties die niet goed gesloten worden die performance nogal negatief beinvloed.

[Alarmnummer]

EfBe schreef op maandag 09 januari 2006 @ 16:02:
Als de bottleneck in de database blijkt te zitten ben jij aan het profilen voor niets

Dan zit hier ons menings verschil. Ik krijg in mijn java profiler voor mijn java applicatie ook te zien dat de db de bottleneck is. Ik zie gewoon dat er bv 80% van de tijd komt te zitten in een update call dus ik weet dat het probleem dan in de db moet zitten.

[joepP]

Je kan niet altijd goed profilen. Soms komt de ellende alleen aan het licht onder zware load, en dat is lastig simuleren. In een live productieomgeving kan je ook niet zomaar alles profilen, zeker niet als de problemen vooral aan de serverkant liggen, of als je te maken hebt met veel losse componenten.

[Verwijderd]

Ik moet ook zeggen, ik gebruik ook nooit die windows performance monitor. Pak toch ook echt een profiler erbij die me eigenlijk nog nooit in de steek heeft gelaten en altijd direct een indicatie gaf van het probleem.

[Verwijderd]

PerfMon is de tool die ik als eerste start.
Het is ook de tool die het minste impact geeft op je applicatie tijdens het meten. Profilers beinvloeden de performance vaak negatief.

Vergeet niet dat naast .Net ook SqlServer een profiler heeft.
Naast de tools die je al noemt is de ITW (Sql7/8) of DTA (Sql9) een simpele tool die je erg kan helpen.