Benchmark DTU

  • Articolo

Si applica a:Database SQL di Azure

L'unità di transazione di database (DTU) è un'unità di misura che rappresenta una misura combinata di CPU, memoria e operazioni di lettura e scrittura. Le caratteristiche fisiche (CPU, memoria, IO) associate a ciascuna misura DTU vengono calibrate usando un benchmark che simula il carico di lavoro di database reali. Questo articolo riepiloga il benchmark DTU e condivide informazioni sullo schema, i tipi di transazione usati, la combinazione di carichi di lavoro, gli utenti e la velocità, le regole di ridimensionamento e le metriche associate al benchmark.

Per informazioni generali sul modello di acquisto basato su DTU, consultare la Panoramica sul modello di acquisto basato su DTU.

Riepilogo del benchmark

Il benchmark DTU misura le prestazioni di una combinazione di operazioni di database di base che si verificano con maggiore frequenza in carichi di lavoro di elaborazione di transazioni online (OLTP). Benché il benchmark sia stato progettato tenendo conto del cloud computing, lo schema del database, il popolamento di dati e le transazioni sono stati progettati in modo da rappresentare a grandi linee gli elementi di base usati con maggiore frequenza con carichi di lavoro OLTP.

Correlazione tra i risultati e le prestazioni del database nel mondo reale

È importante comprendere che tutti i benchmark hanno una funzione esclusivamente rappresentativa e indicativa. Le frequenze di transazioni raggiunte con l'applicazione benchmark non saranno uguali a quelle che è possibile ottenere con altre applicazioni. Il benchmark include una raccolta di diversi tipi di transazioni eseguiti a fronte di uno schema contenente una gamma di tabelle e tipi di dati. Anche se il benchmark esegue le stesse operazioni di base comuni a tutti i carichi di lavoro OLTP, esso non rappresenta una specifica classe di database o applicazione. L'obiettivo del benchmark è fornire un'indicazione ragionevole delle prestazioni relative di un database previste in caso di riduzione o aumento delle dimensioni di calcolo.

Nella realtà i database hanno dimensioni e complessità diverse, gestiscono combinazioni diverse di carichi di lavoro e rispondono in modi diversi. Ad esempio, un'applicazione con un utilizzo elevato di I/O può raggiungere le soglie di I/O prima, così come un'applicazione con un utilizzo elevato di CPU può raggiungere i limiti di CPU in tempi più brevi. Non vi sono garanzie che la scalabilità di un determinato database corrisponda a quella del benchmark in caso di aumento del carico.

Il benchmark e la relativa metodologia sono descritti con maggiori dettagli in questo articolo.

Schema

Lo schema è progettato in modo da prevedere una varietà e una complessità sufficienti per supportare una vasta gamma di operazioni. Il benchmark viene eseguito a fronte di un database costituito da sei tabelle. Le tabelle rientrano in tre categorie, ovvero a dimensione fissa, ridimensionabili ed espandibili. Sono presenti due tabelle a dimensione fissa, tre tabelle ridimensionabili e una tabella espandibile. Le tabelle a dimensione fissa includono un numero costante di righe. Le tabelle ridimensionabili prevedono una cardinalità proporzionale alle prestazioni del database, che però non cambia durante l'esecuzione del benchmark. La tabella espandibile ha le dimensioni di una tabella ridimensionabile con carico iniziale, ma successivamente la cardinalità cambia nel corso dell'esecuzione del benchmark con l'inserimento e l'eliminazione di righe.

Lo schema include una combinazione di tipi di dati, tra cui valori integer, valori numerici, caratteri e valori di data/ora. Sono incluse chiavi primarie e secondarie, ma non chiavi esterne e non esistono pertanto vincoli di integrità referenziale tra le tabelle.

Un programma di generazione di dati genera i dati per il database iniziale. I dati integer e numeric vengono generati con diverse strategie. In alcuni casi, i valori vengono distribuiti in modo casuale su un intervallo. In altri casi, un insieme di valori viene permutato in modo casuale per garantire che venga mantenuta una distribuzione specifica. I campi di testo vengono generati da un elenco ponderato di parole per produrre dati realistici.

Le dimensioni del database si basano su un fattore di conversione. (SF), che determina la cardinalità delle tabelle ridimensionabili ed espandibili. Come descritto più avanti nella sezione Utenti e velocità, la dimensione del database, il numero di utenti e le prestazioni massime vengono tutti adattati in proporzione.

Transazioni

Il carico di lavoro è costituito da nove tipi di transazioni, come illustrato nella tabella riportata di seguito. Ogni transazione è progettata per evidenziare un insieme specifico di caratteristiche di sistema nel motore di database e nell'hardware del sistema, con un contrasto elevato rispetto alle altre transazioni. Questo approccio consente di valutare l'impatto dei diversi componenti sulle prestazioni globali. Ad esempio, la transazione "Operazioni lettura intense" produce un numero significativo di operazioni di lettura dal disco.

Tipo di transazione Descrizione
Operazioni lettura leggere SELECT, in memoria, sola lettura
Operazioni lettura medie SELECT, principalmente in memoria, sola lettura
Operazioni lettura intense SELECT, principalmente non in memoria, sola lettura
Operazioni aggiornamento leggere UPDATE, in memoria, lettura/scrittura
Operazioni aggiornamento intense UPDATE, principalmente non in memoria, lettura/scrittura
Operazioni inserimento leggere INSERT, in memoria, lettura/scrittura
Operazioni inserimento intense INSERT, principalmente non in memoria, lettura/scrittura
Elimina DELETE, combinazione in memoria e non in memoria, lettura/scrittura
Operazioni CPU intense SELECT, in memoria, carico CPU relativamente pesante, sola lettura

Combinazione di carichi di lavoro

Le transazioni vengono selezionate casualmente da una distribuzione ponderata con la seguente combinazione globale. La combinazione globale presenta un rapporto di lettura/scrittura di circa 2:1.

Tipo di transazione % di combinazione
Operazioni lettura leggere 35
Operazioni lettura medie 20
Operazioni lettura intense 5
Operazioni aggiornamento leggere 20
Operazioni aggiornamento intense 3
Operazioni inserimento leggere 3
Operazioni inserimento intense 2
Elimina 2
Operazioni CPU intense 10

Utenti e velocità

Il carico di lavoro del benchmark si basa su uno strumento che invia transazioni attraverso un insieme di connessioni per simulare il comportamento di numerosi utenti simultanei. Benché tutte le connessioni e transazioni siano generate da un computer, per semplicità vengono indicate come utenti. Sebbene ogni utente agisca in modo indipendente da tutti gli altri, tutti gli utenti eseguono lo stesso ciclo di passaggi illustrato di seguito:

  1. Stabilire una connessione di database.
  2. Ripetere le operazioni seguenti fino al segnale di uscita:
    • Selezionare una transazione in modo casuale (da una distribuzione ponderata).
    • Eseguire la transazione selezionata e misurare il tempo di risposta.
    • Attendere un ritardo velocità.
  3. Chiudere la connessione di database.
  4. Uscire.

Il ritardo velocità (passaggio 2c) viene selezionato in modo casuale, ma con una distribuzione che presenta una media di 1,0 secondi. Pertanto, ogni utente in media può generare al massimo una transazione al secondo.

Regole di ridimensionamento

Il numero di utenti è determinato dalle dimensioni del database (in unità di fattore di conversione). Esiste un utente per ogni unità di fattore di scala. A causa del ritardo velocità, un utente in media può generare al massimo una transazione al secondo.

Ad esempio, un database con fattore di scala pari a 500 (SF=500) avrà 100 utenti e potrà raggiungere una frequenza massima di 100 TPS. Per ottenere un valore TPS più elevato, sono necessari più utenti e un database di dimensioni maggiori.

Durata della misurazione

Per l'esecuzione di un benchmark valido è necessaria una durata della misurazione in condizioni stabili di almeno un'ora.

Metrica

La metrica di base del benchmark è rappresentata dalla velocità effettiva e dal tempo di risposta.

  • La velocità effettiva è l'unità di misura di base delle prestazioni nel benchmark. Viene misurata in transazioni per unità di tempo, conteggiando tutti i tipi di transazioni.
  • Il tempo di risposta consente di misurare la prevedibilità delle prestazioni. Il vincolo del tempo di risposta varia in base alla classe di servizio. I servizi di classe superiore prevedono requisiti di tempi di risposta più rigorosi, come illustrato di seguito.
Classe di servizio Misura della velocità effettiva Requisito di tempi di risposta
Premium Transazioni al secondo 95° percentile a 0,5 secondi
Standard Transazioni al minuto 90° percentile a 1,0 secondi
Base Transazioni all'ora 80° percentile a 2,0 secondi

Nota

Le metriche relative al tempo di risposta sono specifiche per il benchmark DTU. I tempi di risposta per altri carichi di lavoro dipendono dal carico di lavoro e possono essere diversi.

Passaggi successivi

Altre informazioni sui modelli di acquisto e sui concetti correlati sono disponibili nei seguenti articoli: