Vita da tecnici

Qualche giorno fa ho avuto una discussione, a volte anche abbastanza accesa, su come ottimizzare uno specifico modulo di un prodotto in fase di sviluppo.

Problema: da un nodo centrale si devono contattare n server comporaneamente (tramite webservice) per poi assemblare le risposte ottenute. Le richieste dal nodo centrale sono originate da una operazione compiuta dall’utente per cui ci possono essere m richieste che originano n*m richieste remote.

La persona (mooolto tecnica) che si era fatta carico del problema sosteneva una poszione di questo tipo: le operazioni di invocazione non sono altro che attesa su una socket, se al posto di generare n*m thread uso i meccanismi di comunicazione non bloccante sulle socket (non blocking I/O) risparmio risorse e l’applicazione è più scalabile.

Il ragionamento sembra filare, ma c’è un problema di fondo (più di uno in realtà, ma quello veramente importante è uno solo):

Di quanto l’applicazione è più scalabile? quanto costa in termini di complessità di codice usare il non blocking I/O rispetto ad un “semplice” thread?

Senza una misurazione effettiva si rimane nell’ambito delle opinioni, con un test case (anche molto semplice) ci si muove nel mondo dei fatti.

Per cui la prima cosa che ho chiesto è: quanto migliora con il non blocking I/O in termini di prestazioni e di utilizzo di memoria?

Dopo vari test case, la conclusione è stata che l’applicazione di test (simulando un carico circa 1000 thread) multithtread e quella con non blocking I/O avevano circa le stesse prestazioni (qualche punto precentuale a favore del multithread) in termini di prestazioni e quella con i thread occupava diversi mega di memoria in più (qualche decina quando c’era un numero consistente di thread). La macchina di produzione sarà dedicata all’application server ed avrà 4GB di RAM. Cosa sono 2o mega in più, specialmente considerando che stano alle previsioni attuali sarà difficilissimo superare i 300 thread? Soprattutto il codice multithread risulta più pulito e più facile da manutere in futuro (considerato anche il fatto che non tutto sanno manegiare a dovere le api bel non blocking I/O).

Conclusione: prima di dire è più veloce/scalabile/etc  questo rispetto a quello è necessario avere dei fatti a supporto, perchè finchè ci si limita alle opinioni (per quanto sensate e intuitivamente corrette) non si può essere veramente sicuri di quello che si dice. La semplice condivisione di un test case vale più di mille parole ed è infinitamente più istruttiva sia per chi lo scrive sia per chi lo legge. Anche perchè  le applicazioni sono spesso complesse e devono tenere conto del fatto che ormai l’hardware è sempre multiprocessore (e lo sarà sempre di più); per cui il miglioramento presunto va inquadarato in ottica costi/benefici (e i costi, a meno di errori grossolani, ci sono quasi sempre). Il mio ultimo pensiero va a quel team di sviluppo (di un sistema operativo) che era felicissimo di aver ottimizzato il tempo di esecuzione di una API del 20%; quando il loro responsabile vide il loro lavoro li guardò stupito: avevano ottimizzato il ciclo idle del sistema

Alla prossima.