Blog · Prestazioni
Perché un client Kafka ci mette un minuto ad aprire un cluster con migliaia di topic
Apri il tuo client Kafka sul cluster di lavoro. Duemila topic, ventottomila partizioni. Clic su «connetti» e poi aspetti: dieci secondi, trenta, a volte minuti, con una rotella che gira su «Retrieving topics…».
Eppure il cluster risponde in fretta. Dov'è il tempo?
Una richiesta o trentamila
Per mostrare l'elenco dei topic basta una richiesta al broker: Metadata. In risposta arrivano tutti i topic, le loro partizioni, i leader e le repliche. Anche con decine di migliaia di partizioni è una risposta di qualche megabyte, che arriva in frazioni di secondo.
Su un cluster aziendale reale con 7 broker, 2.050 topic e 28.319 partizioni, con SASL_SSL e la verifica del certificato, abbiamo misurato 0,77 secondi per la prima richiesta Metadata completa, collegamento, TLS e autenticazione compresi.
Il problema nasce quando il client vuole mostrare anche quanti messaggi ci sono in ogni topic. Metadata non lo dice. Per saperlo servono gli offset di inizio e di fine di ogni partizione, con la richiesta ListOffsets. Ventottomila partizioni, due offset ciascuna, spesso su broker diversi: anche raggruppando le richieste, sono tanti viaggi e tanto lavoro per i broker.
Nel nostro confronto su un cluster in rete con 10.003 topic e 27.026 partizioni, un client che carica i conteggi di tutto ha impiegato 51 secondi prima di mostrare l'elenco. Lo stesso elenco, solo con i nomi, è arrivato in 0,88 secondi. Non è lo stesso lavoro, ed è proprio questo il punto: i conteggi di tutti i topic quasi nessuno li guarda tutti insieme.
I trucchi che fanno la differenza
Chiedi solo quello che mostri
L'elenco dei topic non ha bisogno dei conteggi. Quando apri un topic, chiedi gli offset delle sue partizioni: una richiesta raggruppata, qualche decimo di secondo.
Disegna solo le righe visibili
Un albero con duemila nodi, o diecimila, non va creato tutto. Una lista virtuale disegna solo le righe che stanno sullo schermo, una cinquantina, e ricicla gli elementi mentre scorri. Così il filtro risponde mentre scrivi, anche con decine di migliaia di voci.
Tieni una copia locale
I nomi dei topic cambiano poco. Salvarli in una cache su disco, per connessione, permette di mostrare subito l'ultimo elenco noto quando torni su un cluster, e di aggiornarlo quando lo chiedi tu.
Riusa la connessione
Collegamento, TLS e autenticazione SASL costano più della richiesta stessa: nella nostra misura la prima Metadata ha richiesto 0,77 s, le successive a connessione aperta 0,39 e 0,37 s. Un client che apre una connessione nuova per ogni schermata paga quel prezzo ogni volta.
Cosa controllare se il tuo client è lento
- Il tempo è nel collegamento o nell'elenco? Prova lo stesso cluster con uno strumento da riga di comando: se è veloce lì, il collo di bottiglia è il client.
- Il client calcola i conteggi di tutti i topic all'apertura? Spesso c'è un'opzione per spegnerlo.
- La lentezza cresce con il numero di topic in modo lineare o peggio? Un albero non virtuale si vede subito: si blocca anche lo scorrimento.
Le condizioni delle misure
Metadata: cluster aziendale reale, SASL_SSL e SCRAM, dalla VDI, 16 ottobre 2026, motore della versione 0.1 di Topicup dalla riga di comando, senza cache. Elenco con e senza conteggi: cluster Redpanda in rete con SASL_SSL, mediana di 3 giri, 21 ottobre 2026; il metodo completo e i dati grezzi sono nella pagina del confronto.