Metodtips för prestandamätning för Azure Database for MySQL – flexibel server

Artikel
2024-12-18

Prestanda är ett kännetecken för alla program och det är viktigt att definiera en tydlig strategi för att analysera och utvärdera hur en databas presterar när du hanterar ett programs krav på variabel arbetsbelastning.

Den här artikeln innehåller överväganden och metodtips för att köra prestandamått mot flexibel Azure Database for MySQL-server.

Prestandatest

Benchmarking av prestanda för relationsdatabassystem syntetiskt kan till en början verka som en trivial uppgift. Det är trots allt relativt enkelt att utvärdera prestanda för enskilda frågor manuellt och till och med att starta enkla syntetiska tester med något av de tillgängliga benchmarking-verktygen. Dessa typer av tester tar lite tid och ger snabbt lätt att förstå resultat.

Att jämföra prestanda för verkliga produktionssystem kräver dock mycket ytterligare arbete. Det är inte lätt att utforma, implementera och köra tester som verkligen är representativa för produktionsarbetsbelastningar. Det är ännu svårare att fatta beslut om produktionsdatastackar baserat på resultatet av en serie prestandamått som utförs i en isolerad miljö.

Metoder för prestandatestning

Syntetiska riktmärken

Syntetisk testning är utformat för att belasta ett databassystem med hjälp av artificiella arbetsbelastningsexempel som simulerar repeterbara resultat i en databasmiljö. Detta gör det möjligt för kunder att göra jämförelser mellan flera miljöer för att mäta rätt databasresurs för sina produktionsdistributioner.

Det finns flera fördelar med att använda syntetiska riktmärken. De kan till exempel:

Är förutsägbara, repeterbara och tillåter selektiv testning (till exempel skrivskyddade tester, skrivskyddade tester, en blandning av skriv- och lästester och riktade tester mot en tabell).
Ange övergripande resultat som kan representeras med enkla mått (till exempel "frågor per sekund", "transaktioner per sekund" osv.).
Kräver inte program- eller miljöspecifik kunskap för att skapa och köra.
Kan utföras snabbt och med lite eller ingen förberedelse. Det finns dock även tillhörande nackdelar i det här fallet:
Exempel på artificiella arbetsbelastningar är inte representativa för verklig programtrafik.
Resultat kan inte användas för att exakt förutsäga prestanda för produktionsarbetsbelastningar.
De kanske inte exponerar produktspecifika prestandaegenskaper när de används för att testa olika databasprodukter.
Det är enkelt att utföra testerna felaktigt och ge resultat som är ännu mindre representativa.

Syntetiska tester är praktiska för snabba jämförelser mellan produkter. Du kan också använda dem för att implementera mekanismer för kontinuerlig prestandaövervakning. Du kan till exempel köra en testsvit varje helg för att verifiera baslinjeprestandan för databassystemet, identifiera avvikelser och förutsäga långsiktiga prestandamönster (till exempel försämrad frågesvarstid till följd av datatillväxt).

Verkliga riktmärken

Med verkliga tester presenteras databasen med arbetsbelastningsexempel som liknar produktionstrafik. Du kan uppnå detta direkt genom att spela upp en logg med produktionsfrågor och mäta databasprestanda. Du kan också uppnå detta indirekt genom att köra testet på programnivå och mäta programprestanda på en viss databasserver.

Det finns flera fördelar med att använda verkliga riktmärken, eftersom de:

Ge en korrekt vy över systemprestanda i verkliga produktionsförhållanden.
kan avslöja program- eller databasspecifika egenskaper som förenklade syntetiska tester inte skulle göra.
Hjälp med kapacitetsplanering som rör programtillväxt.

Det finns också vissa nackdelar: Verkliga riktmärken:

Är svåra att utforma och köra.
Måste bibehållas för att säkerställa relevans när programmet utvecklas.
Ange resultat som endast är meningsfulla i kontexten för ett visst program.

När du förbereder dig för en större förändring i din miljö, t.ex. när du distribuerar en ny databasprodukt, rekommenderar vi att du använder verkliga tester. I en sådan situation är en omfattande benchmark-körning med faktisk produktionsarbetsbelastning till stor hjälp. Det ger inte bara korrekta resultat som du kan lita på, utan även ta bort eller åtminstone avsevärt minska antalet "okända" om systemet.

Välj "rätt" testmetod

Den "rätta" testmetoden för dina syften beror helt och hållet på målet med testningen.

Om du snabbt vill jämföra olika databasprodukter med hjälp av exempel på artificiella data och arbetsbelastningar kan du på ett säkert sätt använda ett befintligt benchmark-program som genererar data och kör testet åt dig.

Om du vill utvärdera prestandan för ett faktiskt program som du tänker köra på en ny databasprodukt bör du utföra verkliga benchmark-tester. Varje program har en unik uppsättning krav och prestandaegenskaper, och det föreslås att du inkluderar verklig benchmark-testning i alla prestandautvärderingar.

Riktlinjer för att förbereda och köra syntetiska och verkliga riktmärken finns i följande avsnitt senare i det här inlägget:

Förbereda och köra syntetiska tester
Förbereda och köra verkliga tester

Metodtips för prestandatestning

Serverspecifika rekommendationer

Serverstorlek

När du startar flexibla Azure Database for MySQL-serverinstanser för att utföra benchmarking använder du en flexibel Azure Database for MySQL-serverinstansnivå, SKU och instansantal som matchar din aktuella databasmiljö.

Till exempel:

Om den aktuella servern har åtta CPU-kärnor och 64 GB minne är det bäst att välja en instans baserat på Standard_E8ds_v4 SKU.
Om din aktuella databasmiljö använder Skrivskyddade repliker använder du Azure Database for MySQL– flexibla serverläsningsrepliker.

Beroende på resultatet av benchmark-testningen kan du välja att använda olika instansstorlekar och antal i produktion. Det är dock fortfarande en bra idé att se till att de första specifikationerna för testinstanser ligger nära dina aktuella serverspecifikationer för att ge en mer exakt jämförelse av "äpplen till äpplen".

Serverkonfiguration

Om programmet/riktmärket kräver att vissa databasfunktioner är aktiverade justerar du serverparametrarna därefter innan du kör benchmark-testet. Du kan till exempel behöva:

Ange en nondefault-servertidszon.
Ange en anpassad parameter för "max_connections" om standardvärdet inte räcker.
Konfigurera trådpoolen om din flexibla Azure Database for MySQL-serverinstans kör version 8.0.
Aktivera långsamma frågeloggar om du förväntar dig att använda dem i produktion så att du kan analysera flaskhalsfrågor.

Andra parametrar, till exempel de som rör storleken på olika databasbuffertar och cacheminnen, är redan förinställda i Azure Database for MySQL – flexibel server och du kan först låta dem vara inställda på sina standardvärden. Även om du kan ändra dem är det bäst att undvika att göra ändringar i serverparametern om inte prestandamåtten visar att en viss ändring faktiskt förbättrar prestandan.

När du utför tester som jämför en flexibel Azure Database for MySQL-server med andra databasprodukter måste du aktivera alla funktioner som du förväntar dig att använda i produktion i dina testdatabaser. Om du till exempel inte aktiverar zonredundant HA, säkerhetskopior och läsrepliker i testmiljön kanske dina resultat inte korrekt återspeglar verkliga prestanda.

Klientspecifika rekommendationer

Alla prestandamått omfattar användning av en klient, så oavsett din valda benchmarkingmetod bör du överväga följande rekommendationer på klientsidan.

Kontrollera att klientinstanser finns i samma virtuella Azure-nätverk (VNet) som den flexibla Serverinstansen för Azure Database for MySQL som du testar. För svarstidskänsliga program är det bra att placera klientinstanser i samma tillgänglighetszon (AZ) som databasservern.
Om ett produktionsprogram förväntas köras på flera instanser (till exempel en appserverflotta bakom en lastbalanserare) är det en bra idé att använda flera klientinstanser när du utför prestandamåttet.
Se till att alla klientinstanser har tillräcklig beräknings-, minnes-, I/O- och nätverkskapacitet för att hantera riktmärket. Med andra ord måste klienterna kunna skapa begäranden snabbare än databasmotorn kan hantera dem. Alla operativsystem tillhandahåller diagnostikverktyg (till exempel "top", "htop", "dstat" eller "iostat" i Linux) som kan hjälpa dig att diagnostisera resursanvändning på klientinstanser. Vi rekommenderar att du använder dessa verktyg och ser till att alla klientinstanser alltid har extra PROCESSOR-, minnes-, nätverks- och I/O-kapacitet medan benchmark körs.

Även med en stor SKU kanske en enskild klientinstans inte alltid kan generera begäranden tillräckligt snabbt för att mätta databasen. Beroende på testkonfigurationen kan Azure Database for MySQL– flexibel server hantera hundratusentals läs-/skrivbegäranden per sekund, vilket kan vara mer än vad en enskild klient kan hantera. För att undvika konkurrens på klientsidan under tunga prestandatester är det därför vanligt att köra ett riktmärke från flera klientinstanser parallellt.

Viktigt!

Om du jämför ditt program med ett trafikgeneratorskript eller verktyg från tredje part (till exempel Apache Benchmark, Apache JMeter eller Siege) bör du också utvärdera den instans där verktyget körs med hjälp av rekommendationerna som beskrevs tidigare.

Förbereda och köra syntetiska tester

Syntetiska benchmarking-verktyg som sysbench är enkla att installera och köra, men de kräver vanligtvis en viss grad av konfiguration och justering innan ett givet riktmärke kan uppnå optimala resultat.

Antal tabeller och storlek

Antalet och storleken på tabeller som genereras före benchmarking bör vara stora. Till exempel är det osannolikt att tester som utförs på en enda tabell med 100 000 rader ger användbara resultat eftersom den här datamängden sannolikt är mindre än praktiskt taget alla verkliga databaser. Som jämförelse kan ett riktmärke med flera tabeller (till exempel 10–25) med 5 miljoner rader vardera vara en mer realistisk representation av realtidsarbetsbelastningen.

Testläge

Med de flesta benchmark-verktyg (inklusive den populära sysbench) kan du definiera vilken typ av arbetsbelastning som du vill köra mot servern. Verktyget kan till exempel generera:

Skrivskyddade frågor med identisk syntax men olika parametrar.
Skrivskyddade frågor av olika typer (punktval, intervallval, val med sortering osv.).
Skrivskyddade instruktioner som ändrar enskilda rader eller radintervall.
En blandning av läs-/skrivinstruktioner.

Du kan använda skrivskyddade eller skrivskyddade arbetsbelastningar om du vill testa databasens prestanda och skalbarhet i dessa specifika scenarier. Ett representativt riktmärke bör dock vanligtvis innehålla en bra blandning av läs-/skrivinstruktioner, eftersom detta är den typ av arbetsbelastning som de flesta OLTP-databaser måste hantera.

Samtidighetsnivå

Samtidighetsnivån är antalet trådar som körs samtidigt mot databasen. De flesta benchmark-verktyg använder en enda tråd som standard, som inte är representativ för verkliga databasmiljöer, eftersom databaser sällan används av en enskild klient i taget.

Om du vill testa den teoretiska toppprestandan för en databas använder du följande process:

Kör flera tester med olika antal trådar för varje test. Börja till exempel med 32 trådar och öka sedan antalet trådar för varje efterföljande test (64, 128, 256 och så vidare).
Fortsätt att öka antalet trådar tills databasens prestanda stabiliseras – det här är din högsta teoretiska prestanda.
När du fastställer att databasprestandan slutar öka på en viss samtidighetsnivå kan du fortfarande försöka öka antalet trådar ett par gånger till, vilket visar om prestandan förblir stabil eller börjar försämras. Mer information finns i blogginlägget Benchmarking Azure Database for MySQL – Flexibel server med Sysbench.

Förbereda och köra verkliga tester

Varje program är unikt när det gäller dataegenskaper och prestandakrav. Därför är det svårt att komma fram till en enda universell lista med steg som räcker för att förbereda och köra ett representativt, verkligt riktmärke i en godtycklig databasmiljö.

De idéer som presenteras i det här avsnittet är avsedda att göra prestandatestningsprojekt lite enklare.

Förbereda testdata

Innan du utför prestandamått mot flexibel Azure Database for MySQL-server måste du se till att servern är ifylld med ett representativt exempel på din produktionsdatauppsättning.

Använd när det är möjligt en fullständig kopia av produktionsuppsättningen. När detta inte är möjligt kan du använda följande förslag för att avgöra vilka delar av data du alltid ska inkludera och vilka data du kan utelämna.

Testservern måste innehålla alla objekt (dvs. scheman, tabeller, funktioner och procedurer) som används direkt av riktmärket. Varje tabell ska vara helt ifylld, det vill ex. den ska innehålla alla rader som den innehåller i produktion. Om tabellerna inte är helt ifyllda (till exempel innehåller de bara ett litet urval av raduppsättningen) är prestandaresultatet inte representativt.
Exkludera tabeller som används av produktionsprogram men som inte ingår i kontinuerlig driftstrafik. Om en databas till exempel innehåller en live-, driftdatauppsättning och historiska data som används för analys, kanske historiska data inte krävs för att köra benchmarks.
Fyll i alla tabeller som du kopierar till testservern med verkliga produktionsdata i stället för artificiella, programmatiskt genererade exempel.

Designa programriktmärken

Den övergripande processen för att utföra programriktmärken är följande:

Skapa en flexibel Azure Database for MySQL-serverinstans och fyll i den med en kopia av dina produktionsdata.
Distribuera en kopia av programmet i Azure.
Konfigurera programmet så att det använder den flexibla serverinstansen Azure Database for MySQL.
Kör belastningstester mot programmet och utvärdera resultaten.

Den här metoden är främst användbar när du enkelt kan distribuera en kopia av ditt program i Azure. Det gör att du kan utföra prestandautvärdering på det mest noggranna och korrekta sättet, men det finns fortfarande vissa rekommendationer att tänka på.

Verktyget som används för att generera programtrafik måste kunna generera en blandning av begäranden som är representativa för din produktionsarbetsbelastning. Testa till exempel inte genom att upprepade gånger komma åt samma program-URL, eftersom detta sannolikt inte är representativt för hur dina klienter använder programmet i verkligheten.
Poolen med klient- och programinstanser måste vara tillräckligt kraftfull för att generera begäranden, hantera dem och ta emot svar från databasen utan att införa några flaskhalsar.
Samtidighetsnivån (antalet parallella begäranden som genereras av benchmark-verktyget) bör matcha eller något överskrida den förväntade högsta samtidighetsnivån som observerats i ditt program.

Designa databasmått

Om du inte enkelt kan distribuera en kopia av ditt program i Azure måste du utföra prestandamåttet genom att köra SQL-instruktioner direkt mot databasen. Använd följande metod på hög nivå för att åstadkomma detta:

Identifiera DE SQL-instruktioner som oftast visas i din produktionsarbetsbelastning.
Baserat på den information som samlas in i det första steget förbereder du ett stort exempel på SQL-instruktioner som ska testas.
Skapa en flexibel Azure Database for MySQL-servernod och fyll i den med en kopia av dina produktionsdata.
Starta azure-klientinstanser (VM) i Azure.
Från de virtuella datorerna kör du SQL-arbetsbelastningsexemplet mot din flexibla Azure Database for MySQL-serverinstans och utvärderar resultatet.

Det finns två huvudsakliga metoder för att generera testnyttolasten (SQL-instruktionsexempel):

Observera/registrera SQL-trafiken som inträffar i din aktuella databas och generera sedan SQL-exempel baserat på dessa observationer. Mer information om hur du registrerar frågetrafik med hjälp av en kombination av granskningsloggar och långsam frågeloggning i Azure Database for MySQL – flexibel server.
Använd faktiska frågeloggar som nyttolast. Verktyg från tredje part som "Percona-uppspelning" kan generera arbetsbelastningar med flera trådar baserat på MySQL Slow Query Logs.

Om du bestämmer dig för att generera SQL-exempel manuellt måste du se till att exemplet innehåller:

Ett tillräckligt stort antal unika instruktioner.

Exempel: Om du fastställer att produktionsarbetsbelastningen använder 15 huvudtyper av instruktioner räcker det inte för att exemplet ska innehålla totalt 15 -instruktioner (en per typ). För ett så litet exempel skulle databasen enkelt cachelagras de data som krävs i minnet, vilket gör riktmärket icke-representativt. Ange i stället ett stort frågeexempel för varje instruktionstyp och använd följande ytterligare rekommendationer.
Instruktioner av olika typer i rätt proportioner.

Exempel: Om du fastställer att din produktionsarbetsbelastning använder 12 typer av instruktioner är det troligt att vissa typer av instruktioner visas oftare än andra. Exemplet bör återspegla dessa proportioner: om fråga A visas 10 gånger oftare än fråga B i produktionsarbetsbelastningen bör den också visas 10 gånger oftare i exemplet.
Frågeparametrar som är realistiskt randomiserade.

Om du har följt tidigare rekommendationer och frågeexemplet innehåller grupper av frågor av samma typ/syntax bör parametrarna för sådana frågor randomiseras. Om exemplet innehåller en miljon frågor av samma typ och alla är identiska (inklusive parametrar i WHERE-villkor) cachelagras de data som krävs i databasminnet, vilket gör benchmark-referensvärdet icke-representativt.
En instruktionskörningsordning som är realistiskt randomiserad.

Om du följer de tidigare rekommendationerna och testnyttolasten innehåller många frågor av olika slag bör du köra dessa frågor i en realistisk ordning. Exemplet kan till exempel innehålla 10 miljoner SELECT och 1 miljon UPPDATERINGAR. I sådana fall kanske det inte är det bästa valet att köra alla SELECT innan alla UPDATEs eftersom det förmodligen inte är så programmet kör frågor i verkligheten. Mer troligt är att programmet mellanläser SELECTs och UPDATEs och ditt test bör försöka simulera det.

När frågeexemplet är klart kör du det mot servern med hjälp av en mySQL-kommandoradsklient eller ett verktyg som mysqlslapv.

Köra tester

Oavsett om du kör ett syntetiskt riktmärke eller ett verkligt prestandatest för program finns det flera tumregler att följa för att säkerställa att du får mer representativa resultat.

Köra tester mot flera instanstyper

Anta att du bestämmer dig för att köra benchmarks mot en db.r3.2xlarge-server och upptäcker att programmets/frågans prestanda redan uppfyller dina krav. Vi rekommenderar också att du kör tester både mot mindre och större instanstyper, vilket ger två fördelar:

Testning med mindre instanstyper kan fortfarande ge bra prestandaresultat och avslöja potentiella kostnadsbesparingsmöjligheter.
Testning med större instanstyper kan ge idéer eller insikter om framtida skalbarhetsalternativ.

Mäta både varaktiga och högsta prestanda

Teststrategin som du väljer bör ge dig svar på om databasen kommer att tillhandahålla tillräckliga:

Varaktig prestanda – kommer den att fungera som förväntat under den normala arbetsbelastningen, när användartrafiken är smidig och väl inom förväntade nivåer?
Högsta prestanda – kommer det att säkerställa programresponsivitet under trafiktoppar?

Läs igenom följande riktlinjer:

Se till att testkörningarna är tillräckligt långa för att utvärdera databasens prestanda i ett stabilt tillstånd. Ett komplext test som till exempel bara varar i 10 minuter ger sannolikt felaktiga resultat, eftersom databasens cacheminnen och buffertar kanske inte kan värmas upp på så kort tid.
Prestandamått kan vara mycket mer meningsfulla och informativa om arbetsbelastningsnivåerna varierar under hela testet. Om ditt program till exempel vanligtvis tar emot trafik från 64 samtidiga klienter startar du riktmärket med 64 klienter. När testet fortfarande körs lägger du sedan till ytterligare 64 klienter för att avgöra hur servern beter sig under en simulerad trafiktoppar.

Inkludera blackout-/brownout-tester i benchmark-proceduren

Bibehållen serverprestanda är ett viktigt mått, som sannolikt kommer att bli den viktigaste fokuspunkten under dina tester. För verksamhetskritiska program bör dock prestandatestningen inte sluta att mäta serverbeteendet i stabilt tillstånd.

Överväg att inkludera följande scenarier i dina tester.

"Blackout"-tester, som är utformade för att avgöra hur databasen beter sig under en omstart eller en krasch. Azure Database for MySQL – flexibel server introducerar betydande förbättringar kring kraschåterställningstider, och omstarts-/kraschtester är avgörande för att förstå hur Azure Database for MySQL– flexibel server bidrar till att minska programavbrotten i sådana scenarier.
"Brownout"-tester, som är utformade för att mäta hur snabbt en databas uppnår nominella prestandanivåer efter en omstart eller krasch. Databaser behöver ofta tid för att uppnå optimala prestanda, och Azure Database for MySQL – flexibel server introducerar även förbättringar på det här området.

I händelse av stabilitetsproblem som påverkar databasen hjälper all information som samlas in under prestandamåtten att identifiera flaskhalsar eller finjustera programmet ytterligare för att tillgodose arbetsbelastningsbehoven.

Dela via