I test sui thread pool mostrano che le modifiche alla buffer size cambiano i risultati
I test su database thread pool riportati da Percona il 12 ottobre 2026 mostrano che il valore del connection pooling dipende fortemente dalla dimensione della memoria, dal numero di connessioni e dalla specifica implementazione del server. Un thread pool è un modo con cui un database server riutilizza un insieme controllato di worker thread, unità di esecuzione interne al server, invece di creare o pianificare lavoro in modo troppo libero quando molti client si connettono contemporaneamente. L'obiettivo è mantenere alto il throughput e prevedibile la latency quando un database è sotto pressione.
I benchmark hanno confrontato la variante database server 9.7.1-1 di Percona con il database server standard 26.7.0, e hanno anche verificato il database server standard 26.7.0 rispetto al database server standard 9.7.2. Percona afferma che i risultati del database server standard 26.7.0 e 9.7.2 erano molto vicini. Le configurazioni senza thread pool sono convergite verso valori simili, e le configurazioni con thread pool hanno fatto lo stesso nei livelli di buffer testati di 2G, 12G e 32G. Le impostazioni thread pool testate includevano valori di thread_pool_size pari a 10, 20, 40, 80, 120 e 160, e valori di thread_pool_oversubscribe pari a 2, 3 e 4. Percona nota solo che il database server standard 26.7.0 era leggermente più veloce di 9.7.2 con numeri elevati di client thread, quindi i confronti successivi si concentrano sul database server standard 26.7.0.
Il punto pratico più importante è che l'InnoDB buffer pool, l'area di memoria in cui il database server conserva i dati di tabelle e indici usati di frequente, ha cambiato i risultati. Con innodb_buffer_pool_size impostato a 2G, il database server standard 26.7.0 non ha visto lo stesso grande guadagno da thread pool riportato per il database server di Percona, ma la configurazione con pooling ha comunque aiutato con numeri elevati di connessioni. A 2560 connessioni client, il database server standard con thread pool ha raggiunto 371 TPS, o transazioni al secondo, rispetto a 122 TPS senza thread pool. Si tratta di circa tre volte il throughput senza pooling. Percona riferisce che thread_pool_size=10 è stata la scelta migliore in questo livello, mentre impostazioni maggiori di 20, 40, 80, 120 e 160 hanno migliorato meno i TPS. Per il database server standard a 2G, cambiare thread_pool_oversubscribe ha avuto scarso effetto, anche se un valore di 2 è risultato leggermente migliore di 3 o 4.
A 12G, il throughput complessivo del database server standard è aumentato, ma il vantaggio relativo del thread pooling al numero di connessioni più alto è stato inferiore rispetto a 2G. Con 2560 connessioni e innodb_buffer_pool_size=12G, il database server standard ha raggiunto 1273 TPS con thread pool e 718 TPS senza, che Percona descrive come un miglioramento del 77 percento. A 32G, dove il data set era completamente in buffer, anche la configurazione con pooling del database server standard ha battuto la configurazione senza pooling: 18.975 TPS contro 17.011 TPS, un vantaggio dell'11,6 percento per il thread pool. Il risultato sulla latency ha seguito la stessa direzione. Percona riferisce che la p95 latency, cioè il tempo di risposta sotto il quale viene completato il 95 percento delle richieste, è scesa da 759 ms a 153 ms con il thread pool del database server standard abilitato in quello scenario completamente in buffer.
Il confronto diretto tra la variante database server 9.7.1-1 di Percona e il database server standard 26.7.0 mostra perché gli amministratori non dovrebbero presumere che nomi di impostazioni identici significhino comportamenti identici. Con innodb_buffer_pool_size=2G, Percona ha usato le impostazioni thread pool con le prestazioni migliori per ciascun server: thread_pool_size=10 per entrambi, thread_pool_oversubscribe=4 per il database server di Percona e thread_pool_oversubscribe=2 per il database server standard. Il database server standard è partito più veloce a 40 connessioni, ma Percona non considera i numeri bassi di connessioni un buon test dell'efficienza del thread pool. A 2560 connessioni, il database server di Percona ha prodotto 2304 TPS rispetto ai 371 TPS del database server standard, una differenza di 6,2 volte a favore del database server di Percona.
Con un buffer pool di 12G, l'andamento era simile. Il database server standard era più veloce ai punti inferiori di 40 e 80 connessioni, ma a 2560 connessioni il thread pool del database server di Percona ha superato il database server standard. Il livello 32G ha invertito il risultato. Nel caso completamente in buffer, la migliore configurazione del database server Percona è cambiata a thread_pool_size=160 e thread_pool_oversubscribe=2, mentre la migliore del database server standard è rimasta thread_pool_size=10 e thread_pool_oversubscribe=2. Percona interpreta questo come prova che, nel suo server, aumentare innodb_buffer_pool_size può richiedere l'aumento di thread_pool_size per mantenere il thread pool in funzionamento ottimale.
A 32G, il database server standard ha avuto il risultato thread pool più forte: 19.054 TPS rispetto a 15.519 TPS per il database server di Percona, una differenza del 22 percento. Anche la latency ha favorito il database server standard in quel livello. Con il thread pooling disabilitato, Percona riferisce che entrambi i server avevano una p95 latency simile, con il database server standard leggermente più breve. Con thread pool abilitato, la p95 latency del database server standard era circa il 25 percento migliore, a 177 ms rispetto a 235 ms per il database server di Percona. Nei livelli 2G e 12G, tuttavia, il database server di Percona ha mostrato una p95 latency leggermente inferiore rispetto al database server standard.
Per i team IT, la lezione non è che una sola impostazione thread pool sia universalmente corretta. È che connection management, dimensionamento della memoria e forma del workload devono essere testati insieme. I risultati di Percona mostrano che la sua implementazione thread pool è più sensibile a thread_pool_size e thread_pool_oversubscribe, e che tali impostazioni hanno avuto l'effetto maggiore sulle sue prestazioni. Il database server standard ha mostrato variazioni meno drastiche quando quei parametri sono cambiati, e il suo beneficio più chiaro dal thread pooling è apparso solo con numeri elevati di connessioni, come 1280 e 2560. Il database server di Percona ha mostrato benefici molto prima, a 80 o più connessioni.
Questo conta per i sistemi aziendali perché i database sovraccarichi spesso cedono gradualmente prima di fallire in modo visibile: i tempi di risposta aumentano, le code si accumulano e gli utenti delle applicazioni vedono pagine lente prima che qualcuno veda un'interruzione netta. Una configurazione gestita può aiutare rendendo la misurazione una pratica di routine invece che occasionale. Per i lettori che stanno rivedendo le proprie operazioni database, AEU Data provides European cloud and data infrastructure, una base rilevante quando i team devono eseguire servizi dati con una supervisione operativa disciplinata.
La conclusione prudente è eseguire benchmark prima di cambiare le impostazioni di produzione. Testare con numeri di connessioni che somigliano all'applicazione reale, confrontare throughput e p95 latency, e ripetere il test con dimensioni di memoria realistiche. I thread pool possono proteggere un database da concurrency eccessiva, ma questi benchmark mostrano che il loro valore dipende dal server, dal buffer pool e dal workload, non solo dal nome della feature.