LINQ og SQL Server Performance Tuning SQL Server 2008 database beste praksis?

stemmer
1

Mitt spørsmål er hva som er beste praksis for å optimalisere ytelsen ved hjelp av LINQ for SQL og ytelse er responstiden ut i brukergrensesnittet.

Akkurat nå har jeg noen salgsdata i en SQL Server 2008 database, og jeg vise disse dataene (MAT, årlig, i ulike segmenter, vekst i segmentet, prosent av markedsvekst ,,,,) i diagrammer i en ASP.NET applikasjon ved hjelp av LINQ for SQL å konstruerer Iquerable uttrykk som er utført

Jeg ser utfordringen som jeg har en database og brukes LINQ å konstruere alle spørsmål, og jeg har ingen kontroll på hva SQL er opprettet (jeg kan spore den, men ,,,,), og jeg bruker ikke lagrede prosedyrer så hvordan mine data hentes er som en svart boks.

Akkurat nå kjører jeg noen enhet tester og manuell test programmet og bruke Databasse Engine Tuning Advisor hva indekser etc for å skape ....

Publisert på 30/12/2009 klokken 01:15
kilden bruker
På andre språk...                            


2 svar

stemmer
2

I tillegg til det, vil jeg vanligvis bruker både SQL Profiler og CLR profiler med noen simulerte brukere på en stor-ish datasett, og se etter langvarig søk og / eller langvarige samtaler gjennom Context (som kan bety flere rundreiser skjer under dyna). Min personlige preferanse er også å deaktivere utsatt lasting og objekt sporing på alle mine datacontexts som standard, så jeg må melde seg til flere rundreiser i de fleste tilfeller. Selv om du ikke kan direkte påvirke SQL som er generert, kan du være forsiktig med LoadWith / AssociateWith og sørg for at du ikke henter forferdelig store / ineffektive resultatsett, og bryte opp spørsmål som har massevis av dyre tiltrer (noen ganger flere runde -trips er billigere enn mondo tiltrer på store tabeller).

Det handler om måle- bruk det verktøy du kan få hendene på.

Svarte 30/12/2009 kl. 01:22
kilden bruker

stemmer
1

Profilering, profilering, profilering. :)

Mål ikke bare timings, men ta hensyn til I / O i tillegg. Et ofte utført spørring som er I / O intensiv kan kjøre fort på grunn av caching, men kan i sin tur ha en negativ effekt på den totale db-server ytelse siden det vil være mindre ressurser tilgjengelig for andre spørsmål.

Som du sier, kan L2S være litt av en svart boks, så du må prøve å gjenskape alle scenarier og / eller profil mens programmet er i bruk av reelle brukere. Deretter bruke denne til 1) finpusse spørsmål 2) legge indekser 3) foreta andre endringer som trengs for å få den ytelsen du trenger.

Jeg har en profilering verktøy laget spesielt for Linq til SQL for å gjøre det litt 'mindre svart boks' - det tillater deg å gjøre runtime profilering mens knytte de genererte spørsmål til koden (call stack) som resulterte i en bestemt spørring utføres. Du kan laste det ned og få en gratis prøvelisens på http://www.huagati.com/L2SProfiler/

Bakgrunnen grunnen til min profiler er skissert i litt mer detalj her: http://huagati.blogspot.com/2009/06/profiling-linq-to-sql-applications.html

... og noen avanserte profilering alternativer er dekket her: http://huagati.blogspot.com/2009/08/walkthrough-of-newest-filters-and.html


En annen ting som kan hjelpe hvis du har en masse tabeller med mye kolonner er å få indeksen info inn i koden editor. Dette gjøres ved å legge xml doc-kommentarer med at info til foretakets klasser og medlems egenskaper; at informasjon vises deretter i VS kode redaktørens verktøytips:

kode editor verktøytips som viser xml doccomments for L2S foretakets klasser, medlemsegenskaper etc

... den måten kan du se allerede mens du skriver spørringer hvis det er en indeks som dekker kolonnen (e) som brukes i hvor klausuler etc. For å unngå å måtte skrive alt dette i, har jeg laget et verktøy for det også. Se 'update dokumentasjon funksjonen i http://www.huagati.com/dbmltools/

Svarte 30/12/2009 kl. 01:38
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more