Tales from the Machine Room


Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Login/Register

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

Previous Next

Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.

13 messages this document does not accept new posts
Timmy Turner By Timmy Turner - posted 25/04/2011 11:19

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

--
Timmy Turner


Anonymous coward By Anonymous coward - posted 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 By Anonymous coward - posted 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 By Vincenzo - posted 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 :D :D :D

--
Vincenzo


LG@ Anonymous coward By LG - posted 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 By Dusty - posted 26/04/2011 10:10

In realtā l'hanno fatto apposta.

Se il server non risponde, sicuramente non č bucabile :\)



--
Dusty

Davide Bianchi@ Dusty By Davide Bianchi - posted 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 By Michele A. - posted 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 By Alberto - posted 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 By Davide Inglima - posted 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 By FDG - posted 03/05/2011 14:02

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

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

--
FDG


dotnette By dotnette - posted 26/04/2011 20:09

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

--
dotnette


Anonymous coward By Anonymous coward - posted 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 messages this document does not accept new posts

Previous Next


This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.


This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.

This site isn't optimized for vision with any specific browser, nor it requires special fonts or resolution.
You're free to see it as you wish.

Web Interoperability Pleadge Support This Project
Powered By Gojira