JMeter e il load testing che vorrei

Questo è un rant. Ve lo dico subito, così potete non leggerlo.

In questo post voglio lamentarmi di JMeter, non perché sia un cattivo strumento di load testing, anzi, è sicuramente il migliore del panorama open. Il problema è che non è abbastanza.

La complessità delle web application moderne è tale che i test di carico basati su banali sequenze di URL richiamate in serie non garantisce affatto un risultato credibile.

Un tool moderno dovrebbe essere in grado di generare "modelli di comportamento degli utenti", in modo da poter testare carichi reali delle web app, sia partendo da una singola navigazione (con analisi dei possibili comportamenti applicabili in una pagina), sia estrapolando i modelli da log già esistenti di utilizzo. Inoltre, dovrebbe permettere di emulare automaticamente i comportamenti del browser riguardo al caricamento di immagini, css, js, etc. Ad esempio:

• l'utente effettua il login alla webmail (load della pagina di login e tutti gli elementi correlati, chiamata POST per il login, caricamento dell'interfaccia della webmail e relativi elementi correlati)
• l'utente controlla la inbox e clicca su uno dei messaggi (chiamata GET o AJAX per spostarsi alla visualizzazione del singolo messaggio)
• l'utente risponde al messaggio (ancora, chiamata GET o AJAX per caricare l'interfaccia di composizione del messaggio; all'interno di tale interfaccia potrebbero essere presenti altre chiamate al server, ad esempio per l'auto-completion nel campo degli indirizzi)
• l'utente invia il messaggio di risposta, viene ricaricata la inbox (chiamata POST o AJAX che implica anche un test di carico per il server di posta, chiamata GET o AJAX per ricaricare la inbox)
• l'utente effettua il logout (chiamata GET o AJAX, caricamento della pagina di saluto)

Il tool, sostanzialmente, dovrebbe essere in grado di ricostruire le interfacce tra i vari elementi della web app e permettere di costruire i modelli di comportamento senza tener conto dell'implementazione spicciola, ma lavorando su concetti più ad alto livello.

Poi, per replicare un carico reale della piattaforma, si potrebbero creare diversi gruppi a cui applicare diversi comportamenti (ma questo si può già fare con JMeter).

Con una base del genere, poi si potrebbe iniziare a sperimentare sul serio, per misurare le prestazioni del sistema in casi che ancora non si sono verificati (es. pubblicazione in homepage di qualche grosso portale ed "effetto slashdot", pubblicazione di una news "virale" o vero e proprio attacco virale (facebook worms) alla piattaforma per cui la condivisione tra utenti cresce esponenzialmente, etc).

Google+, Android, la pervasività del social

Da quando ho questi aggeggi Android, ho usato i servizi di Google molto più di quanto avessi mai fatto prima. E' strano, per me, perché non amo molto Google, né il cloud. Il cloud non lo amo per nulla, in effetti.
Almeno com'è implementato ora.

Mi piacerebbe - e forse, chissà, col tempo ci arriveremo - poter scegliere separatamente infrastruttura e servizi, per esempio. Vorrei poter scegliere di usare Google+, ma salvare le foto su Flickr. Oppure Smugmug. O, ancora, in raw su Amazon S3 o Dropbox.

Vorrei poter leggere i feed (magari anche offline, grazie alle funzionalità di HTML5) e salvare i bookmark su un servizio di mia scelta, non necessariamente usando Google Reader e Google Bookmarks. Per esempio, io ora uso Fastladder per aggregare i feed e una installazione di scuttle su un server privato per salvare i bookmark.

Sarebbe bello se ci fossero delle API aperte (W3C? Mi senti?) per permettere ai vari servizi di scambiarsi i dati e migrarli quando IO lo decido. E se un giorno volessi togliere tutto? Facile, farei un backup dello storage (Amazon S3? Dropbox? Ubuntu One?) e poi cancellerei tutto.
Milioni di broken link :)
(e di oggetti storati nella cache di Google o salvati su altri milioni di hd nel mondo)

Ormai sono anni che si parla di Semantic Web come di quello che sarà il Web 3.0, ma forse sarà la standardizzazione del cloud e dei servizi che su di esso si appoggiano a costituire il prossimo passo.

E se il problema non fosse solo dalla parte di chi produce informazione?

Negli ultimi giorni, un paio di progetti hanno attirato la mia attenzione.

Il primo è della Mozilla Foundation e riguarda alcune cose su cui sto riflettendo da un po' (mesi), si tratta del progetto Drumbeat, nato per migliorare la creazione e la fruizione delle notizie, in collaborazione con importanti testate (The Guardian, BBC, Al Jazeera).

Il secondo è, invece, del creatore del sito icanhazcheezburger.com, famoso per le serie di LOLcats. Il progetto si chiama Moby Dick e si pone come obiettivo quello di stimolare la discussione su come vengono prodotte e mostrate le news. Ci sono degli schizzi interessanti di un'idea di layout.

A questo punto, però, mi domando: non è che per caso il problema non sia solo dal lato dei produttori di notizie, ma anche da quello dei consumatori?

Ritengo fondamentale, oggi più che mai, la nozione dell'impossibilità di fidarsi al 100% di qualsiasi fonte. Eppure, in un'epoca di virtuale sempre più imperante, è facilissimo vedere che le notizie vengono lette, credute e sbandierate senza neanche una basilare verifica dei fatti. Questo è pericolosissimo per chiunque, basta pensare a come possono reagire le folle (e i mercati) a voci incontrollate diffuse dai grandi media (che sempre più spesso le riprendono, da Internet, senza alcuna verifica).

Forse è importante, prima di modificare l'architettura dell'informazione, creare dei fruitori di informazione consapevoli dei limiti e dei pericoli dell'informazione creata da sconosciuti su Internet.

Questo strumento ha enormi potenzialità, ma come tutti gli strumenti potenti, necessita di una grande consapevolezza per essere usato a dovere.

Togliere la barra degli indirizzi dal browser è una mossa saggia?

Ars Technica dice che in Chrome 13 è disponibile un'opzione per nascondere la barra degli indirizzi e che è uscita un'estensione per Firefox per fare la stessa cosa.

A me sembra stupido e pericoloso: la barra degli indirizzi è fondamentale per controllare su che sito siamo effettivamente, magari verificando lo stato della connessione https. Toglierla significa non disporre a colpo d'occhio di notizie importanti per la sicurezza della navigazione, non mi sembra affatto una buona idea.