DTU-benchmark

  • Artikel

Van toepassing op: Azure SQL Database

Een database transaction unit (DTU) is een maateenheid die een gemengde meting van CPU, geheugen, leesbewerkingen en schrijfbewerkingen vertegenwoordigt. Fysieke kenmerken (CPU, geheugen, IO) die aan elke DTU-meting zijn gekoppeld, worden gekalibreerd met behulp van een benchmark die de werkelijke databaseworkload simuleert. Dit artikel bevat een overzicht van de DTU-benchmark en deelt informatie over het schema, gebruikte transactietypen, workloadmix, gebruikers en pacing, schaalregels en metrische gegevens die zijn gekoppeld aan de benchmark.

Zie het overzicht van het aankoopmodel op basis van DTU voor algemene informatie over het aankoopmodel op basis van DTU.

Benchmark-samenvatting

De DTU-benchmark meet de prestaties van een combinatie van basisdatabasebewerkingen die het vaakst voorkomen in OLTP-workloads (Online Transaction Processing). Hoewel de benchmark is ontworpen met cloud-computing, zijn het databaseschema, de gegevenspopulatie en transacties ontworpen om breed te zijn afgestemd op de basiselementen die het meest worden gebruikt in OLTP-workloads.

Benchmarkresultaten correleren met de prestaties van echte databases

Het is belangrijk om te begrijpen dat alle benchmarks representatief en alleen indicatief zijn. De transactietarieven die met de benchmarktoepassing worden bereikt, zijn niet hetzelfde als de transacties die kunnen worden bereikt met andere toepassingen. De benchmark bestaat uit een verzameling verschillende transactietypen die worden uitgevoerd op basis van een schema met een reeks tabellen en gegevenstypen. Hoewel de benchmark dezelfde basisbewerkingen uitvoert die gebruikelijk zijn voor alle OLTP-workloads, vertegenwoordigt deze geen specifieke klasse van database of toepassing. Het doel van de benchmark is om een redelijke handleiding te bieden voor de relatieve prestaties van een database die kan worden verwacht bij het omhoog of omlaag schalen tussen rekengrootten.

In werkelijkheid zijn databases van verschillende grootten en complexiteit, ondervinden verschillende combinaties van workloads en reageren ze op verschillende manieren. Een IO-intensieve toepassing kan bijvoorbeeld eerder IO-drempelwaarden bereiken, of een CPU-intensieve toepassing kan eerder CPU-limieten bereiken. Er is geen garantie dat een bepaalde database op dezelfde manier wordt geschaald als de benchmark onder toenemende belasting.

De benchmark en de bijbehorende methodologie worden in dit artikel uitvoeriger beschreven.

Schema

Het schema is ontworpen om voldoende verscheidenheid en complexiteit te hebben om een breed scala aan bewerkingen te ondersteunen. De benchmark wordt uitgevoerd op basis van een database die bestaat uit zes tabellen. De tabellen worden onderverdeeld in drie categorieën: vaste grootte, schaalaanpassing en groei. Er zijn twee tabellen met een vaste grootte; drie schaaltabellen; en één groeiende tafel. Tabellen met een vaste grootte hebben een constant aantal rijen. Het schalen van tabellen heeft een kardinaliteit die evenredig is met de prestaties van de database, maar niet verandert tijdens de benchmark. De groeiende tabel heeft de grootte van een schaaltabel bij de eerste belasting, maar vervolgens verandert de kardinaliteit in de loop van het uitvoeren van de benchmark wanneer rijen worden ingevoegd en verwijderd.

Het schema bevat een combinatie van gegevenstypen, waaronder geheel getal, numeriek, teken en datum/tijd. Het schema bevat primaire en secundaire sleutels, maar geen referentiële sleutels: er zijn geen beperkingen voor referentiële integriteit tussen tabellen.

Een programma voor het genereren van gegevens genereert de gegevens voor de eerste database. Gehele getallen en numerieke gegevens worden gegenereerd met verschillende strategieën. In sommige gevallen worden waarden willekeurig verdeeld over een bereik. In andere gevallen wordt een set waarden willekeurig permuteerd om ervoor te zorgen dat een specifieke verdeling wordt gehandhaafd. Tekstvelden worden gegenereerd op basis van een gewogen lijst met woorden om realistische gegevens te produceren.

De grootte van de database is gebaseerd op een schaalfactor. De schaalfactor (afgekort als SF) bepaalt de kardinaliteit van de schaal- en groeitabellen. Zoals hieronder beschreven in de sectie Gebruikers en Pacing, de grootte van de database, het aantal gebruikers en de maximale prestaties, worden allemaal geschaald in verhouding tot elkaar.

Transacties

De workload bestaat uit negen transactietypen, zoals wordt weergegeven in de onderstaande tabel. Elke transactie is ontworpen om een bepaalde set systeemkenmerken in de database-engine en systeemhardware te markeren, met een hoog contrast van de andere transacties. Deze aanpak maakt het eenvoudiger om de impact van verschillende onderdelen op de algehele prestaties te beoordelen. De transactie 'Leesintensief' produceert bijvoorbeeld een aanzienlijk aantal leesbewerkingen van schijf.

Transactietype Omschrijving
Lite lezen SELECTEER; in-memory; alleen-lezen
Normaal lezen SELECTEER; voornamelijk in het geheugen; alleen-lezen
Leesintensief SELECTEER; meestal niet in het geheugen; alleen-lezen
Lite bijwerken UPDATE; in-memory; lezen/schrijven
Zwaar bijwerken UPDATE; meestal niet in het geheugen; lezen/schrijven
Lite invoegen INVOEGEN; in-memory; lezen/schrijven
Zwaar invoegen INVOEGEN; meestal niet in het geheugen; lezen/schrijven
Verwijderen VERWIJDEREN; mix van in-memory en niet in-memory; lezen/schrijven
CPU-intensief SELECTEER; in-memory; relatief zware CPU-belasting; alleen-lezen

Workloadmix

Transacties worden willekeurig geselecteerd uit een gewogen verdeling met de volgende algemene mix. De algehele mix heeft een lees-/schrijfverhouding van ongeveer 2:1.

Transactietype % van mix
Lite lezen 35
Normaal lezen 20
Leesintensief 5
Lite bijwerken 20
Zwaar bijwerken 3
Lite invoegen 3
Zwaar invoegen 2
Verwijderen 2
CPU-intensief 10

Gebruikers en pacing

De benchmarkworkload wordt gebaseerd op een hulpprogramma waarmee transacties worden verzonden over een set verbindingen om het gedrag van een aantal gelijktijdige gebruikers te simuleren. Hoewel alle verbindingen en transacties worden gegenereerd, verwijzen we voor het gemak naar deze verbindingen als gebruikers. Hoewel elke gebruiker onafhankelijk van alle andere gebruikers werkt, voeren alle gebruikers dezelfde cyclus van stappen uit die hieronder worden weergegeven:

  1. Een databaseverbinding tot stand brengen.
  2. Herhaal dit totdat u wordt gesignaleerd om af te sluiten:
    • Selecteer een willekeurige transactie (uit een gewogen verdeling).
    • Voer de geselecteerde transactie uit en meet de reactietijd.
    • Wacht op een tempovertraging.
  3. Sluit de databaseverbinding.
  4. Afsluiten.

De pacing-vertraging (in stap 2c) wordt willekeurig geselecteerd, maar met een verdeling met een gemiddelde van 1,0 seconde. Elke gebruiker kan dus gemiddeld maximaal één transactie per seconde genereren.

Regels voor schalen

Het aantal gebruikers wordt bepaald door de databasegrootte (in schaalfactoreenheden). Er is één gebruiker voor elke vijf schaalfactoreenheden. Vanwege de pacing-vertraging kan één gebruiker gemiddeld maximaal één transactie per seconde genereren.

Een schaalfactor van 500 (SF=500) heeft bijvoorbeeld 100 gebruikers en kan een maximumsnelheid van 100 TPS bereiken. Voor een hogere TPS-snelheid zijn meer gebruikers en een grotere database vereist.

Duur van meting

Een geldige benchmarkuitvoering vereist een stabiele meetduur van ten minste één uur.

Metrische gegevens

De belangrijkste metrische gegevens in de benchmark zijn doorvoer en reactietijd.

  • Doorvoer is de essentiële prestatiemeting in de benchmark. Doorvoer wordt gerapporteerd in transacties per eenheid van tijd, waarbij alle transactietypen worden geteld.
  • Reactietijd is een meting van de voorspelbaarheid van prestaties. De reactietijdbeperking varieert per serviceklasse, met hogere serviceklassen met een strengere reactietijdvereiste, zoals hieronder wordt weergegeven.
Klasse van service Doorvoermeting Vereiste reactietijd
Premium Transacties per seconde 95e percentiel bij 0,5 seconden
Standaard Transacties per minuut 90e percentiel bij 1,0 seconden
Basic Transacties per uur 80e percentiel bij 2,0 seconden

Notitie

Metrische reactietijdgegevens zijn specifiek voor de DTU-benchmark. Reactietijden voor andere workloads zijn afhankelijk van de werkbelasting en verschillen.

Volgende stappen

Meer informatie over aankoopmodellen en gerelateerde concepten vindt u in de volgende artikelen: