Chrome Development : RESTful Stress

Negli ultimi mesi sto lavorando sempre più spesso nello sviluppo di applicazioni "service oriented". Sviluppare piattaforme di servizi web è sicuramente una delle cose che preferisco, perchè mi permette di lavorare molto a livello funzionale ed architetturale, e meno sulla parte front-end; quest'ultima...beh, diciamo che non è "nelle mie corde". Mi considero una capra (con tutto il rispetto per gli ovini) nella realizzazione di interfacce uomo macchina e, in generale, in tutto quello che va sotto la definizione di "user experience". In realtà con il "gusto per l'estetica" ci devi nascere; se non se ne è dotati, meglio limitarsi delle cose semplici ed essenziali, lasciando la gloria ai colleghi "web designer"...

Quello che è fondamentale tenere in considerazione quando si lavora ad una piattaforma di puri servizi web, è che è necessario esporre pubblicamente solo le informazioni e le operazioni strettamente necessarie al corretto funzionamento del sistema. I metodi a disposizione dell'utente fruitore finale, devono essere auto-consistenti, atomici, ed esprimere un flusso funzionale completo compreso tra "request" del client, e la "response" del server.

Ma questo non è post di natura "filosofica", quindi veniamo al sodo dell'argomento. Come possiamo "simulare" un'invocazione da un client remoto, recuperare gli eventuali input inviati, e verificare la response emessa dal nostro servizio? Facile: basta creare un semplice client ed eseguire la chiamata all'indirizzo sul quale il servizio è esposto.

Verissimo: è molto facile. Ma quando siete ancora in fase di sviluppo del vostro web service, e vi trovare a dover modificare di continuo i "contratti" dello stesso (nomi dei metodi, dei parametri, o semantica degli stessi), dovete anche essere pronti a modificare il vostro piccolo client per rispettare i cambiamenti operati sul server. Lavoro lungo, tedioso, prono ad errori e certamente molto noioso.

Meglio utilizzare uno strumento esterno, magari realizzato per venire incontro a queste particolari esigenze. Sul mercato ce ne sono di ottimi: il primo a cui ho rivolto la mia attenzione è "Postman", una estensione di Google Chrome che permette di fare tutto quello che ci serve, in maniera tuttosommato immediata e semplice.

Meravigliosa: funziona benissimo e fa quello che mi serve. Questo finchè non mi sono trovato a dovermi confrontare con una esigenza un po' "particolare". Ho un servizio web RESTful che funziona senza problemi; tuttavia noto che i tempi di risposta, a partità di input, cambiano al passare del tempo. Avevo bisogno di iterare la stessa richiesta nel corso di un periodo di tempo piuttosto lungo (un'ora nel mio caso), ma non avevo assolutamente voglia di cliccare il pulsante "Send" di Postman ogni 5 secondi per tutto quel tempo.

Dopo una breve (ed infruttuosa) ricerca su internet, non ho trovato nulla che facesse al caso mio. Per carità: questo strumento ci sarà pure, ma semplicemente non l'ho scovato...oppure diciamo che avevo voglia di capire come funzionavano le "Extensions" e le "Packaged Apps" di Google Chrome, e ho iniziato a lavorare al mio piccolo progetto.

Dopo una breve documentazione sul funzionamento della piattaforma "Chrome", ho iniziato a lavorare sulla mia estensione usando tecnologie "client-side" che ben conosco: jQuery, KnockoutJs, DurandalJs e, per la parte grafica (ricordiamoci che sono solo un "ovino" con il pollice opponibile) Bootstrap e Font Awesome.

L'itegrazione con le API native di Chrome funziona senza problemi, e tutte e tecnologie adottate asservono al mio scopo; nel giro di qualche ora la prima "early version" di RESTfull Stress è pronta e pubblicata sul Chrome Store sotto forma di "Extension".

Come recita il "bugiardino" pubblicato, l'utilizzo è molto semplice: basta inserire l'indirizzo del servizio web da "stressare", selezionare il "verb HTTP" ("GET, "POST", "PUT" o "DELETE"), impostare il numero di iterazioni e l'intervallo tra le stesse, e cliccare sul pulsante "Start".

Un pannello di feedback visualizza il response del server, calcolando i tempi di esecuzione di ciascuna chiamata, e permettendomi di monitorare l'andamento di ogni singola esecuzione e le sue oscillazioni temporali.

Tutto bene fino alla versione 0.0.0.3. Poi, la mia voglia di seguire i consigli di Google che raccomandava l'utilizzo di AngularJs per lo sviluppo su Chrome, mi ha messo nei guai, anche se poi ne sono uscito. Ma questa è un'altra storia...

Buon anno a tutti!
M.

Commenti

  1. Scusa una domanda, ma invece di fare una estensione di chrome non si poteva utilizzare un Middleware opportunamente configurato per fare i test? Così anche da poter avere non solo un test, forse più attendibile ma anche un tracciato completo.

    Grazie.

    RispondiElimina
    Risposte
    1. Ciao Davide.
      La tua è una domanda del tutto lecita; e la risposta è "si", si potrebbero tranquillamente usare anche strumenti 'nativi' per misurare le performance di un servizio REST, siano essi dei Middleware già pronti, oppure di programmi scritti "ad hoc" per l'occasione (es. con .NET o Java).

      Uno degli strumenti nativi che reputo migliore per questo scopo è sicuramente Apache Bench (su Google è il primo risultato). Funziona da linea di comando, ma è perfettamente adeguato allo scopo.

      La problematica che hai giustamente sollevato - ovvero poter misurare un tracciato composto da diverse richieste HTTP - è senza dubbio importante. Tieni conto tuttavia che la misurazione delle prestazioni di un servizio REST si riduce alla misurazione della singola request che fa da "collo di bottiglia". Puoi certamente partire da uno scenario completo di navigazione utente, ma alla fine dovrai fare i conti con la misurazione singola, per individuare quali sono le chiamate HTTP che puoi migliorare per ottenere una esperienza di utilizzo meglio tollerabile dal tuo utente (e sopratutto dal tuo server).

      Per questo scopo dalla versione 1.2 di RESTful Stress è presente la modalità "scenario" con la quale puoi scrivere il tuo tracciato (usando Javascript e Jquery) e misurare una situazione di utilizzo standard.

      Chiudo con questo pensiero. Un'estensione Chrome è certamente il modo più sensato per simulare un caso reale di utilizzo di una piattaforma WebAPI consumata da una Single Page Application (es. AngularJs; Backbone, Ember, ecc) perchè utilizza la stessa componentistica presente in un browser: otterrai lo stesso identico feedback con qualche dato di rilevazione in aggiunta...

      Se sei invece un fautore della soluzione nativa "fatta in casa", ti consiglio di dare un occhio a NodeJs: una delle piattaforme che - IMHO - farà la parte da leone in situazioni di interazione con piattaforme WebAPI nei prossimi 2-3 anni.

      Alla prossima...
      M.

      Elimina
  2. Ciao Mauro :),
    grazie per la riposta e per i consigli, non ero per nulla a conoscenza della modalità denominata "scenario".

    D.



    RispondiElimina
    Risposte
    1. Figurati...
      Spero di esserti stato utile.
      In bocca al lupo per tutto ;)
      M.

      Elimina

Posta un commento

Post popolari in questo blog

RESTful Stress: misurare le performance di un servizio REST

Load tests, Stress tests e performance di un servizio REST

Cancellazione fisica vs cancellazione logica dei dati