Resumé
I dag vil jeg tale om databaseforbindelsespuljer. For at være ærlig sagde jeg, at andepæren er meget stor. Fordi forbindelsespuljer er relativt svære at forstå sammenlignet med andre kapitler. Jeg vil gerne forklare det for dig i de mest populære sætninger, men det er ikke en nem opgave. Dog er forbindelsespuljer også et meget vigtigt videnspunkt, især ved udrulning af multi-brugerprogrammer. Derfor skal jeg ikke kun tale, men også tale grundigt. Gennem denne artikel vil du forstå det grundlæggende i connection pooling og hvordan det allerede udnyttes til at forbedre ydeevnen af din applikation.
Indholdsfortegnelse
Hvad er en forbindelsespulje?
Hvordan forbindelsespuljen fungerer
Lad os tale om nogle meget vigtige egenskaber ved forbindelsespuljer
Undtagelser og håndteringsmetoder for forbindelsespuljer
En måde at overvåge status på din forbindelse
Grundlæggende principper for effektiv brug af forbindelsespuljer
1. Hvad er en forbindelsespool?
I den forrige artikel, "ADO.NET You Must Know (4) Taste Connection Objects", har jeg understreget, at etablering af en databaseforbindelse er en meget tidskrævende (tidskrævende) og arbejdskrævende (ressourcekrævende) proces. Dette skyldes, at forbindelse til en databaseserver involverer flere langvarige processer: etablering af en fysisk kanal (såsom en socket eller navngivet pipeline), et indledende håndtryk med serveren, analyse af forbindelsesstrengsinformationen, at få serveren til at autentificere forbindelsen, køre en kontrol for at registrere sig i den aktuelle transaktion osv. Uanset hvorfor der findes en sådan mekanisme, er der altid en grund til at eksistere. Da det er så smertefuldt at skabe en ny forbindelse, hvorfor så ikke genbruge en eksisterende?
Faktisk giver ADO.NET os allerede en optimeringsmetode kaldet connection pooling. En forbindelsespulje er en sådan container: den rummer et vist antal fysiske forbindelser til databaseserveren. Derfor, når vi skal forbinde til databaseserveren, behøver vi kun at fjerne en fri forbindelse fra puljen (container) i stedet for at oprette en ny. Dette reducerer i høj grad overheaden ved at oprette forbindelse til databasen, hvilket forbedrer applikationens ydeevne.
PS:本来做了2张图片来描述连接池的，无奈公司装有监控软件，不能上传，所以只能等下次有时间上传了。
2. Hvordan forbindelsespuljen fungerer
2.1 Opret en forbindelsespulje
Det skal bemærkes, at forbindelsespuljer er klasse-følsomme. Det vil sige, at det samme applikationsdomæne kan have flere forskellige typer forbindelsespuljer på samme tid. Så hvordan identificeres forbindelsespuljer? I detaljer adskiller den sig ved signaturen, der udgør processen, applikationsdomænet, forbindelsesstrengen og Windows-identiteten (når integreret sikkerhed bruges). Dog identificeres den for samme applikationsdomæne generelt kun ved forbindelsesstrengen. Når en forbindelse åbnes, oprettes en ny forbindelsespool, hvis typesignaturen for stripforbindelsen ikke matcher typen af den eksisterende forbindelsespool. ellers oprettes der ingen ny forbindelsespool.
Et typisk eksempel på at skabe en forbindelse:
I ovenstående tilfælde oprettede jeg tre SqlConnection-objekter, men kun to forbindelsespuljer var nødvendige for at administrere dem. Pas på venner, I har måske allerede fundet ud af, at conn1 og conn3 har samme forbindelsesstreng, så de kan dele en forbindelsespool, mens conn2 og conn1 er forskellige fra conn3, så du skal oprette en ny forbindelsespool.
2.2 Allokering af inaktive forbindelser
Når en bruger opretter en forbindelsesforespørgsel eller kalder Open of a Connection-objektet, skal forbindelsespoolmanageren først finde en forbindelsespulje af den matchende type baseret på typesignaturen for forbindelsesforespørgslen og derefter forsøge at allokere en fri forbindelse. Detaljerne er som følger:
Hvis der er en tilgængelig forbindelse i puljen, returner forbindelsen.
Hvis alle forbindelser i poolen er udtømt, skal du oprette en ny forbindelse til poolen.
Hvis det maksimale antal forbindelser i puljen er nået, går anmodningen ind i ventekøen, indtil der er ledige forbindelser tilgængelige.
2.3 Fjern ugyldige forbindelser
Ugyldige forbindelser, det vil sige forbindelser, der ikke forbinder korrekt til databaseserveren. For forbindelsespuljer er antallet af forbindelser, der er lagret til databaseserveren, begrænset. Derfor, hvis ugyldige forbindelser ikke fjernes i tide, vil plads i forbindelsespuljen gå til spilde. Faktisk behøver du ikke bekymre dig, forbindelsespoolmanageren har håndteret disse problemer rigtig godt for os. Hvis en forbindelse er inaktiv i en længere periode, eller hvis den opdager, at forbindelsen til serveren er afbrudt, fjerner forbindelsespoolmanageren forbindelsen fra poolen.
2.4 Genanvend brugte forbindelser
Når vi er færdige med at bruge en forbindelse, bør vi lukke eller frigive den i tide, så forbindelsen kan returneres til poolen til genbrug. Vi kan lukke forbindelsen via Close or Disposose-metoden i Connection-objektet eller gennem using statement i C#.
3. Fortæl mig om nogle meget vigtige egenskaber
Adfærden af forbindelsespuljen kan styres af forbindelsesstrenge og omfatter hovedsageligt fire vigtige egenskaber:
Forbindelsestimeout: Tiden for forbindelsesanmodningen til at vente på timeout. Standarden er 15 sekunder i sekunder.
Maksimal poolstørrelse: Det maksimale antal forbindelser i forbindelsespoolen. Standardindstillingen er 100.
Min poolstørrelse: Det minimale antal forbindelser i forbindelsespoolen. Standarden er 0.
Pooling: 是否启用连接池。ADO.NET默认是启用连接池的，因此，你需要手动设置Pooling=false来禁用连接池。
Lad os tage et eksempel for at forstå egenskaberne ved forbindelsespuljen. Koden er som følger:
4. Undtagelser og håndteringsmetoder for forbindelsespoolen
Når en bruger åbner en forbindelse uden at lukke den korrekt eller rettidigt, udløser det ofte "forbindelseslækage"-problemet. Den lækkede forbindelse forbliver åben, indtil Dispose-metoden kaldes, og Garbage Collector (GC) lukker og frigiver forbindelsen. I modsætning til ADO skal ADO.NET manuelt lukke brugte forbindelser. En vigtig myte er, at forbindelsen er lukket, når det forbundne objekt er uden for det lokale omfang. Faktisk, når det er uden for scope, frigives kun forbindelsesobjektet, ikke forbindelsesressourcen. Lad os tage et eksempel først.
For at gøre resultaterne mere tydelige satte jeg specielt det maksimale antal forbindelser til 5, og timeout-tiden er 1 sekund. Efter løb opnås følgende resultater hurtigt.
Ud fra ovenstående resultater er det tydeligt, at der er en unormalitet i forbindelsen. Vi ved allerede, at det maksimale antal forbindelser i forbindelsespuljen er 5, og når den 6. forbindelse oprettes, er det nødvendigt at vente på forbindelsen, indtil den går i timeout, fordi det maksimale antal forbindelser i forbindelsespuljen har nået maksimum, og der ikke er nogen ledige forbindelser. Når timeout-tiden overskrides, vil forbindelsesundtagelsen nævnt ovenfor dukke op. Derfor må jeg endnu en gang understrege, at brugte forbindelser bør lukkes korrekt og frigives så hurtigt som muligt.
5. Metoder til overvågning af status for SQL Server-forbindelser
(1) Gennem aktivitetsmonitoren
Trin 1: Åbn MSSMS Manager og klik på ikonet "Activity Monitor".
Trin 2: I visningen Åbn Aktivitetsovervågning skal du klikke på fanen Processer.
Trin 3: Kør eksemplet i #4 Connection Pool Exceptions and Handling Methods, du kan se de 5 åbne forbindelser som vist i figuren nedenfor.
(2) Brug T-SQL-sætninger
Ligeledes kan vi ved at udføre systemlagret procedure sp_who også overvåge forbindelsens tilstand.
6. Grundlæggende principper for effektiv brug af forbindelsespuljer
At udnytte forbindelsespuljen godt vil i høj grad forbedre ydeevnen i din applikation. Tværtimod, hvis det bruges forkert, vil det ikke skade. Generelt bør følgende principper følges:
Anmod om en forbindelse så sent som muligt, og ophæv forbindelsen hurtigst muligt.
Når du lukker forbindelsen, skal du først lukke den relevante brugerdefinerede transaktion.
Sørg for og vedligehold mindst én åben forbindelse i forbindelsespuljen.
Prøv at undgå poolaffald. Dette omfatter hovedsageligt poolfragmentering genereret af integreret sikkerhed og poolfragmentering genereret ved brug af mange databaser.
Tip: Poolfragmentering er et almindeligt problem i mange webapplikationer, og applikationer kan skabe et stort antal pools, som først frigives, når processen afsluttes. På denne måde åbnes et stort antal forbindelser, hvilket optager meget hukommelse og resulterer i reduceret ydeevne.
|
Opslået på 17/09/2016 15.41.28
|
|
|
|
