Jeg elsker at ændre SQL Server-kode for at forbedre ydeevnen, men der er nogle gange scenarier, hvor selv efter at have justeret koden, indekserer og designe en brugeropgave fra applikationen, tager længere tid at fuldføre end den forventede slutbrugeroplevelse. Når dette sker, skal brugergrænsefladen enten vente på, at processen er fuldført, eller vi skal finde på en alternativ måde at håndtere opgaven på. Den asynkrone behandling leveret af Service Broker passer godt til mange af disse scenarier og gør det muligt at udføre baggrundsbehandling af den langvarige opgave separat fra brugergrænsefladen, hvilket giver brugeren mulighed for at fortsætte med at arbejde med det samme uden at vente på, at opgaven rent faktisk skal udføres . I løbet af mine næste par artikler håber jeg at skabe en serie om, hvordan du kan udnytte Service Broker med de passende forklaringer og kodeeksempler undervejs for at gøre det nemmere at udnytte Service Brokers muligheder uden implementeringsproblemer.
Metoder til at udføre asynkron behandling
Der er en række måder at håndtere en langvarig, men allerede afstemt proces. Applikationskoden kan også omskrives til at bruge en BackgroundWorker, baggrunden ThreadPool eller en manuelt skrevet trådbaseret løsning i .NET, der udfører handlingen asynkront. Dette giver dog mulighed for, at et ubegrænset antal af disse langvarige processer kan indsendes af ansøgningen, medmindre der udføres yderligere kodningsarbejde for at spore og begrænse antallet af aktive processer. Det betyder, at applikationen vil have en potentiel effekt på ydeevnen, eller at den under belastning rammer en grænse og vender tilbage til den tidligere ventetid, som vi oprindeligt forsøgte at forhindre.
Jeg har også set denne type processer omdannet til SQL Agent-job, der er knyttet til en tabel, der bruges til at gemme de oplysninger, der skal behandles. Så er jobbet enten planlagt til at køre periodisk eller startes af applikationen ved hjælp af sp_start_job når en ændring gemmes til behandling. Dette giver dog kun mulighed for en seriel udførelse af de langvarige processer, da SQL Agent ikke tillader, at et job køres flere gange samtidigt. Jobbet skal også designes til at håndtere scenarier, hvor flere rækker kommer ind i behandlingstabellen, så den korrekte behandlingsrækkefølge opstår, og efterfølgende indsendelser behandles separat.
Udnyttelse af Service Broker til asynkron behandling i SQL Server adresserer faktisk begrænsningerne med de tidligere nævnte metoder til håndtering af den asynkrone behandling. Mæglerimplementeringen tillader, at nye opgaver sættes i kø til asynkron behandling i baggrunden, og giver også mulighed for parallel bearbejdning af de opgaver, der er blevet sat i kø til en konfigureret grænse. Men i modsætning til applikationsniveauet, der skal vente, når grænsen er nået, sætter mæglerløsningen simpelthen den nye besked, der modtages, i kø og tillader den at blive behandlet, når en af de aktuelle behandlingsopgaver er afsluttet - dette tillader applikationen at fortsætte uden at vente.
Konfiguration af enkelt databaseservicemægler
Selvom Service Broker-konfigurationer kan blive komplekse, behøver du for simpel asynkron behandling kun at kende de grundlæggende begreber for at bygge en enkelt databasekonfiguration. En enkelt databasekonfiguration kræver kun:
- Oprettelse af to meddelelsestyper
- En til anmodning om asynkron behandling
- En for returmeddelelsen, når behandlingen er fuldført
- En kontrakt, der bruger meddelelsestyperne
- Definerer hvilken meddelelsestype der sendes af initiatortjenesten, og hvilken meddelelsestype der returneres af måltjenesten
- En kø-, service- og aktiveringsprocedure for målet
- Køen giver lagring af meddelelser sendt til måltjenesten af initiatortjenesten
- Aktiveringsproceduren automatiserer behandlingen af beskeder fra køen
- Returnerer en fuldført besked til initiatortjenesten, når den fuldfører behandlingen af en anmodet opgave
- Håndterer systemmeddelelsestyperne http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog og http://schemas.microsoft.com/SQL/ServiceBroker/Error
- En kø-, service- og aktiveringsprocedure for initiativtageren
- Køen giver lagring af beskeder sendt til tjenesten
- Aktiveringsproceduren er valgfri, men automatiserer behandlingen af beskeder fra køen
- Behandler den afsluttede besked til måltjenesten og afslutter samtalen
- Håndterer systemmeddelelsestyperne http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog og http://schemas.microsoft.com/SQL/ServiceBroker/Error
Ud over disse grundlæggende komponenter foretrækker jeg at bruge en indpakning lagret procedure til at oprette en samtale og sende beskeder mellem mæglertjenester for at holde koden ren og gøre det nemmere at skalere efter behov ved at implementere samtale genbrug eller 150 samtale tricket forklaret i SQLCAT-teamets hvidbog. For mange af de simple asynkrone behandlingskonfigurationer behøver disse præstationsjusteringsteknikker muligvis ikke implementeres. Men ved at bruge en wrapper-lagret procedure bliver det meget nemmere at ændre et enkelt punkt i koden i stedet for at ændre hver procedure, der sender en besked i fremtiden, hvis det skulle blive nødvendigt.
Hvis du ikke har givet Service Broker et kig, kan det være en alternativ metode til at udføre afkoblet behandling asynkront for at løse en række mulige scenarier. I mit næste indlæg vil vi gennemgå kildekoden for et eksempel på implementering og forklare, hvor specifikke ændringer skal foretages for at udnytte koden til asynkron behandling.