Migliora il mio disco
Hardware contro Software. E' la solita vecchia storia quando ci sono problemi di prestazioni, o in effetti ogni tipo di problema, che affliggono ogni tipo di sistema informatico complesso.
Il punto e' che quando un sistema va oltre un certo livello di complessita', nessuno capisce piu' esattamente cosa fa cosa e quale parte e' responsabile per quella o questa funzione. Tutti quanti pero' capiscono che se c'e' un problema e' sicuramente nella parte che qualcun altro ha in carico. Deve esserlo. La MIA parte e' assolutamente immacolata e priva di errori! Yup! Niente errori qui.
Ed il guaio e' che per la maggioranza hanno anche ragione.
Il "problema" non e' che la LORO parte ha degli errori, ma piu' precisamente che il modo in cui la loro parte "parla" (o si rifiuta di farlo) con il resto del sistema e'... non molto corretto. E piu' complesso e' il sistema, piu' le varie parti devono seguire un ben preciso protocollo per "parlare" tra di loro in modo che il tutto funzioni correttamente e quando una o piu' parti non si "incastrano" e' un gran casino.
Quindi che succede quando un sistema di questo tipo comincia a manifestare "problemi"? Che tutti quanti entrano in panico ovviamente.
Ed in generale, che tutti cominciano a puntare il dito verso l'hardware, perche' se non altro e' una parte facile da vedere e da gestire.
Ed adesso possiamo parlere di $masterofdisaster, una piccola societa' che si era messa a mettere insieme una specie di tool di data-analysis di qualche tipo.
L'idea era di collezionare informazioni tra varie applicazioni usando degli "analizzatori" e quindi processre il tutto in una interfaccia sciccosa. E vendere il servizio per mucho dinero ovviamente. In sostanza, stavano cercando di re-inventare NewRelic o qualche cosa di simile.
Per fare cio', andarono pazzi con lo "stacking", sostanzialmente incollarono insieme cose di ogni tipo mediante la libera applicazione di Mule e codice NodeJS.
E poi.. disastro.
Dopo circa un mese di operazioni, tutto quanto comincio' a diventare molto ma molto lento... ed anche abbastanza "imprevedibile". Cose che funzionavano e poi smettevano di funzionare senza nessuna ragione apparente.
Ovviamente il primo grido fu "prestazioni". Si perche' meglio fornire risultati sbagliati di corsa che risultati corretti ma lentamente, esattamente come e' meglio prendere decisioni sbagliate ma velocemente che pensarci su e prendere decisioni giuste, no?
Ondepercuicio, un lungo meeting fu organizzato tra noi (hosting) e qualcuno della societa'. Ovviaemnte loro stavano cercando un modo rapido e veloce di aumentare le prestazioni senza "impattare la struttura generale". Aka: noi non vogliamo cambiare il nostro software noi vogliamo cambiare il vostro hardware. Che e' ok per noi, voglio dire, tu paghi di piu' ed alla fine e' il tuo fottuto problema quindi... chissenefotte, ma se l'hardware non e' il problema, e quasi mai lo e', puoi cambiarlo quante volte vuoi e non fara' un cazzo di differenza.
Noi, ok, in effetti IO, cercammo di spiegare che quando hai una pletora di cosi che cercano di parlare l'uno con l'altro e' molto importante tenere sotto controllo il ritardo con il quale queste conversazioni sono effettuate per poter puntare il dito verso il vero problema. Quindi gli sviluppatori del coso dovrebbero essere molto attenti nel
1. aggiungere 'punti di debug' per misurare quanto tempo richiede ogni singola operazione.
2. ottimizzare ogni processo per quanto possibile
3. se salta fuori che uno dei processi non e' tanto buono dal punto di vista delle performance, essere pronti a rivederlo o sostituirlo
e, per ultimo ma non da ultimo
4. non aggiungere merda che tu non capisci solo perche' e' semplice da aggiungere.
Ovviamente potete immaginarvi quale fu la ricezione di queste semplici e credo logiche considerazioni.
Per procedere alla "velocizzazione" del processo una decisione fu presa di raddoppiare l'hardware. Quindi il doppio dei servers, con il doppio della ram, il doppio dei processori... il doppio di tutto. Il che ovviamente risolse... niente. Il sistema passo' da lento ed attivo a lento e molto poco attivo. Ed a questo punto tutti quanti cominciarono a strillare l'uno con l'altro. E con noi ovviamente perche' e' piu' facile strillare contro qualcun altro che contro te stesso.
Come finisce la cosa? Be'... non finisce. Cambia. Cambia perche' la societa' decise che la "successiva iterazione" del software avrebbe dovuto essere testata in modo diverso. Ed adesso dobbiamo scendere nei dettagli di come il software era sviluppato.
Non in un ambiente di test. Almeno non un ambiente di test "regolare". Sapete, quella specie di "copia" dell'ambiente di produzione dove voi provate le vostre cose. No. Quello sarebbe stato troppo facile. No, loro avevano deciso di andare con il modo "agile". Il che significa che ogni sviluppatore aveva una smazzata di macchine virtuali su cui testare il software.
A questo punto il problema era come ognuna di queste macchine virtuali erano "assemblate". Si perche' mentre l'ambiente di produzione era CentOS, niente di meglio che fare l'ambiente di test su... qualche cosa di completamente diverso. Qualche cosa che non avenva ne' gli stessi package, ne' le stesse versioni del software di base ed ogni singolo file di configurazione era diverso ed in un posto diverso. E quindi strillare che non si potevano confrontare gli ambienti.
E quando domandammo come mai avevano deciso di usare quella roba per mettere insieme le loro vm invece di usare quello che usavamo in produzione, la risposta fu che avevano scelto di usare una cosa che fosse 'ottimizzata' per basso consumo di memoria e di disco. E stiamo parlando di un paio di gigabytes su macchine con almeno 16 Gb di ram e centinaia di giga di disco.
Non devo dire che non riuscirono mai a risolvere il problema per davvero, giusto?
Davide
29/08/2018 11:32
