DTU-benchmark

Artikel
07/31/2023

En databastransaktionsenhet (DTU) är en måttenhet som representerar ett blandat mått på CPU, minne, läsningar och skrivningar. Fysiska egenskaper (CPU, minne, I/O) som är associerade med varje DTU-mått kalibreras med hjälp av ett riktmärke som simulerar en verklig databasarbetsbelastning. Den här artikeln sammanfattar DTU-riktmärket och delar information om schemat, transaktionstyper som används, arbetsbelastningsmix, användare och pacing, skalningsregler och mått som är associerade med riktmärket.

Allmän information om den DTU-baserade inköpsmodellen finns i översikten över DTU-baserad köpmodell.

Benchmark-sammanfattning

DTU-riktmärket mäter prestanda för en blandning av grundläggande databasåtgärder som förekommer oftast i OLTP-arbetsbelastningar (onlinetransaktionsbearbetning). Även om riktmärket är utformat med molnbaserad databehandling i åtanke har databasschemat, datapopulationen och transaktionerna utformats för att i stort sett vara representativa för de grundläggande element som används oftast i OLTP-arbetsbelastningar.

Korrelera prestandamått till verkliga databasprestanda

Det är viktigt att förstå att alla riktmärken endast är representativa och vägledande. Transaktionsfrekvenserna som uppnås med benchmark-programmet kommer inte att vara desamma som de som kan uppnås med andra program. Benchmark består av en samling olika transaktionstyper som körs mot ett schema som innehåller ett intervall med tabeller och datatyper. Benchmark utför samma grundläggande åtgärder som är gemensamma för alla OLTP-arbetsbelastningar, men det representerar inte någon specifik klass av databas eller program. Målet med riktmärket är att tillhandahålla en rimlig guide till den relativa prestandan för en databas som kan förväntas vid upp- eller nedskalning mellan beräkningsstorlekar.

I verkligheten är databaser av olika storlekar och komplexitet, stöter på olika blandningar av arbetsbelastningar och svarar på olika sätt. Ett I/O-intensivt program kan till exempel nå I/O-tröskelvärden tidigare, eller så kan ett CPU-intensivt program nå CPU-gränserna tidigare. Det finns ingen garanti för att en viss databas kommer att skalas på samma sätt som riktmärket vid ökad belastning.

Referensvärdet och dess metod beskrivs mer detaljerat i den här artikeln.

Schema

Schemat är utformat för att ha tillräckligt med variation och komplexitet för att stödja ett brett spektrum av åtgärder. Riktmärket körs mot en databas som består av sex tabeller. Tabellerna delas in i tre kategorier: fast storlek, skalning och växande. Det finns två tabeller med fast storlek. tre skalningstabeller; och en växande tabell. Tabeller med fast storlek har ett konstant antal rader. Skalningstabeller har en kardinalitet som är proportionell mot databasprestanda, men som inte ändras under riktmärket. Den växande tabellen är storleksanpassad som en skalningstabell vid den inledande belastningen, men kardinaliteten ändras under körningen av riktmärket när rader infogas och tas bort.

Schemat innehåller en blandning av datatyper, inklusive heltal, numeriskt, tecken och datum/tid. Schemat innehåller primära och sekundära nycklar, men inga sekundärnycklar , det vill sägs att det inte finns några begränsningar för referensintegritet mellan tabeller.

Ett datagenereringsprogram genererar data för den första databasen. Heltal och numeriska data genereras med olika strategier. I vissa fall distribueras värden slumpmässigt över ett intervall. I andra fall permuteras en uppsättning värden slumpmässigt för att säkerställa att en specifik fördelning upprätthålls. Textfält genereras från en viktad lista med ord för att skapa realistiska data.

Databasen är storleksanpassad baserat på en skalningsfaktor. Skalningsfaktorn (förkortad som SF) avgör kardinaliteten för skalnings- och växande tabeller. Enligt beskrivningen nedan i avsnittet Användare och pacing skalas databasens storlek, antal användare och högsta prestanda i förhållande till varandra.

Transaktioner

Arbetsbelastningen består av nio transaktionstyper, enligt tabellen nedan. Varje transaktion är utformad för att markera en viss uppsättning systemegenskaper i databasmotorn och systemmaskinvaran, med hög kontrast från de andra transaktionerna. Den här metoden gör det enklare att bedöma effekten av olika komponenter på övergripande prestanda. Till exempel genererar transaktionen "Read Heavy" ett stort antal läsåtgärder från disken.

Transaktionstyp	Beskrivning
Läs lite	VÄLJ; minnesintern; skrivskyddad
Läsmedium	VÄLJ; mestadels minnesintern; skrivskyddad
Läs tungt	VÄLJ; mestadels inte i minnet; skrivskyddad
Uppdatera lite	UPPDATERING; minnesintern; läs-skriva
Uppdatera tung	UPPDATERING; mestadels inte i minnet; läs-skriva
Infoga lite	INFOGA; minnesintern; läs-skriva
Infoga tung	INFOGA; mestadels inte i minnet; läs-skriva
Delete	TA BORT; blandning av minnesintern och inte minnesintern; läs-skriva
CPU Heavy	VÄLJ; minnesintern; relativt tung CPU-belastning. skrivskyddad

Arbetsbelastningsmix

Transaktioner väljs slumpmässigt från en viktad fördelning med följande övergripande blandning. Den övergripande mixen har ett läs-/skrivförhållande på cirka 2:1.

Transaktionstyp	% av mix
Läs lite	35
Läsmedium	20
Läs tungt	5
Uppdatera lite	20
Uppdatera tung	3
Infoga lite	3
Infoga tung	2
Delete	2
CPU Heavy	10

Användare och pacing

Benchmark-arbetsbelastningen drivs från ett verktyg som skickar transaktioner över en uppsättning anslutningar för att simulera beteendet hos ett antal samtidiga användare. Även om alla anslutningar och transaktioner genereras av datorer refererar vi för enkelhetens skull till dessa anslutningar som användare. Även om varje användare fungerar oberoende av alla andra användare utför alla användare samma stegcykel som visas nedan:

Upprätta en databasanslutning.
Upprepa tills det signaleras att avsluta:
- Välj en transaktion slumpmässigt (från en viktad fördelning).
- Utför den valda transaktionen och mät svarstiden.
- Vänta på en fördröjning.
Stäng databasanslutningen.
Avsluta.

Tempofördröjningen (i steg 2c) väljs slumpmässigt, men med en fördelning som har ett genomsnitt på 1,0 sekunder. Därför kan varje användare i genomsnitt generera högst en transaktion per sekund.

Skalningsregler

Antalet användare bestäms av databasens storlek (i skalningsfaktorenheter). Det finns en användare för varje fem skalningsfaktorenheter. På grund av fördröjningen kan en användare generera högst en transaktion per sekund i genomsnitt.

En skalningsfaktor på 500 (SF=500) databas har till exempel 100 användare och kan uppnå en maximal hastighet på 100 TPS. För att få en högre TPS-hastighet krävs fler användare och en större databas.

Måttvaraktighet

En giltig benchmark-körning kräver en varaktighet för steady-state-mätning på minst en timme.

Mått

De viktigaste måtten i riktmärket är dataflöde och svarstid.

Dataflöde är det viktigaste prestandamåttet i riktmärket. Dataflödet rapporteras i transaktioner per tidsenhet och räknar alla transaktionstyper.
Svarstiden är ett mått på prestandaöversägbarhet. Tidsbegränsningen för svar varierar med tjänstklassen, där högre tjänstklasser har ett strängare krav på svarstid, enligt nedan.

Tjänstklass	Dataflödesmått	Krav på svarstid
Premium	Transaktioner per sekund	95:e percentilen vid 0,5 sekunder
Standard	Transaktioner per minut	90:e percentilen vid 1,0 sekunder
Basic	Transaktioner per timme	80:e percentilen vid 2,0 sekunder

Kommentar

Mått för svarstid är specifika för DTU Benchmark. Svarstiderna för andra arbetsbelastningar är arbetsbelastningsberoende och skiljer sig åt.

Nästa steg

Läs mer om köpmodeller och relaterade begrepp i följande artiklar:

Dela via