Nel mondo Linux certe rivoluzioni non fanno rumore, ma quando arrivano si sentono eccome. Questa volta non si parla di una nuova versione del kernel, bensì di qualcosa che vive un livello sopra: il runtime .NET. Una pull request pubblicata su GitHub ha acceso i riflettori su una rielaborazione profonda della gestione dei socket su Linux, con un obiettivo preciso: appoggiarsi in modo diretto a io_uring, l’API asincrona introdotta nel 2019 con il kernel 5.1.
.NET integra io_uring su Linux per I/O più veloce e stabile
Per chi lavora con carichi di rete importanti, io_uring non è una novità. È lì da anni, considerata da molti uno dei tasselli più interessanti dell’evoluzione del kernel Linux. Il suo scopo è chiaro: ridurre drasticamente il numero di system call e di context switch, due passaggi che, quando si accumulano su milioni di operazioni, diventano un freno serio alle prestazioni. Meno passaggi, meno overhead, più efficienza. File system e networking sono stati i primi terreni di prova, ma il potenziale va ben oltre.
L’idea ora è sfruttare questa architettura direttamente nel cuore dell’I/O di rete di .NET su Linux. Non un semplice ritocco, ma una riscrittura strutturale del modo in cui i socket vengono gestiti. Nelle prime versioni pubbliche della pull request comparivano anche stime numeriche piuttosto ambiziose. Su Kestrel HTTP/1.1 si parlava di una riduzione del costo CPU per richiesta tra il 15% e il 40%. Con HTTP/2 e flussi multiplexati, il throughput per connessione sarebbe potuto crescere tra il 5% e il 15%.
Microservizi e database beneficiano della nuova gestione
Gli scenari più interessanti emergono però nei contesti ad altissima concorrenza. Server con oltre 10.000 connessioni inattive, come hub WebSocket o SignalR, avrebbero potuto beneficiare di un taglio significativo dell’overhead di memoria, insieme a una latenza di risveglio più contenuta. Nei casi estremi, come game server o sistemi HFT con SQPOLL attivo, le stime parlavano addirittura di una latenza media di submit ridotta di decine di volte sotto carico sostenuto.
Anche il mondo dei microservizi era coinvolto: HttpClient avrebbe potuto vedere una riduzione della latenza per richiesta sulle connessioni brevi, mentre driver per database come PostgreSQL, MySQL e Redis mostravano miglioramenti stimati tra il 5% e il 15% per query. Sul fronte UDP, fondamentale per DNS, server di gioco e telemetria, l’incremento ipotizzato in termini di pacchetti al secondo era ancora più marcato.
Meno overhead e più throughput su Linux
Poi le percentuali sono sparite dalla pull request pubblica. Non perché l’idea sia stata ridimensionata, ma per una scelta di prudenza. Le stime preliminari rischiano sempre di trasformarsi in promesse percepite come definitive. Oggi il testo si concentra sull’implementazione tecnica, lasciando ai benchmark ufficiali il compito di parlare con numeri consolidati.
Se anche solo una parte di quelle proiezioni dovesse trovare conferma nei test reali, Linux potrebbe guadagnare un vantaggio competitivo ulteriore negli ambienti cloud e ad alte prestazioni dove .NET è già ampiamente utilizzato. Non è una rivoluzione annunciata a gran voce, ma uno di quei cambiamenti silenziosi che, nel tempo, spostano davvero gli equilibri.