Det är den stora frågan. Dessutom en aktuell sådan. Idag hade jag inte tänkt beskriva någon smart kod utan istället berätta om skillnader i sätt att angripa prestandaproblem.
Det senaste året har jag på konferenser, seminarier och utbildningstillfällen ofta blivit hejad på och hamnat i en diskussion om vad som behövs göras i ett system för att snabba upp applikationen som använder SQL Server som lagringsplattform. Mitt första svar blir oftast “Det beror på om du är DBA eller utvecklare.”.
Nästan undantagslöst ser jag då ett frågetecken hos frågeställaren som nu undrar om jag är riktigt klok i huvudet. För han eller hon vill ju bara ha ett svar på hur deras applikation ska gå snabbare!
Jag ställer ofta en uppföljningsfråga i stil med “Vad är det du upplever som ett bekymmer?”. Och efter ett litet tag med halmstrån som långa väntetider, deadlocks och IO-problem brukar det utkristallisera sig vad egentligen är som upplevs som ett problem. De flesta professionella DBA-er och utvecklare vet om att det som brukarna upplever som ett bekymmer oftast bara är symptomet på det verkligen problemet medan de med mindre erfarenhet koncentrerar sig på fel saker. De sätter helt enkelt bara ett plåster på tummen när det egentligen hade behövts gips på armen. Eller i värsta fall en full hjärt-, lever-, lung- och njur-transplantation. Där slutar mina liknelser för i den verkliga världen går det ännu inte att transplantera en hjärna men i vår digitala värld går det att åstadkomma.
För enkelhetens skull påstår jag att DBA-er vill ha Performance Tuning och utvecklare vill ha Query Tuning. När man arbetar med SQL Server behöver man ta hänsyn både till hårdvara och mjukvara och som överallt annars är det svårt att se allt i svart eller vitt. Det finns nästan alltid en gråzon någonstans där mittemellan. Det finns en stark koppling mellan Performance Tuning och hårdvara samt mellan Query Tuning och mjukvara.
Jag ska fortsätta med en annan liknelse för att göra det enklare att förklara den egentliga skillnadan mellan de både metoderna att angripa ett prestandaproblem. För det är just prestandan som i nästan alla fall är den gemensamma nämnaren på de problem som brukarna rapporterar.
Vi börjar med Performance Tuning eller hårdvaran. Låt oss säga att vi ärver en gammal Bubbla från Volkswagen. Det finns folk som verkligen vet hur man ska pimpa den till att bli så kraftfull som möjligt inom ramen för en budget. Dessa personer är DBA-er. De är ansvariga för att hålla kolla på så att det finns olja i motorn, kylvätska och spolarvätska. De kollar lufttryck i däcken och inställningarna för tändstiften. De servar och reparerar bubblan för att den ska vara i så bra trim som möjligt.
De kan byta ut motorn till en starkare motor om de tycker det behövs eller sätta på vinterdäcken när det är påkallat. De kollar mätarställningen och tvättar bilen. Vad jag vill illustrera är att DBA-er har en stor uppgift att underhålla och se till så att bubblan uppför sig som man kan förvänta sig. DBA-er är experter på detta.
Då uppkommer den logiska frågan, vad gör då en utvecklare eller Query Tuning? Jo, dessa är experter på mjukvaran. Det är utvecklarna som vet hur man ska få bubblan att köra så fort som möjligt inom ramen för den hårdvara som existerar. Det är de som väljer körväg och hur mycket som behövs lutas i kurvorna. Pressar de mjukvaran för mycket så kommer hårdvaran inte att hinna med. Det är detta som händer är oerfarna utvecklare skriver dålig kod som i sin tur genererar alldeles för mycket IO eller använder för många processorer eller cores än nödvändigt. Även om det är DBA-erna som bestämt hur stor tanken ska vara, är det utvecklarna som kan se till så att bilen bara drar 0,1 liter per mil istället för 13 liter per mil. Det är utvecklarnas kod som avgör om bilen kommer att gå i 700 km/h eller i 15 km/h.
Jag har arbetat med databaser i över 20 år. En enda gång har lösningen på ett prestandaproblem varit att köpa mer hårdvara, eller uppgradera den befintliga hårdvaran. All gånger, utom den gången, har lösningen varit att skriva bättre kod eller skapa bättre design i applikationen. Det är också så att det är den lösningen som ger mest valuta för pengarna. Dubblar du antalet processorer, mängden minne och dubblar IO på ditt SAN, kan du förvänta dig att applikationen går dubbelt så snabbt, till en hög kostnad. Men spendera någon eller några timmar med kod och design, och du får en prestandaökning som kan räknas i 100 elller 10 000 000 gånger bättre prestanda.
Och någonstans här mittemellan ska dessa två yrkesgrupper komma överens. Utvecklarna kommer med önskemål om att “Servern är lite långsam, kan ni sätta i mer minne?” på vilken DBA-n antingen svarat “Javisst kan jag göra det” eller “Nej, det behövs inte. Du har lika mycket minne som Facebook och Google tillsammans. Använd det du har på ett bättre sätt.”.
Det är inte helt enkelt att få dessa två yrkesgrupper att samarbeta då de har olika fokus. Men en sak har de trots allt gemensamt och det är att göra brukarna nöjda inom ramen för det ledningen tillhandahåller. Och det är därför jag fortsätter med att undervisa, presentera och prata om prestandaförbättringar för att underlätta för brukaren, för det är ändå de som ser till så att vi alla har ett jobb att sköta.
Ha det kul tills nästa gång vi ses!
//Peter
