Stress Test

Sono qui' alle 16,45 suonate che sto' pensando quale cappero di tram devo prendere domani mattina per andare al consolato per il rinnovo del passaporto (sic), quando una maillina mi casca nella casellina di postina. La maillina in questione dice "914". E cio' e' male.

No, non sto' dando i numeri (non piu' del solito almeno). Una spiegazione e' necessaria.

Tempo addietro avevo narrato delle tristi vicende di $scaffalieponteggi (per la precisione in questa ed in quest'altra storia) e di come gli sviluppatroti in questione avessero allegramente glissato sui problemi causati dalla loro trotaggine. Comunque sia, il foxxuto sito era andato "live" e ci era rimasto per circa 3 settimane, prima che io mi beccassi una bella telefonata alle 3 del pomeriggio che il loro sito era piu' dead che live.

Un controllo nel sito medesimo mi aveva rivelato che il foxxuto coso aveva qualche cosa come 900 connessioni aperte con il database ed apparentemente dopo le 800 il db non pare piu' molto propenso a fornire delle risposte, il risultato e' che l'intero sito va' in coma profondo.

Dopo un pietoso tira-e-molla con $sponteggiesconfali riavviamo TomCat ed il sito si ripiglia un attimo. Io, per non saper ne' leggere ne' scrivere ho sbattuto uno scriptino sul server che ogni ora calcola quante connessioni al database ci sono e mi manda una maillina con il suddetto numerino.

E che ti vedo? Che la maillina comincia col dirmi "8", poi diventa "10" poi "14" poi "20" e va' cosi' in incrementi finche', dopo un paio di settimane e' diventata "532" o giu' di li... ed a quel punto ogni giorno e' buono per un bel riavvio. Poi $sponteggiesponfali pubblica qualche cosa, ottiene un fottio di visite e l'intero coso diventa ancora piu' instabile.

Ovviamente i programmatroti cominciano a blaterare di parametri di configurazione del database e concorrenza nella configurazione del kernel e di ottimizzare il carico di rete et similia. Almeno finche' non mi faccio un giro rapido nel log di TomCat e scopro che il numero di connessioni che resta "appese" corrisponde stranamente col il numero di "NullPointerExceptions" che sono ritornate da una certa parte della loro applicazione. Praticamente quando una certa pagina di errore viene generata la connessione viene lasciata appesa.

I programmatroti nicchiano per un po' poi esclamano trionfanti di aver scoperto un bug in Java (siccomeno...) e mandano una versione "sperimentale" dell'applicazione da mettere sul server di test per verificare. Io installo e poi domando se possono verificare. Ed ovviamente non ricevo piu' risposta alcuna.

Nel frattempo, dopo consultazioni ad alto livello, si e' deciso che quando il numero di connessioni raggiunge i 400 si fa' un bel riavvio del servizio. Riavvio che pero' deve avvenire fuori dall'orario di ufficio per non inficiare il funzionamento del sito ed evitare di danneggiare il ritorno di investimento e tutte quelle balle li' insomma. Il che significa che alle 6 del mattino io mi collego e do' un bel restart. Ma non basta. Perche' la merdacchiosa applicazione tende ad incantarsi durante lo stop, quindi si tratta di dargli uno stop, aspettare un paio di minuti e poi, se ancora li' attaccata ai suoi processi come un gambero alla coda di una balena si va' di Kill -9 finche' non e' morta del tutto e poi si puo' riavviare. Ed a quel punto si vede il numero di connessioni al database scendere a zero. Il che significa che e' quasi impossibile fare uno script schedulato che faccia il tutto ma e' necessario (o meglio: consigliabile) farlo a manella. Il che significa che io sto' accumulando ore straordinarie da compensare e $spongeggiesciuffali sta' accumulando fatture per "lavori fuori orario d'ufficio".

Poi arriva oggi, quando mi arriva sta' maillina con "914" scritto dentro. Ed io ci rimango basito. Come sarebbe a dire 914 connessioni? Ripesco la mail di un'ora fa', dice 106. Da 106 a piu' di 900 in un'ora? E che succede?

Ovviamente il sito e' gia in stato comatoso, cerco di contattare l'unico di $sponteggi che capisce qualche cosa, ma e' gia' schizzato fuori dall'ufficio, quindi mi faccio la solita giga di stop/kill/kill/muoribastardo/restart, mando una mail al succitato SL per avvisarlo del problema e poi e' ora di andarsene a casa. Arrivato a casa faccio un rapido controllo di mail e trovo un'altra maillina che dice 583. Ma che??? Erano 0 un'ora fa'! Che accidenti sta' succedendo?

Il giorno dopo ri-riavvio il foxxuto coso e poi cerco di recuperare il suddetto SL

IO - ...quindi il sito e' andato giu' di nuovo con il solito problema delle connessioni al database e noi lo abbiamo riavviato stamani, solo che volevo sapere se eravate a conoscenza di un qualche cosa che abbia potuto provocare un simile carico sul sistema.
SL - Huuuu... Adesso non mi viene in mente niente, magari dovrei parlare con gli sviluppatori.
IO - Bene. A proposito, come sta' andando con il testing dell'applicazione che dovrebbe sistemare il problema? Che sono almeno 3 settimane che e' stata installata.
SL - Ah, no, di quella roba li' ancora non abbiamo visto niente...
(me pensa: andiamobeneandiamo)

Non che avessi dei dubbi eh! Comunque un paio d'ore dopo mi arriva una bella mail di spiegazione da parte di $sconfali:

La causa dell'elevata attivita' e' che gli sviluppatori sono occupati con un penetration testing dell'applicazione. Il test verra' condotto anche oggi dalle 10 alle 17

Io guardo l'orologio: le 10.45, poi guardo la mia mail, l'ultima diceva "62", passano 15 minuti e la successiva dice "960". Ed il sito e' di nuovo down.

Seguono una serie di mail molto concitate tra me, $sponteggi ed il branco di programmatroti. Ma dico io: tu fai i "penetration testing" su un sito di produzione che ha una versione di applicazione del menga che si incatasta quando riceve troppe connessioni (con troppe=poche)?? E dircelo prima non era il caso? E fare il tuo foxxuto test sul server di test magari? Cosi' verifichi anche se quella patch del ca$$o risolve il problema? Questo non e' un test di penetrazione, questo e' uno "stress" test. Per misurare il mio livello di resistenza allo stress!

Davide
25/04/2011 08:00

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.

13 messaggi this document does not accept new posts

Di Timmy Turner postato il 25/04/2011 11:19

Quand'è che $scansaliipolleggi si deciderà a fare un penetration test sui programmatroti?

-- Timmy Turner

Anonymous coward

Di Anonymous coward postato il 25/04/2011 12:14

uhm, ma fammi capire, fanno un pen-test su una macchina / rete non loro e non vi avvisano? Non è illegale in olanda?

Mboh, Buona Pasquetta D.

-- Anonymous coward

Anonymous coward

Di Anonymous coward postato il 25/04/2011 14:52

Quello che hai scritto mi ricorda le cose che sto studiando in questi giorni...l'ITIL Foundation v3: http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

Teoria bellissima, quello che vuoi, ma o hai un'organizzazione con i controcazzi per fare tutto ciò, oppure...

Perchè lo standard? Perchè purtroppo il buon senso scarseggia, IMHO...

-- Anonymous coward

Vincenzo

@ Anonymous coward Di Vincenzo postato il 26/04/2011 00:17

> Quello che hai scritto mi ricorda le cose che sto studiando in questi giorni...l'ITIL

> Foundation v3:

> http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

> Teoria bellissima, quello che vuoi, ma o hai un'organizzazione con i controcazzi per fare

> tutto ciò, oppure...

> Perchè lo standard? Perchè purtroppo il buon senso scarseggia, IMHO...

Ogni volta che leggo queste storie (e anche ogni volta che sento parlare di ITIL) penso a questo:

http://dilbert.com/strips/comic/2011-04-14/

e rido tantissimo

-- Vincenzo

@ Anonymous coward Di LG postato il 26/04/2011 08:25

Perchè lo standard? Perchè purtroppo il buon senso scarseggia, IMHO...

E' la base di ITIL, dopotutto.

In una organizzazione ITIL-compliant software con problemi del genere, magari esposto su Internet, in produzione semplicemente non ci arriva, e se ci arriva lo si rimuove (a tutela tra l'altro delle infrastrutture condivise). Dopotutto che accordi di servizio vuoi fare fra conduzione e sviluppatori se a fronte di bug bloccanti la risposta tecnica ad un problem (non ad un incident, dove bisogna rispondere in tempo minimo) è "sorveglia e riavvia a mano" o peggio "faccio un patch e poi non la testo".

Detto questo, da letteratura il pen-test "vero" lo si fa senza avvisare la conduzione sistemistica (e lo si fa fare a terze parti), ma solo la dirigenza; questo serve a garantire maggiore realismo alla simulazione. Gli stessi problemi li avrebbe causati uno script-kiddie qualunque che avesse "puntato" l'applicativo.

-- LG

Dusty

Di Dusty postato il 26/04/2011 10:10

In realtà l'hanno fatto apposta.

Se il server non risponde, sicuramente non è bucabile $:\)$

--
Dusty

@ Dusty Di Davide Bianchi postato il 26/04/2011 18:35

Se il server non risponde, sicuramente non è bucabile $:\)$

Il computer piu' sicuro e' un computer spento e non collegato a nessuna rete eh?

-- Davide Bianchi

Michele A.

@ Davide Bianchi Di Michele A. postato il 27/04/2011 11:10

Se il server non risponde, sicuramente non è bucabile $:\)$

Il computer piu' sicuro e' un computer spento e non collegato a nessuna rete eh?

E anche in quel caso basta un cacciavitino per fottersi l'HD (evento non del tutto improbabile visto che già successo :o )

-- Michele A.

Alberto

Di Alberto postato il 26/04/2011 11:28

E' si mi ricordo ancora una meravigliosa applicazione che in fase di test, con due utenti che usavano il sito, andava in palla per il numero eccessivo di connessioni.

Quando abbiamo chiesto lumi ci hanno detto che la usavamo troppo!

Poi quando è andato in produzione si sono accorti che aprivano le connessioni al db ma si erano dimenticati di scrivere il codice per chiuderle.

Controllare prima no è!

-- Alberto

Davide Inglima

Di Davide Inglima postato il 26/04/2011 12:57

Ci scommetto il mio laptop che quei programmatroti non stanno chiudendo le connessioni dentro un blocco finally.

http://blog.shinetech.com/?p=66

http://www.selikoff.net/2008/07/30/finally-closing-jdbc-resources/

L'api di JDBC farà schifo, ma quella é una FAQ così conosciuta che é il primo sbarramento per capire se sei un java developer o un programmatroto.

-- http://limacat.blogspot.com

FDG

@ Davide Inglima Di FDG postato il 03/05/2011 14:02

Stavo per scrivere la stessa cosa. Poi ho visto il tuo messaggio

Ci scommetto il mio laptop che quei programmatroti non stanno chiudendo le connessioni dentro un blocco finally.

-- FDG

dotnette

Di dotnette postato il 26/04/2011 20:09

In confronto a questi ci sente migliori, leggere queste cose può far bene all'autostima!

-- dotnette

Anonymous coward

Di Anonymous coward postato il 26/04/2011 23:55

Ma scusa, hanno un'applicazione che si auto DoSsa e hanno bisogno di ulteriori pen test? O pensano che il debug/test/debug ormai sia fuori moda?

-- Anonymous coward

13 messaggi this document does not accept new posts

Precedente Successivo

Storie dalla Sala Macchine

Stress Test

13 messaggi this document does not accept new posts

13 messaggi this document does not accept new posts