GH GambleHub

Operazioni e Gestione → Metriche delle prestazioni

Metriche delle prestazioni

1) A cosa servono le metriche delle prestazioni

Le prestazioni sono la capacità del sistema di fornire SLO mirati in base ai tempi di risposta e alla larghezza di banda a costi contenuti. Senza metriche non è possibile:
  • rilevare il degrado prima degli incidenti,
  • prevedere capacità e budget,
  • confrontare le soluzioni alternative (cache vs database, gRPC vs REST),
  • gestire le regressioni dopo i rilasci.

I principi sono: un unico dizionario di metriche, aggregazione per percento (p50/p90/p95/p99), conteggio separato di percorsi caldi e freddi, contesto (versione, regione, provider, dispositivo).

2) Tassonomia metriche

2. 1 Cornici SRE base

Quattro segnali d'oro: Latency, Traffic, Errors, Saturation.
RED (per microservizi): Rate, Errors, Duration.
USA (per il ferro): Utilization, Saturation, Errors.

2. 2 Livelli

Infrastruttura: CPU, RAM, disco, rete, contenitori, nodi.
Piattaforma/Servizi: endpoint API, code, cache, database, pneumatici eventi.
Esperienza dei clienti: Web Vitals, mobile SDK, streaming, CDN.
Piattaforma data: ETL/ELT, strip, vetrine, BI ritardi.
Flow critici aziendali: autorizzazioni, KYC, depositi/pagamenti, round game.

3) Catalogo delle metriche chiave e delle formule

3. 1 API e microservizi

RPS (Requests per second).
Latency p50/p95/p99 (ms) - preferibilmente «end-to-end» e «backend-only».
Errore Rate (%) = 5xx + convalidabili 4xx/tutte le richieste.
Saturation: lunghezza media della coda dei worker, in-flight delle query.
Cold Start Rate (per FaaS).
Throttling/Dropped Requests.

SLO esempio: p95 latency 250 ms con RPS fino a 2k nella regione EU-East; Errori ≤ 0. 5%.

3. 2 Database

QPS/Transactions/s, avg/median query time, p95 query time.
Lock Waits / Deadlocks, Row/Index Hit Ratio, Buffer Cache Miss%.
RepLag (replica), Checkpoint/Flush time, Autovacuum lag.
Hot Keys/Skew è il top-N delle chiavi di carico.

La formula Query kernel è QPS/ .

3. 3 Cache e CDN

Hit Ratio (%), Evictions/s, Latency p95, Item Size percentiles.
Origin Offload (%) для CDN, TTFB, Stale-while-revalidate hit%.

3. 4 Code/striam

Ingress/egress msg/s, Consumer Lag (messaggi/ora), Rebalance rate.
Processing Time p95, DLQ Rate.

3. 5 Infrastruttura/contenitori

CPU Utilization %, CPU Throttle %, Run Queue length.
Memory RSS/Working Set, OOM kills, Page Faults.
Disk IOPS/Latency/Throughput, Network RTT/ retransmits.
Node Saturation: pods pending, pressure (CPU/Memory/IO).

3. 6 Client Web (UX)

Core Web Vitals: LCP, INP, CLS.
TTFB, FCP, TTI, Resource Timing (DNS, TLS, TTFB, download).
Error Rate (JS), Long Tasks, SPA route change time.
CDN Geo-Latency.

3. 7 Client mobile

App Start time (cold/warm), ANR rate, Crash-free sessions %.
Network round-trips/session, Payload size, Battery drain/session.
Offline success rate (operazioni di cache).

3. 8 Data-piattaforma e report

Freshness Lag (T-now → витрина), Throughput rows/s, Job Success %.
Cost per TB processed, Skew per partenze, Late events%.
BI Time-to-Render p95 per i dashboard chiave.

3. 9 Flow critici di dominio (iGaming come esempio)

Auth p95, KYC TTV (Time-to-Verify), Deposit/Withdrawal p95.
Game Round Duration p95, RNG call latency, Provider RTT p95.
Payment PSP success rate, Chargeback investigation SLA.

4) Normalizzazione, percezione e attribuzione

Percentili contro media: fissiamo p50/p90/p95/p99 - la media allevia il dolore di punta.
Tagli: versione dell'applicazione, regione, provider, canale di rete (4G/Wi-Fi), dispositivo.
Correlazione: colleghiamo «backend-only» e «real-user» le metriche per le catene di causale.
Eccplars/Trace - Colleghiamo i percettori estremi ai tracciati.

5) Soglie e alert (griglia modello)

Latency p95 (core API): warning> 250 ms, critical> 400 ms 5 minuti consecutivi.
Error rate: warning > 0. 5%, critical> 2% (endpoint, non globale).
DB RepLag: warning > 2 s, critical > 10 s.
Kafka consumer lag (time): warning > 30 s, critical > 2 min.
Web LCP (p75): warning > 2. 5 s, critical > 4 s.
Mobile ANR: warning > 0. 5%, critical > 1%.
ETL Freshness: warning > +15 min, critical > +60 min от SLA.

Usiamo soglie statiche + adattive (stagionalità, modelli diurni), deduplicazione e raggruppamento di alert per servizi/rilascio.

6) Test delle prestazioni

Tipi: baseline, stress, lungo (soak), caos (degrade links/PSP).
Profili di carico: trade reali (distribuzione-based), burst, picchi regionali.
Obiettivi: raggiungimento di SLO con operazioni mirate RPS e mix, convalida backpressure.
Metriche di progone: Throughput, Errore%, p95 latency, pausa GC, CPU throttle, queue lag, cost/run.

Regola di regressione: il rilascio è considerato un successo se p95 non è peggiorato> 10% con un profilo uguale e il costo della richiesta (CPU-ms/query) non è aumentato> 15%.

7) Pianificazione della capacità e costi/prestazioni

Demand model: RPS ore x media lavoro/query (CPU-ms, IO-ops).
Headroom: 30-50% di riserva per percorsi critici, auto-scaling per P95.
Cost KPIs: Cost per 1k requests, Cost per GB served, $ per 1 p. p. Miglioramenti LCP.
Cache/Denormalizzazione: conta «cache ROY» = (risparmio CPU-ms - costo cache).
Regioni calde e fredde: offload in CDN/edge, replica solo lettura.

8) Pratiche di osservazione e profilassi

Tracciati: trace-ID distribuiti attraverso tutti gli hop's; il sempilamento è intelligente (tail-based).
Metrica: Prometheus/OpenTelemetry, una sola nota di nomi e etichette.
Loghi: correlazione trace/span, budget al rumore logico, modifica PII.
Profilatori: CPU/Heap/Alloc/Lock profiles, profilazione continua (eBPF).
Istanze campione: colleghiamo p99 picchi a specifici span/SQL/PSP-call.

9) Metriche di rilascio e comandi (per la completezza)

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
SPAZIO: soddisfazione, prestazioni, attività, comunicazione, efficienza.
Queste metriche non riguardano il ferro, ma influenzano direttamente la sostenibilità delle prestazioni.

10) Anti-pattern

Insegui media: ignora p95/p99.
«Global» errato rate, nasconde endpoint dolorosi.
Senza l'assegnazione delle versioni, non è possibile catturare la regressione del client.
Alert-spam - soglie senza isteresi e correzione stagionale.
Ottimizzazione alla cieca: nessuna profilassi o traccia.
Combinazione tra UX e backend latency: conclusioni errate per esperienza client.

11) Assegno fogli

Standard di metriche unificate

  • Dizionario di metriche con formule, unità, proprietari
  • Percentili obbligatori p50/p90/p95/p99
  • Correlazione trace e loga-correlazione
  • Tag: regione, versione, provider, dispositivo, canale di rete
  • Soglie con isteresi e deduplicazione

Prima del lancio

  • Baseline p95/p99 su stage e vendette
  • Traffico canarino + confronto metriche A/B
  • Flag Fiech con rigetto rapido
  • Piano di sorveglianza (osservability runbook)

Regolare

  • Ruota i top-N più lenti di query/SQL
  • Controllo dei criteri cache e TTL
  • Verifica di Freshness e delle repliche del database
  • Test di degrado dei provider esterni (PSP, KYC)

12) Mini playbook (esempio)

Degrado p95/api/payments

1. Incrocia il% e i timeout PSP esterni.
2. Controlla il consumer lag code Colleback.
3. Visualizzare trace di esempi p99: lo stretto di SQL/HTTP?
4. Abilita la cache di guide/limiti, riduce N + 1.
5. Budget: aumentare temporaneamente del 20% le risorse del worker, includere l'autoscale.
6. Post-fix: indice per (psp _ id, status, created _ at), retrai-jitter.

Crescita del RepLag nel database

1. Verifica richieste pesanti e transazioni lunghe.
2. Aumenta il parallelismo della replica, tinge checkpoint.
3. Offload di sola lettura nella cache/replica.
4. Con le finestre di punta, denorm parziale + batch.

13) Esempi di formule/SQL (semplificato)

Errore Rate per endpoint

sql
SELECT endpoint,
100. 0 SUM(CASE WHEN status >= 500 THEN 1 ELSE 0 END) / COUNT() AS error_pct
FROM http_logs
WHERE ts >= now() - interval '5 minutes'
GROUP BY 1
HAVING COUNT() > 500;

Latency p95 (TDigest/Approx)

sql
SELECT endpoint, approx_percentile(latency_ms, 0. 95) AS p95_ms
FROM http_metrics
WHERE ts >= date_trunc('hour', now())
GROUP BY 1;

Consumer Lag (ora)

sql
SELECT topic, consumer_group,
max(produced_ts) - max(consumed_ts) AS lag_interval
FROM stream_offsets
GROUP BY 1,2;

Web LCP p75

sql
SELECT approx_percentile(lcp_ms, 0. 75) AS lcp_p75
FROM web_vitals
WHERE country = 'UA' AND device IN ('mobile','tablet')
AND ts >= current_date;

14) Incorporazione e reporting dei dashboard

Carte KPI: p95 latency, errore%, RPS, saturation con trend WoW/DoD.
Top N «peggiori» endpoint/SQL/risorse, cliccabile drill-down-trace.
La correlazione delle versioni del client è la versione p95 LCP/INP della conversione.
Mappa del mondo: geo-latency (CDN), PSP latency per regione.
Dashboard SLO: parte del tempo in SLO, uscite da SLO, bilancio degli errori.

15) Riepilogo

Le metriche delle prestazioni sono una disciplina di sistema: un unico dizionario, una perforazione, un'attribuzione, una buona osservabilità e un SLO rigoroso. Combinando i segnali tecnici (latitanza, lagi, kash hit) e alimentari (tempo KYC, deposito p95, LCP), si gestisce la qualità dell'esperienza e il costo della consegna - prevedibile e scalabile.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.