Tales from the Machine Room

ANTTDNW (Another Nice Trick That Does Not Work)

Qui' ci va' una piccola spiegazione, noi abbiamo una specie di web-application, scritta per conto di una societa' che (guardacaso) e' uno dei piu' grossi ISP d'Olanda.

L'applicazione funziona, salvo il fatto che, quando riceve parecchie richieste, rallenta fino a velocita' lumachesche. La societa' di cui sopra domanda soluzioni, ed il branco di pisquani che hanno scritto tale applicazione (di cui CL e' il portavoce) cerca scappatoie.

Chiamato al capezzale della suddetta ciofeca e' stata chiesta la mia opinione ed io l'ho data con la solita franchezza: questa applicazione e' una chiavica immonda e l'unico modo per spremere migliori prestazioni e' quello di mettere una macchina piu' potente o spezzare il carico su due macchine.

Ovviamente la soluzione non e' piaciuta a nessuno (perche' domandano la mia opinione se poi non gli piace mai?). Cosi' CL si e' messo a studiare soluzioni "alternative" che (a detta sua) dovrebbero ottimizzare l'uso dell'hardware senza penalizzare le risorse software... se vi state domandando che cavolo significa non vi preoccupate che non l'ho capito nemmeno io...a me e' sembrato che stesse parlando del moto perpetuo o qualche cosa di simile... mah!

Cosi' dopo qualche giorno CL salta fuori con l'Idea (notare la maiuscola): smandruppare i file di configurazione di Apache in modo tale da fargli credere che le immagini che sono attualmente sotto il controllo dell'application server siano sotto il controllo di apache stesso, cosi' che sia lui a servire tali immagini e non l'application server.

La precedente riunione e' andata piu' o meno cosi':

CL - ...e cosi' utilizzando una semplice modifica ai file di configurazione riusciamo ad ottenere un miglioramento delle prestazione dell'86%...
IO - ci avete provato?
CL - ...he?
IO - dico, ci avete provato a fare ste' modifiche ?
CL - no.
IO - come fai a dire che c'e' un'aumento delle prestazioni dell'86% allora?
CL - ecco... ${cliente} vuole che l'applicazione risponda in X secondi, mentre attualmente risponde in Y secondi, per farla rispondere in X secondi ci serve un'aumento di circa l'86% quindi...
IO - quindi voi *sperate* di ottenere un'aumento simile.
CL - hemmm... piu' o meno...si'...no...circa...
IO - e secondo te il far servire le immagini da Apache invece che da quell'accrocchio pauroso e' sufficiente a raddoppiare la velocita' dell'applicazione?
CL - hemmm... credo di si'.
SL - quindi modificando Apache risolviamo il problema?
IO - no.
CL - si.
SL - (guardando prima me e poi lui) Si o no ?
CL - si.
IO - no.
SL - (guardando me) perche' no?

SL puo' sembrare masochista a domandare a me perche' penso che non funzioni, ma il fatto e' che ha imparato sulla sua pellaccia che quando io dico che qualche cosa funziona, in genere ho ragione, quando dico che qualche cosa potrebbe funzionare, ho quasi sempre ragione, mentre se dico che qualche cosa non funziona ho sempre ragione.

IO - innanzitutto, mi sembra il classico caso di ANTTDNW, in secondo caso, anche supponendo che funzioni, non mi sembra possibile che fornisca un simile aumento di prestazioni.
SL - ANTche?
IO - ANTTDNW, Another Nice Trick That Does Not Work.
SL - E perche' non funziona secondo te?
IO - Perche' sono poco convinto del fatto che si riesca ad imbrogliare in questo modo Apache. Secondo me possono succedere due cose: uno, non cambia assolutamente niente oppure due, non funziona piu' un tubo perche' Apache e l'application server cominciano a litigare tra di loro su chi deve servire cosa.
CL - Lo abbiamo provato in Yugoslavia e funziona!
IO - Lo abbiamo anche provato sul server di test e *non* funziona.
CL - Il server di test non e' un'ambiente di test coerente!
IO - E perche' ?
CL - perche' ci sono piu' applicazioni ospitate li'.
IO - Embe'? Dal punto di vista di Apache e dell'application server e' esattamente la stessa cosa. Piuttosto, se lo avete provato in Yugo, che miglioramento di prestazioni avete ottenuto?
CL - Be', non lo abbiamo provato con l'applicazione vera, solo con una semplice applicazione di prova...
IO - grossa quanto?
CL - hemmm...un solo file...
IO - E questo sarebbe un test esaustivo?
CL - hemmm...no, pero' non abbiamo un server di test su cui fare le prove.
SL - (guardando me) quanto tempo ci metti a fare le modifiche?
IO - 30 secondi.
SL - (guardando il suo disorganizer) dunque... potresti andare la' domani mattina verso le 10 e fare le modifiche, cosi' vediamo subito.. poi potremmo aggiornare la versione dell'applicativo...
IO - e se non risolve niente che facciamo?
SL - cerchiamo di pensare positivo!
IO - Ok, "positivamente", se non funziona che facciamo?
SL - partiamo dal presupposto che funzioni...

La riunione si e' chiusa su questa nota di speranza.

Ovviamente il giorno dopo io sono andato da ${cliente} e, indovinate un po'...NON HA FUNZIONATO...cosi' siamo d'accapo...

CL - ma sei sicuro di aver fatto tutte le modifiche giuste?
IO - senti, se non ti fidi puoi andare la te e farle da solo.
SL - ma secondo te perche' non ha funzionato?
IO - te l'ho detto l'altra volta perche' secondo me non funzionava, l'ho anche messo per iscritto.
SL - hemmm...cosa possiamo fare per risolvere il problema?
IO - t'ho gia' detto anche questo. O questi si decidono a mettere una macchina piu' potente o separano l'applicazione su due server.
SL - no, intendo, per far funzionare sta' cosa.
IO - hummm...quale e' la parte di "non funziona" che non hai capito?
SL - ma ci deve essere un qualche sistema...
IO - no non c'e'.
CL - come e' possibile?
IO - Perche' e' un'Altro Bel Trucco Che Non Funziona.

E su questa nota negativa si e' chiusa la riunione... chissa' se l'hanno capita stavolta?

Davide
10/07/2002 00:00

Previous Next

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.

Previous Next