Storie dalla Sala Macchine


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Login/Register

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

Precedente Successivo

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

18 messaggi posta messaggio
Guido Di Guido - postato il 11/09/2017 09:13 - rispondi

Fammi immaginare i test li facevano su 10 righe?

--
who uses Debian learns Debian but who uses Slackware learns Linux


Cobra78 Di Cobra78 - postato il 11/09/2017 09:31 - rispondi

Da un lato è vero che a volte avere un ambiente di test realmetne comparabile con la produzione è difficile se non impossibile, anche da noi siamo messi così, con ambiente di sviluppo sui pc dei dev, ambiente di staging su un dato ambiente virtuale molto più grosso dei pc dei dev, e produzione che è molto molto molto più grossa dello staging.

 

Per fortuna i nostri dev sono abbastanza svegli da aver chiaro il problema e sapere che è un problema, quelli con cui di solito hai a che fare tu invece....

--
Prendi la vita al minuto, non all'ingrosso.
Sogna come se dovessi vivere per sempre; vivi come se dovessi morire
oggi.


Anonymous Coward Di Anonymous Coward - postato il 11/09/2017 10:59 - rispondi

Qualcuno ha detto "SAP + Accenture"? Dove "Select *" va bene sia per tabelle con 100 righe che per tabelle con 50 milioni di righe?

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.

Sei stato mio collega e non me ne sono mai accorto?blush

--
Anonymous Coward


Manuel Di Manuel - postato il 11/09/2017 13:52 - rispondi

Fantastico.

Un piccolo OT: finalmente sono tornate le storie! mi sono DAVVERO mancate. Grazie Davide!

--
::: meksONE :::


Il solito anonimo codardo Di Il solito anonimo codardo - postato il 11/09/2017 16:08 - rispondi

Ca$$o, sul Commodore Vic 20 di mio cuggino (mio cuggino mio cuggino) girava tutto che è una meraviglia, e su 'sto fantamegacoso con 128 CPU virtuali, 64 terabyte di RAM virtuale e un HD virtuale da 7 zettabyte non gira! Ma cos'è 'sta storia? Insomma, se a gestire 1 dato sul Vic 20 gira bene, cosa vuoi che sia gestire un googolplex di dati qui? cheeky

N. B.: davvero sei caduto dalla padella alla brace, dal tuo precedente lavoro su cui hai pubblicato storie fino al 2012 a questo qui...

--
Il solito anonimo codardo


Pengh@ Il solito anonimo codardo Di Pengh - postato il 22/09/2017 09:12 - rispondi

 

Ca$$o, sul Commodore Vic 20 di mio cuggino (mio cuggino mio cuggino) girava tutto che è una meraviglia, e su 'sto fantamegacoso con 128 CPU virtuali, 64 terabyte di RAM virtuale e un HD virtuale da 7 zettabyte non gira! Ma cos'è 'sta storia? Insomma, se a gestire 1 dato sul Vic 20 gira bene, cosa vuoi che sia gestire un googolplex di dati qui? cheeky



Ma dai, sul mio lappatopi ultimo modello, un Sinclair ZX81, gira ancora meglio con zero dati! E dato che zero è multiplo di tutti i numeri, vuol dire che mi gira un'incredibile quantità di dati.

--
Pengh


Eladamri Di Eladamri - postato il 11/09/2017 17:47 - rispondi

Questo mi ricorda una breve disscussione con un mio Amico Programmatore:

AP"è inutile impiegare tanto tempo a programmare bene una cosa, costa di più un programmatore che l'hardware."

IO"quindi prima o poi ti ritrovi ad avere una serverfarm solo per giocare a campo minato"

AP:" ma tu non capisci, per debuggare e yadda yadda costa di più pagare dei programmatori, allo stesso prezzo aggiungi più hardware"

IO:"quindi se si paga un buon programmatore si risparmia anche sull'hardware"

Il silenzio che ne è scaturito è stato abbastanza eloqunte.

Buona Settimana Big D.

--
Eladamri


Anonymous coward@ Eladamri Di Anonymous coward - postato il 18/09/2017 09:56 - rispondi

Questo mi ricorda una breve disscussione con un mio Amico Programmatore:

AP"č inutile impiegare tanto tempo a programmare bene una cosa, costa di pių un programmatore che l'hardware."

IO"quindi prima o poi ti ritrovi ad avere una serverfarm solo per giocare a campo minato"

AP:" ma tu non capisci, per debuggare e yadda yadda costa di pių pagare dei programmatori, allo stesso prezzo aggiungi pių hardware"

IO:"quindi se si paga un buon programmatore si risparmia anche sull'hardware"

Il silenzio che ne č scaturito č stato abbastanza eloqunte.

Buona Settimana Big D.



Mitico

--
Anonymous coward


Anonymous genius Di Anonymous genius - postato il 11/09/2017 20:32 - rispondi

Per fortuna hai ripreso con le storie, stavo cercando un modo per rintracciarti ed applicare su di te il metodo "Kathy Bates" XD !

--
Anonymous genius


Messer Franz Di Messer Franz - postato il 12/09/2017 07:48 - rispondi

Tutto bello (da un certo punto di vista), ma mi sono perso un passaggio.

Il programmatore si chiamava DE nel racconto  perchè DEficente, sono le sue iniziali (ed ovviamente non puoi dirci il nome) o mi sono perso un passaggio ed oltre a CL, DB ecc si è aggiunto un nuovo acronimo?

ps: coraggio che la pensione è sempre più vicina...è il giorno dopo la crisi di nervi e il ricovero in manicomio...

--
Messer Franz


Davide Bianchi@ Messer Franz Di Davide Bianchi - postato il 13/09/2017 10:57 - rispondi

Il programmatore si chiamava DE nel racconto  perchè DEficente, sono le sue iniziali (ed ovviamente non puoi dirci il nome) o mi sono perso un passaggio ed oltre a CL, DB ecc si è aggiunto un nuovo acronimo?

 

Semplicemente DEveloper

 

--
Davide Bianchi


Mattia Di Mattia - postato il 12/09/2017 19:51 - rispondi

Quella del Laptop in produzione non e' male come idea... dovrei proporla a qualcuno che conosco, che non ci ha ancora pensato ma di sicuro la mettera' in pratica volentieri.

P.S: l'immagine di Gojira ha il link che manda ancora a Gort.

--
Mattia


Guido@ Mattia Di Guido - postato il 02/10/2017 11:05 - rispondi

Che in effetti e' quello che facciamo qui quando vogliamo vedere come gira qualche ottimizzazione su dati reali e non di test (ovviamente solo consultazione, non certo modifica :P )

Quella del Laptop in produzione non e' male come idea... dovrei proporla a qualcuno che conosco, che non ci ha ancora pensato ma di sicuro la mettera' in pratica volentieri.

P.S: l'immagine di Gojira ha il link che manda ancora a Gort.

 

--
who uses Debian learns Debian but who uses Slackware learns Linux


trekfan1 Di trekfan1 - postato il 13/09/2017 07:26 - rispondi

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.

No, tu li hai visti tutti, avevano UN SOLO sviluppatore, ovvero quello che hai visto. Era quello il TEAM!

--
trekfan1


Messer Franz@ trekfan1 Di Messer Franz - postato il 13/09/2017 14:53 - rispondi

 

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.

No, tu li hai visti tutti, avevano UN SOLO sviluppatore, ovvero quello che hai visto. Era quello il TEAM!

Beh, potrebbe anche essere solo uno ma con una grave forma di personalità multipla...se gestisce la sua salute come i suoi programmi non mi parrebbe nemmeno la cosa più tragica che gli possa essere successa*....

 

*Sì, ho ucciso un po' le concordanze verbali e la grammatica in generale ma a va bene lo stesso...

--
Messer Franz


ste Di ste - postato il 13/09/2017 18:31 - rispondi

Ho appena avuto una discussione simile con un collega

riassunto:

massi c'è il cloud, al max aggiungi risorse

angry

--
ste


Tsktsk Di Tsktsk - postato il 14/09/2017 15:19 - rispondi

Sviluppatore e cliente hanno entrambi le loro colpe. Lo sviluppatore avrebbe potuto fare l'applicazione un po' meglio, dando più tempo al cliente prima che l'app giungesse allo stadio dove scalare l'hardware costa più che non riscrivere l'applicazione con tecnologie più performanti. Il cliente avrebbe dovuto sapere che ad un certo punto avrebbe dovuto mettere a budget la riscrittura almeno in parte dell'applicazione perché non si reggono certi carichi con python.

Rimane il fatto che applicazioni come Booking o Twitter hanno attraversato una fase simile. Faccio il caso di Twitter, nato come applicazione Ruby on Rails a cui è stato tirato il collo fino all'estremo finché non si sono convinti a riscrivere larga parte del backend in Scala/Java.

--
Tsktsk


Nik Di Nik - postato il 28/09/2017 15:48 - rispondi

>> CL - Ma perche' cose come Facebook e Booking riescono a gestirsi mole di dati enormi e noi no?

Che tenerezza.... come quelli che venivano a chiedere un sito "come Facebook"...

--
Chronicles of a Broken Heart


18 messaggi posta messaggio

Precedente Successivo


Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gort