Storie dalla Sala Macchine


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Imposta lingua:en it | Login/Register


Conslutant's Night Blues

Prologo

Taaaaaaanto tempo fa, un paio di UL senza niente di meglio da fare, si sono messi in testa di creare l'ennesima "killer application" (nel senso che lo scopo era di ammazzare qualche sfortunato sysadmin) per "sveltire le operazioni di ordinaria gestione" e cose cosi'.

Questa volta l'Idea (con la 'i' maiuscola) sarebbe stata di creare una specie di 'libreria digitale' in modo da poter archiviare immagini, fotografie, video e chi piu' ne ha piu' ne metta e potervi accedere da ogni ufficio.

Ovviamente, nessuno dei due 'padrini' dell'Idea aveva la piu' pallida idea di come farla una roba del genere.

Entra quindi in scena Conslutante numero 1 (c1), il quale, con la modica spesa di una barca di soldi, produce in un periodo di un'annetto circa un mostruoso accrocchio che usa un database full-text per gestire le sue cavolate poi, mediante l'astuto uso di una barcata di file batch, genera uno sproloquio di pagine HTML statiche che sono quindi scaricate su un malcapitato server web (installato, tanto per fare, dall'altra parte del pianeta Terra) per l'uso generale.

Chiaramente uno dei difetti di tale arnese e' che risulta essere lento come la fame (grazie alla qualita' della connessione di rete a cui il server web e' attaccato) ed aggiornato ogni morte di papa (dato che l'aggiornamento e' una procedura completamente manuale). Se poi si aggiunge il fatto che l'intero arnese e' installato su un solo pc e che tale pc ha un serio bisogno di una reinstallazione...

Passano alcuni anni, e qualcuno decide che tale arnese richiede un'aggiornamento. Un altro paio di UL decidono percio' di prendere in mano la situazione... qui' finisce la favola e comincia la storia...

UL1 - ...quindi l'aggiornamento dell'applicazione risultera' in una maggiore efficienza nell'uso delle risorse e blah blah blah yada yada yada...
IO - (interrompendolo) Si, tutto bello, ma sta roba chi la dovrebbe fare?
UL2 - Ma abbiamo questo superefficiente conslutante...
IO - Non e' che e' lo stesso dell'infame "progetto ldap" ?
UL1 - Beh', si', ma che c'entra?
IO - Come che c'entra??

Evidentemente i precedenti (penali, nel senso di 'azzate) non vengono tenuti in considerazione. Cosi' i due conslutanti cominciano l'annoso lavoro di ricostruzione dell'accrocchio... in un'accrocchio diverso.

Un bel di', vengo informato che l'accrocchio e' pronto per essere installato sul server di produzione.

Quale server di produzione? Domando io. "Il" server di produzione, mi viene risposto. QUALE server di produzione??? ri-domando io.

Si perche' ovviamente non hanno pensato che un server di produzione deve essere acquistato per lo scopo. Viene recuperato un server di straforo (convenientemente 'donato') e l'applicazione viene installata.

Un paio di scalognati utenti vengono prescelti per testare la meraviglia ed immediatamente cominciano a piovere le lamentele: e' piu' lento di prima. I due conslutanti ovviamente cominciano ad incolpare il server di recupero. Prima di tutto mi bombardano con spezzoni di 'errata' e frammenti di 'kernel bug report', a nulla valgono le mie rimostranze che "quel bug si riferisce ad un driver per un componente che sul server non e' installato e comunque per un kernel che noi non usiamo"...

Dopo un paio di meeting, decido di dare un'occhiata al server piu' da vicino. E noto un paio di cosucce... prima di tutto, ogni volta che la meraviglia della tecnologia moderna deve mettere insieme una pagina, vengono fatti una media di 12000 (dodiciMILA) accessi al database, per una ricerca "semplice", gli accessi salgono a circa 26000 (ventiseiMILA), una query complessa sfiora i 50000.

Le mie rimostranze non vengono accolte molto bene, i due conslutanti sostengono che il database non e' "ottimizzato". Alla mia richiesta di come ottimizzarlo ovviamente non ottengo nessuna risposta.

Finalmente, dopo un numero spaventevole di di mail, oggi siamo in riunione con i due conslutanti ed i due UL (insomma i "soliti sospetti").

IO - (finendo di mostrare i grafici con gli accessi al database) ...quindi, anche se il server fosse due volte piu' veloce, il numero di accessi al database risulta sempre essere il collo di bottiglia. Riduciamo questo ed il miglioramento sara' immediato.
UL1- Ma come e' possibile ridurre gli accessi al database?
IO - Scrivendo l'applicazione in modo decente.
C1 - L'applicazione e' scritta perfettamente!
IO - Una applicazione che ha bisogno di 12000 accessi per presentare la home page non la considero scritta perfettamente.
UL2- (con la faccia e l'entusiasmo della domenica) Comunque non c'e' problema! Il nuovo server e' in arrivo!
IO, C1 e C2, tutti in coro - QUALE NUOVO SERVER???

Ebbene si'! Il pisquanozzo e' partito in tromba ed ha acquistato un server nuovo di trinca, anzi, ne ha acquistati DUE! Avendo sentito parlare di 'clustering'... Con un'enclosure dedicata per il Raid!

IO - (guardando la documentazione) ...e quando dovrebbe arrivare questa meraviglia?
UL2- In una settimana o giu' di li'. Questo dovrebbe risolvere tutti i nostri problemi (guardando C1 e C2) Giusto?
C1 e C2 - (guardandosi tra loro con sguardo sofferente) ...certo... come no...

Ora, se non fosse che UL2 e' completamente rimba, sarei tentato di credere che il server nuovo e' una palla per far cagare sotto C1 e C2. Devo comunque dire che vederli in preda alle convulsioni, pensando a quando il server nuovo dimostrera' che la loro applicazione e' una chiavica totale, e' stato divertente... cio' che mi preoccupa e' che saro' io a dovermelo smazzare dopo...

Davide
17/01/2009 14:21

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.

Nessun messaggio this document does not accept new posts

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 Gojira