Prestazioni Prostazioni
"Ma funziona benissimo sul mio laptop!"
Chi non ha sentito questa frase un paio di miliardi di volte, proferita dall'ultimo sviluppatroto che cerca di giustificare perche' la sua schifossissima applicazione arranca come un gambero nel deserto sul sistema di produzione del cliente, che costa al cliente una piccola fortuna, mentre le millantate performance erano stellari?
Ed il problema tra le "performance percepite" e quelle reali e' solo un piccolo punto della discussione.
Quello che gli sviluppatori ignorano, nella maggioranza dei casi, un po' per pigrizia ed un po' perche' semplicemente non ci sono abituati, e' la capacita' del sistema di "scalare". Una applicazione che funziona relativamente bene su un sistema di test non "scala" bene quando viene caricato di dati ed operazioni che sono un paio di ordini di grandezza piu' grandi di quello per cui era stato sviluppato.
Il problema e' acutizzato quando il 'design' non tiene in considerazione la necessita' di scalare sia orizzontalmente che verticalmente. O quando, di nuovo per pigrizia o per incapacita', gli sviluppatori si ostinano ad usare gli stessi strumenti anche quando diventa ovvio che tali strumenti sono completamente sbagliati per il lavoro in questione.
Quello che succede in queste situazioni e' che gli sviluppatori cominciano ad aumentare le risorse hardware, nella speranza che questo faccia sparire il problema. E, certe volte, aumentare l'hardware porta a certi miglioramenti, ma quando la radice del problema e' un progetto sbagliato (ed una esecuzione schifosa), il problema non viene rimosso, semplicemente nascosto dietro ad una tenda, pronto a saltar fuori di nuovo con il successivo ciclo di release che "spingono" di nuovo sul numero di richieste.
Quello che facevo io quando mi ritrovavo in queste situazioni, era proporre di mettere il suddetto laptop in produzione al posto del sistema preposto. Stranamente nessuno degli sviluppatori coinvolti si sono mai detti soddisfatti della cosa.
E dopo questa performante introduzione, cominciamo con la storia vera e propria.
C'era una volta una societa', chiamiamola $NoiMisuriamoRoba, che era occupata a sviluppare qualche cosa nel campo degli "aggeggi internettizzati". Che roba sono? Sono tutti quei cosi che sono collegati ad internet per motivi futili ed in generale inutili, tipo le lampadine che potete accendere via internet. Il loro piano era di vendere un qualche tipo di "sensori ambientali" che potessero misurare diversi parametri ambientali (temperatura, umidita', pressione dell'aria, luce ambiente etc.) e memorizzare i dati in un qualche archivio centralizzato a cui i vari clienti potesseroo accedere (dietro compenso ovviamente).
L'idea era che una cosa simile avrebbe potuto essere applicata a diverse cose, tipo freezer o ambienti a temperatura controllata in un impianto industriale o in un ufficio in modo da poter controllare l'efficienza dei sistemi di riscaldamento/raffreddamento ed eventuali sprechi di energia (riscaldamento acceso con finestre aperte per esempio). Il che, visto in un certo modo, avrebbe anche potuto essere una buona idea.
Tuttavia, la bonta' dell'idea era in perenne conflitto con la schifosita' dell'implementazione. E stava perdendo. Alla grande.
Prima di tutto, i vari "dispositivi" erano costruiti con un occhio particolare al design e con il classico stile "facciamo finta che siamo Apple" piu' che con un design del tipo "prima di tutto deve funzionare ed essere pratico da usare", ed il risultato erano certe scelte costruttive che non facevano molta impressione (tipo montare il sensore termico direttamente sopra ad un sensore ottico rendendo inutili entrambi).
E poi c'era tutta la faccenda IoShit...
Ovviamente, dato che stiamo parlando di IoS, stiamo principalmente parlando di roba messa insieme alla bene e meglio con una preponderanza di PHP/Pything, una buona dose di Javascript, una robusta quantita' di MySQL e buzzwords varie, un pizzico (ma anche no) di documentazione e NON UNA FOTTUTA LINEA dedicata alla sicurezza del sistema.
Uno dei primi passi di $NoiMisuriamo fu di decidere di ordinare il loro sistema di "produzione". Dato che come ambiente di "test" avevano gia' deciso che quello dei loro sviluppatori andava piu' che bene ed era ampiamente sufficiente. Dei suddetti "sviluppatori" io ne vidi sempre e solo uno, puo' darsi che fosse uno in un gruppo di una dozzina e piu', ma io ne vidi sempre e solo uno.
L'idea di $NoiMisuriamo era di attaccare i suoi sensori ad una connessione GMS cosi' da poter tenere traccia dei dati anche in assenza di una connessione di rete, e quindi essere in grado di vendere questi cosi come dispositivi per il tracking di spedizioni e veicoli. Per poterlof are dovettero combinare i loro "cosi" con altri "cosi" ed aggiungere piu' roba al tutto, il problema e' che le connessioni tra i vari arnesi e la "centrale" si basava adesso su una cosa come l'invio di SMS. Che e' specificamente fornita da tutti provider di telefonia come "best-effor" e senza alcuna garanzia di funzionamento.
Circa un mese prima del "lancio" della cosa, $NoiMisuriamo inizio' una grossa campagna publicitaria, promuovendo il vantaggio del loro sistema di "tracking" a tutti e tutto, dalla spedizione di prodotti e compagnie di consegna fino ai normali mortali curiosi delle condizioni delle loro "case vacanza". Il risultato fu che ancora prima che il sistema venisse in effetti utilizzato vi furono discussioni a proposito della mole di dati che dovevano essere gestiti dall'hardware.
Ora, dato che ne' il cliente ne' gli sviluppatori avevano la minima idea di come il loro sistema avrebbe reagito, la semplice risposta era "e che minchia ne sappiamo". Quindi le discussioni continuarono fino al momento di schiacciare il pulsante e fine li.
Per un po' tutto funzionava a meraviglia, ma non appena il numero di utenti supero una certa soglia ed un certo numero di "features" vennero aggiunte, l'intero sistema comincio' ad arrancare.
Ed immediatamente cominciarono a piovere richieste di "tuning". Ma fu abbastanza chiaro fin dal principio che non si puo' "ottimizare" quello che e' mal progettato. Il che, ovviamente, produsse ulteriori richieste di ottimizzazione e "miglioramenti" all'hardware, fino a che non si arrivo' ad una fase di stallo. Ed a quel punto, ovviamente, vi fu "IL" meeting...
Dalla parte del cliente vi fu il cliente stesso (CL) e lo sviluppatroto di cui ho detto sopra (DE), dalla nostra parte si trovavano, IO (apparentemente l'unico che aveva una vaga idea di ottimizzazione e sviluppo software), il nostro Marketing Man (MM) e DumBoss (DB).
DE - ...ed il sistema funziona perfettamente sul mio laptop, ecco perche' ci domandiamo se c'e' qualche cosa di sbagliato nell'hardware del sistema di produzione dato che le performance non sono lontane da quello che otteniamo sull'ambiente di sviluppo.
MM - Abbiamo gia' aumentato le risorse hardware riservate all'ambiente ma senza un significativo vantaggio, la domanda e' se le scarse performance sono da imputare all'hardware o ad altri fattori al di fuori del nostro sistema.
IO - Posso sapere quanti dati avete nel database di test?
DE - Bhe', e' comparabile con il sistema di produzione...
IO - "Comparabile" che significa?
DE - Non possiamo usare il database di produzione per i test, e' una questione di privacy.
IO - D'accordo, ma che cosa vuole dire "comparabile" in questo caso?
DE - Che intendete dire?
IO - (controllando le mie note) All'ultimo controllo, il database di produzione era di circa 850 Gb, con la tabella "readout" che era la maggiore e conteneva all'incirca 1.5 milioni di righe, seguita dalla tabella "utenti" con circa 250 mila records. Come sono i numeri sul vostro sistema di test?
DE - Be.... non sono cosi' grandi...
IO - Avete provato con un dataset di queste dimensioni?
DE - ...
CL - Possiamo ottimizzare il database?
IO - Non c'e' niente da ottimizzare nel database, specialmente quando non e' usato in modo corretto.
DE - Che vuol dire?
IO - Quello che vedo ripetutamente facendo un semplice scan delle query utilizzate e' che il 90% delle query che vengon processare sono nella forma "WHERE valore IN ...", questo tipo di query forzano un tablescan ogni volta, che a sua volta forza la creazione di una tabella temporanea per la selezione ed il sorting dei dati. Questo capita all'incirca ogni 5 secondi quando qualcuno visita il vostro sito.
DE - Ah, quello e' probabilmente il javascript che rinfresca le viste...
IO - Ed ammazza il database.
DE - Non possiamo aumentare la memoria del database?
IO - Il database creera' lo stesso una tabella temporanea per fare quello che deve fare. E' cosi' che e' progettato ed e' cosi' che le vostre query sono scritte.
DE - Potremmo usare un disco piu' veloce!
IO - E' un disco VIRTUALE.
DB - Potremmo mettere un secondo database affiancato al primo e dividere il carico sui due.
IO - Non migliorerebbe le prestazioni se la divisione non e' fatta dall'applicazione.
DB - Perche' no? Con un load balancer davanti...
IO - Il load balancer non farebbe che bombardare entrambi con la stessa query ogni 5 secondi. Il problema non e' che il database e' lento di suo, il problema e' che la query e' progettata per essere lenta. Se non viene ripensata per trarre vantaggio dall'avere piu' backend l'applicazione sara' sempre lenta.
DE - No, non possiamo ridisegnare la query, vorrebbe dire ridisegnare tutta l'applicazione!
IO - Il che migliorerebbe sicuramente le cose.
CL - Che intendete dire?
IO - Da quello che posso vedere, state usando il database sbagliato. Quello che vi serve e' un'alta velocita' nella scrittura dei dati che arrivano dai vostri sensori e poi un sistema separato che produca le 'views' statiche per le rircerche e la presentazione dei dati. Due sistemi separati dedicati invece che uno solo a cercare di fare tutto.
CL - No, non possiamo fare una roba simile, non e' come abbiamo progettato il sistema.
IO - Vabbe' era un'idea.
CL - Ma perche' cose come Facebook e Booking riescono a gestirsi mole di dati enormi e noi no?
IO - Perche' cose come Facebook e Booking hanno progettato la loro infrastruttura dalla testa ai piedi in maniera tale da partizionare tutto il loro traffico tra CENTINAIA di sistemi senza problemi.
CL - Eh?
IO - Prendiamo Booking per esempio: non hanno UN database, ne hanno circa 400. Ognuno dei quali gestisce una o due tabelle al massimo, ed ognuno dei loro front-end e' progettato per collegarsi ad ognuno dei loro backend ed usare separati backend per scrivere o per leggere. E non parliamo del fatto che praticamente si sono riscritti l'intero linguaggio di programmazione per adattarlo alle loro esigenze. Quello che usano non e' PHP. Non il PHP che scaricate dal sito in ogni caso.
DE - No, non possiamo fare una roba del genere, sarebbe troppo costoso.
CL - Non possiamo semplicemente raddoppiare la memoria del server?
Si, perche' dopo aver ripetuto per un'ora e mezza che aggiungere hardware non e' una soluzione, per forza finiamo con l'aggiungere piu' hardware. Finche' c'e' hardware da poter aggiungere ovviamente.
Non devo dire che il raddoppio della memoria non risolse assolutamente niente vero? E che dopo tutto questo decisero che in ogni caso un ambiente di "test" con lo stesso quantitativo di dati del sistema di produzione non era necessario vero?
Davide
05/09/2017 14:57
)
