Ultimo aggiornamento: 2026-07-02

Punteggio Apdex

Apdex — l'Application Performance Index — è uno standard aperto che trasforma un flusso di misurazioni del tempo di risposta in un unico punteggio di soddisfazione compreso tra 0 e 1. È stato concepito perché le prestazioni di un'applicazione possano essere comunicate a non specialisti senza un grafico: un solo numero cattura la proporzione di richieste abbastanza veloci da mantenere soddisfatti gli utenti. Apdex è ampiamente supportato dalle piattaforme di monitoraggio ed è un modo comune per esprimere un obiettivo di livello di servizio sul tempo di risposta.

Formula

Ogni richiesta viene confrontata con una soglia obiettivo $T$ e classificata in uno di tre gruppi:

• Soddisfatta — tempo di risposta minore o uguale a $T$.
• Tollerante — tempo di risposta maggiore di $T$ ma minore o uguale a $4T$.
• Frustrata — tempo di risposta maggiore di $4T$, oppure richiesta fallita o in timeout.

Il punteggio è il numero di campioni soddisfatti più la metà dei tolleranti, diviso per il numero totale di campioni:

dove il totale è la somma dei tre conteggi:

Le richieste tolleranti contano per metà perché quegli utenti hanno notato il ritardo ma non sono stati bloccati. Le richieste frustrate non contribuiscono. Il risultato è sempre compreso tra 0 (tutte frustrate) e 1 (tutte soddisfatte). La soglia $T$ determina in quale gruppo cade ciascuna richiesta, ma non compare nel calcolo una volta fissati i conteggi.

Esempio svolto

Supponiamo che una finestra di monitoraggio di 1.000 richieste, misurate rispetto a una soglia di $T = 500$ ms, si suddivida così:

• 850 richieste soddisfatte (≤ 500 ms)
• 120 richieste tolleranti (500 ms – 2.000 ms)
• 30 richieste frustrate (> 2.000 ms o fallite)

Prima confermiamo il totale:

Poi applichiamo la formula:

Un punteggio di 0,910 rientra nella fascia «buono», a indicare che i tempi di risposta hanno soddisfatto le aspettative degli utenti per la maggior parte del traffico di questa finestra.

Fasce di valutazione

L'Apdex Alliance pubblica etichette qualitative in modo che un numero isolato possa essere comunicato a colpo d'occhio. Una corrispondenza molto usata è:

Queste fasce sono una convenzione di reportistica, non una specifica rigida. Un team con obiettivi di latenza ambiziosi può trattare come meritevole di attenzione tutto ciò che è sotto 0,94, mentre un sistema di back-office orientato ai batch fisserà un'asticella più permissiva.

Scelta della soglia

La decisione di maggior peso è il valore di $T$. Se impostato troppo alto, un'applicazione lenta riporterà comunque un punteggio lusinghiero; se troppo basso, anche un servizio sano apparirà scarso. La specifica raccomanda di ancorare $T$ al tempo di risposta che gli utenti percepiscono come il limite di un'esperienza fluida, oppure all'obiettivo di un accordo sul livello di servizio esistente — spesso nell'ordine di poche centinaia di millisecondi per le pagine interattive. Poiché il confine di frustrazione è fissato a $4T$, scegliere $T$ fissa automaticamente l'intero schema di classificazione.

Limiti

Apdex comprime un'intera distribuzione di latenza in un solo numero e quindi scarta necessariamente dettaglio. Due distribuzioni molto diverse possono condividere lo stesso punteggio, e il confine di tolleranza fisso $4T$ potrebbe non coincidere con il modo in cui gli utenti di una specifica applicazione percepiscono davvero il ritardo. Il punteggio inoltre non dice nulla sul throughput, sulla semantica degli errori oltre il gruppo frustrato, né su quali richieste siano state lente. Trattalo come un indicatore di soddisfazione di alto livello e affiancalo alla latenza per percentili e al tasso di errore quando diagnostichi una regressione.

Per una visione correlata sugli obiettivi di disponibilità, vedi Calcolatore di disponibilità SLA.