[C# 2.0] Performance meten

[DrDelete]

Ik wil wat performance gaan meten van bepaalde queries (SQLServerExpress2005), daarna wil ik deze informatie vastleggen voor analyse-doeleinden. Er wordt gebruik gemaakt van NHibernate.

Hoe kan ik dit het beste aanpakken ?

Opties:

1) Meetresultaten loggen in een reeds bestaand loggingscomponent
2) Meetresultaten loggen met WMI
3) ?

[Flard]

Met behulp van WMI krijg je variabelen die direct door SQL-server gevuld worden. Je hebt dan dus altijd 'eerstehands' informatie. SQL-Server biedt ook één hoop performance counters aan, dus qua performance meten moet dat wel lukken.

Met behulp van loggingscomponenten zou je het ook kunnen doen, al weet ik niet of je dan in je code wil gaan loggen, of dat je externe tools bedoelt. In je code loggen lijkt me niet helemaal heerlijk, en zorgt voor overhead. Externe tools zullen (lijkt me) veelal gebruik maken van de performance counters van SQL-Server.

Ik zou dus voor WMI/Performance Counters gaan. De truc zal echter worden uitzoeken wélke gegevens je nodig hebt, en hoe je ze moet combineren...

[whoami]

Je kan ook de SQL Profiler gebruiken, je trace resultaten saven, laten analyseren door de index tuning wizard, etc...

Wat wil je eigenlijk bekomen ? Wil je weten:
- of je queries die door NHibernate gegenereert worden performant genoeg zijn
- wil je weten of je de juiste indexen hebt liggen in je DB ?

[Flard]

Ja, als je SQL Profiler hebt kun je nog beter zoeken. Zeker in combinatie met je performance log met daarin je WMI-data. Maar volgens mij zit die niet bij de Express versie?

[DrDelete]

whoami schreef op dinsdag 22 mei 2007 @ 10:19:
Je kan ook de SQL Profiler gebruiken, je trace resultaten saven, laten analyseren door de index tuning wizard, etc...

Wat wil je eigenlijk bekomen ? Wil je weten:
- of je queries die door NHibernate gegenereert worden performant genoeg zijn
- wil je weten of je de juiste indexen hebt liggen in je DB ?

Er zijn bepaalde tabellen die behoorlijk gaan groeien. Daar heb ik een caching mechanisme voor bedacht. Daarvoor moet ik eerst een enkele waarde ophalen om een datum/tijd te krijgen, die vergelijk ik met de meest recente, als deze anders is dan haal ik de hele tabel op om de cache te updaten. Ik wil de performance meten van het ophalen van de enkele waarde (met een scalar query) en daarna de waarde van de hele lijst.

Het gaat me dus voornamelijk om de performance van NHibernate te meten.

[ Voor 4% gewijzigd door DrDelete op 22-05-2007 10:55 ]

[EfBe]

Val niet in de valkuil "Ik heb een cache dus is het sneller". Dat is een myth, caches zijn veelal trager dan geen cache, omdat je de cache moet bijhouden.

Ik zou met een profiler (.NET profiler + sqlserver profiler) een enkele sectie die traag is profilen, dus .NET code en db code. Daarna bekijken wat je moet optimaliseren. Geen idee of je nhibernate de opdracht kunt geven om een switch van joins naar subqueries te maken of vice versa, dat wil nog wel eens helpen.

Caches gebruiken klinkt leuk, maar behalve in de situatie dat je bottleneck het netwerk is, is er geen reden tot het gebruik van een cache mbt performance.

[DrDelete]

EfBe schreef op dinsdag 22 mei 2007 @ 13:52:
Val niet in de valkuil "Ik heb een cache dus is het sneller". Dat is een myth, caches zijn veelal trager dan geen cache, omdat je de cache moet bijhouden.

Ik zou met een profiler (.NET profiler + sqlserver profiler) een enkele sectie die traag is profilen, dus .NET code en db code. Daarna bekijken wat je moet optimaliseren. Geen idee of je nhibernate de opdracht kunt geven om een switch van joins naar subqueries te maken of vice versa, dat wil nog wel eens helpen.

Caches gebruiken klinkt leuk, maar behalve in de situatie dat je bottleneck het netwerk is, is er geen reden tot het gebruik van een cache mbt performance.

De inhoud van die grote tabellen worden gebruikt in plots(grafieken). De gebruiker kan met een combobox snel switchen naar verschillende items. Per item wordt een complete plot gevuld en dan is het handig dat je snel een in-memory cache hebt zonder dat je toegang naar een DB hoeft te hebben.