In questa serie di articoli riprendiamo il tema delle #WEBPERFORMANCES. Nel dettaglio parleremo Di come configurare JMeter. Vedremo come configurare un cluster di nodi JMeter sul Cloud e molto altro.
Vedremo come configurare il cluster sul cloud di Google (GCP) e come accedere alla console, sul cloud, tramite Remote Desktop.
Abbiamo già affrontato il tema performance in altri 2 articoli:
Come ottimizzare la cache di un sito web?
Perché tutti dovrebbero utilizzare una CDN?
Indice
- Cos’è e a cosa serve un test prestazionale?
- Apache JMeter
- Configurare JMeter cluster su GCP
- Come risparmiare sui costi di GCP
- Accedere alla GUI del cluster controller tramite web browser
- Configurare i parametri di un test prestazionale
- Registrare la navigazione di un test prestazionale tramite browser e utilizzando il proxy di JMeter
- Visualizzare i risultati in un grafico
- JMeter su Azure. Azure Load Testing (JMeter managed)
Gli argomenti da trattare sono tantissimi. In questo primo articolo affronteremo i primi 5 punti.
Let’s go!
Cos’è e a cosa serve un test prestazionale?
Iniziamo con lo spiegare cos’è e a cosa serve un test prestazionale.
Al “lancio” di un nuovo servizio (per esempio un sito web o un e-commerce) sarebbe buona norma conoscere le aspettative nel momento in questo inizierà ad essere usato dai clienti. Per “aspettative” intendo:
- Numero di visitatori giornalieri/orari
- Numero di sessioni per visitatore
- Numero di pagine per sessione
- Tempi di caricamento attesi (KPI) della pagina
- Utilizzo delle risorse (CPU e RAM, per esempio) che ospitano il servizio
Poniamo il caso che il nostro Digital Marketing ci abbia informato che dalle stime si aspetta:
- 100 mila visitatori (contiamo sessioni, per semplificare i conti) al giorno
- che mediamente un visitatore, in una sessione, navigherà 6 pagine,
Con questi dati dovremmo aspettarci di dover erogare 600 mila pagine al giorno. Mediamente, salvo casi particolari (offerte o lanci commerciali), l’80% del traffico è concentrato tra le 09:00 e le 23:00. Ciò significa che avremo 480000 pagine erogate in 14 ore (34300 l’ora, ovvero 570 al minuto, ovvero 9,5 pagine al secondo.). Una pagina però è composta da più oggetti, come per esempio immagini, css, js. Stimiamo che una pagina sia composta mediamente da 20 oggetti. A meno che il nostro sito web non utilizzi una CDN, i 21 oggetti (1 pagina html + 20 risorse statiche), dovranno essere gestiti completamente dal nostro webserver. Avremo quindi che in 1 secondo, i nostri server dovranno erogare un numero di Transazioni Per Secondo (TPS) pari a 9,5 pagine x 20 risorse statiche = 190 + 9,5 = 199,5 TPS. Facciamo 200 per comodità ? 😅
Il digital marketing ci dice anche che l’orario di picco è quello che va dalle 10 alle 12, in cui i visitatori raddoppiano. Avremo quindi 19 pagine al secondo per un totale di circa 400 TPS.
Come facciamo ad essere sicuri che il servizio che stiamo sviluppando sia in grado di garantire risorse utili assicurando tempi di erogazione adeguati a quel volume di traffico?
Apache JMeter
A questo scopo entrano in gioco i tools di performance testing. Uno dei più famosi, oltre che gratuito è JMeter:
The Apache JMeter™ application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions.
What can I do with it?
Apache JMeter may be used to test performance both on static and dynamic resources, Web dynamic applications.
It can be used to simulate a heavy load on a server, group of servers, network or object to test its strength or to analyze overall performance under different load types.
JMeter è un’applicazione java che possiamo istallare comodamente sul nostro PC. Ma, abbiamo detto che dobbiamo testare le nostre pagine con un volume di traffico pari a 19 pagine al secondo; e dobbiamo anche registrare i tempi di risposta. Ce la fa il nostro PC, da solo, a reggere questi volumi, magari per 30 minuti continuativi? E la banda della nostra connessione di rete riesce a reggere il traffico derivante? Forse si. Ma su applicazioni enterprise, dove i TPS possono tranquillamente superare 1000 TPS?
Configurare JMeter Cluster per test distribuiti su GCP
JMeter ci offre la possibilità di creare un cluster di macchine che contemporaneamente chiameranno il nostro servizio, stressandolo secondo i canoni di tempo, pagine e utenti da noi scelto.
Ovviamente questo prevede la necessità di avere a disposizione un certo numero di server che costituiranno il cluster e che si comporteranno da client verso il nostro sito web. A questi ne va aggiunto uno ulteriore che fa da controller del cluster, che ospita il file di configurazione del run prestazionale e che “comanda” gli altri. Pertanto ci serviranno almeno 3 server, che siano sulla stessa VLAN e che possano raggiungere internet. Se non se ne hanno a disposizione on-premises, il modo più veloce per “procurarseli” è quello di configurarli in cloud.
Nei test svolti da noi, lo abbiamo fatto su Google Cloud Platform (GCP). Il servizio IAAS di GCP si chiama Compute Engine. Questo ovviamente ha un costo.
Divaghiamo un attimo all’argomento principale (JMeter) per affrontare il tema costi su GCP. E’ utile farlo in quanto molti sono spaventati dai costi del cloud, nonostante sia ormai d’uso comune “cloud is cheap”. Con alcune accortezze però è semplice risparmiare molti soldi.
I costi di Compute Engine di GCP – come risparmiare
Ovviamente le risorse sul cloud hanno un costo. Costo proporzionale alla potenza elaborativa della risorsa e inversamente proporzionale ai tempi di utilizzo. GCP infatti offre sconti per utilizzo sostenuto o per impegno di utilizzo. In alternativa si potrebbero usare quelle che Google chiama Preemptible Virtual Machines ovvero:
Le istanze VM prerilasciabili sono disponibili a un prezzo di molto inferiore (uno sconto del 60-91% ) rispetto al prezzo delle VM standard. Tuttavia, Compute Engine può arrestare (prerilasciare) queste istanze se ha bisogno di recuperare la capacità di calcolo per l’allocazione ad altre VM. Le istanze prerilasciabili utilizzano capacità di Compute Engine in eccesso, quindi la loro disponibilità varia a seconda dell’uso.
Quindi, Google può spegnere quelle VM in qualsiasi momento. Direi che, visto lo sconto, e visto l’uso che dobbiamo farne, potrebbero fare al nostro caso. Ognuno ovviamente sceglierà secondo le proprie esigenze e disponibilità economiche.
In questo case study useremo delle normali VM, NON preemptible.
TIP: Per chi non lo sapesse Google offre un voucher do 300$ per testare i loro servizi per 90 giorni: https://cloud.google.com/free?hl=it
Vi assicuro che per fare un primo test, 300$ sono molto più che sufficienti. Anzi, forse potreste farne una ventina se non di più.
In ogni caso, se quanto detto finora non è stato sufficiente a tranquillizzarvi relativamente ai costi, e siete ancora preoccupati, ricordo ai più distratti che GCP ci offre un simulatore di spesa, grazie al quale possiamo stimare quanto verrà a costarci un determinato servizio.
TIP: Se spegnete le macchine alla fine del test, non pagherete il loro utilizzo. Continuerete però a pagare qualche centesimo per il mantenimento del disco che ospita le configurazioni
Ancora qualche parola per provare a rasserenarvi. Nella vostra cloud console, avete la possibilità di definire un budget su base mensile, raggiunto il quale i servizi verranno stoppati e non vedrete addebitate ulteriori spese. Se decidete, per esempio, di impostare la spesa a 50 euro mensili, raggiunta tale soglia i servizi (dimenticati accesi) verranno spenti e non la supererete.
Ovviamente, se avete già a disposizione dei server nel vostro datacenter, quanto detto finora decade. Potete tranquillamente utilizzarli, purché questi possano raggiungere internet e siano tra di loro sulla stessa VLAN o quanto meno siano visibili tra loro.
E’ anche possibile eseguire test di carico su sistemi che sono ancora in via di sviluppo e magari non ancora raggiungibili da internet. In questo caso sarà sufficiente che la vostra batteria di server JMeter raggiunga il servizio (probabilmente un VIP attestato su un Load Balancer) che dovrete testare.
In questo articolo non vi mostrerò come creare delle VM sul cloud. Poniamo quindi come assunto che abbiamo già a disposizione le macchine di cui abbiamo bisogno. In questo esempio useremo delle macchine Debian GNU/Linux 11 (bullseye).
Vi riporto però per comodità un utile tutorial che vi mostrerà come fare:
Creiamo il Cluster JMeter
Come detto in precedenza il cluster sarà costituito da 2 tipologie di macchine:
- 1 macchina che sarà il controller del cluster e dalla quale lanceremo il nostro test prestazionale
- N a scelta macchine, comandate dal controller, da cui partirà il traffico che chiameremo Remote Servers.
La prima parte della configurazione sarà comune per entrambe le tipologie di macchine
Passi procedurali comuni tra Controller e Remote Servers
Iniziamo con l’aggiornare i pacchetti del nostro sistema operativo:
sudo apt-get -y updateUna volta terminato l’eventuale update, andiamo a istallare la JDK. Il comando da lanciare potrebbe richiedere un po’ di tempo, che dipende dalla potenza elaborativa della vostra macchina. Ma con uno o due minuti dovreste cavarvela
sudo apt-get -y install default-jdkOra che abbiamo istallato la JKD, andiamo a scaricare e istallare JMeter:
curl -O http://archive.apache.org/dist/jmeter/binaries/apache-jmeter-5.4.tgz
tar zxf apache-jmeter-5.4.tgzA questo punto è necessario creare una chiave che permetterà lo scambio di dati tra il controller e i remote servers. Per farlo sarà sufficiente andare nella cartella bin sotto apache-jmeter-5.4 e lanciare il comando:
create-rmi-keystore.sh
L’output del comando sarà un file chiamato rmi_keystore.jks. E’ fondamentale che questo file sia collocato nella cartella bin di jmeter. Una volta recuperato il file, dovrete copiarlo nella cartella bin di tutte la macchina che compongono il cluster. E’ indifferente da quale macchina del cluster creerete la chiave. L’importante è che prima di iniziare, la chiave sia presente su tutti i server, nello stesso path (apache-jmeter-5.4/bin).
Siamo quasi pronti.
A questo punto, su tutti i remote servers, possiamo lanciare il comando:
./jmeter-server &che farà partire un server jmeter pronto ad ascoltare le direttive indicate dal loro controller.
Sul controller, dovremo configurare i puntamenti ai remote servers. Per fare ciò dovremo modificare il file jmeter.properties presente in apache-jmeter-5.4/bin , inserendo il riferimento ai remote servers:
remote_hosts=10.138.0.2,10.138.0.4che ne nostro caso sono solo 2. Ovviamente il numero di remote servers dipende dalle vostre necessità. Altrettanto ovviamente dovrete inserire gli IP dei vostri remote servers.
A questo punto possiamo far partire JMeter sul nostro Controller, ma riceveremo un errore:
jmeter@jmeter-controller:~/apache-jmeter-5.4/bin$ ./jmeter
Nov 24, 2022 11:37:32 PM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
================================================================================
Don't use GUI mode for load testing !, only for Test creation and Test debugging.
For load testing, use CLI Mode (was NON GUI):
jmeter -n -t [jmx file] -l [results file] -e -o [Path to web report folder]
& increase Java Heap to meet your test requirements:
Modify current env variable HEAP="-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m" in the jmeter batch file
Check : https://jmeter.apache.org/usermanual/best-practices.html
================================================================================
An error occurred:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.rJMeter ci dice che non dovremmo usare la GUI per far girare il test. La GUI in ogni caso ci serve per configurare/registrare il caso da testare. Però non sta funzionando il display remoto.
Se il vostro server Contoller si trova nel vostro datacenter sarà sufficiente fare l’export del display e farlo puntare al server X11 istallato su un PC a cui sia collegato un monitor.
Questo però su GCP, dove sto lavorando io, non si può fare.
Vediamo come risolvere il problema
Configurare JMeter – il display remoto per utilizzare la GUI da GCP
Prima di tutto stoppiamo la macchina su GCP e abilitiamo il remote display device:
Una volta abilitato, possiamo far ripartire la macchina ed eseguire i comandi riportati in una pagina apposita di GCP che ci da anche la possibilità di scegliere l’X-manager che preferiamo. In questo esempio sceglieremo Gnome.
Istalliamo prima di tutto il Debian Linux Chrome Remote Desktop installation package:
sudo apt update
curl -L -o chrome-remote-desktop_current_amd64.deb \
https://dl.google.com/linux/direct/chrome-remote-desktop_current_amd64.deb
sudo DEBIAN_FRONTEND=noninteractive \
apt-get install --assume-yes ./chrome-remote-desktop_current_amd64.debprocediamo quindi ad istallare Gnome:
sudo DEBIAN_FRONTEND=noninteractive \
apt install --assume-yes task-gnome-desktopQuesta operazione richiede tempo. Mettevi comodi, o, se volete, andate a prendere un caffè.
Ancora un paio di comandi e abbiamo finito …
Abilitiamo il remote desktop all’uso di Gnome:
sudo bash -c 'echo "exec /etc/X11/Xsession /usr/bin/gnome-session" > /etc/chrome-remote-desktop-session'Disabilitiamo il display fisico visto che non è presente:
sudo systemctl disable lightdm.serviceOpzionale, istalliamo chrome sul nostro server:
curl -L -o google-chrome-stable_current_amd64.deb \
https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo apt install --assume-yes ./google-chrome-stable_current_amd64.debA questo punto visitiamo la url: https://remotedesktop.google.com/headless
Ci apparirà questa schermata:
Clicchiamo su Inizia. Al passo successivo ci viene chiesto di istallare Chrome Remote Desktop sul computer remoto, cosa che però abbiamo già fatto precedentemente. Clicchiamo quindi Avanti per arrivare qui:
Cliccando su Autorizza, ci apparirà il comando da lanciare sul nostro server. Qualcosa di simile a:
DISPLAY= /opt/google/chrome-remote-desktop/start-host --code="4/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" --redirect-url="https://remotedesktop.google.com/_/oauthredirect" --name=$(hostname)Ovviamente al posto della lunga serie di X, avrete un token. Lanciate il comando sul vostro server Controller su GCP e scegliete un PIN.
Ultimi 2 step.
Tornate in SSH sul server e lanciate i comandi:
sudo passwd $(whoami)Per scegliere una passowd per il vostro utente.
Quindi riavviate il servizio chrome-remote-desktop:
sudo systemctl restart chrome-remote-desktop@$USERA questo punto tornate su https://remotedesktop.google.com/access e come per magia vedrete l’hostname del vostro controller:
Configurare JMeter su GCP – Ci siamo
Cliccate sul nome del server, inserite il PIN scelto in precedenza e otterrete la vostra schermata. Aprite il terminale, andate nel path di JMeter scelto a inizio articolo e lanciate il comando jmeter. Risultato? Potete configurare JMeter accedendo direttamente alla sua console installata su un server remoto sul cloud. Se ora cliccate su RUN cosa otterrete?
la lista dei remote servers, che prima abbiamo inserito nel file di properties, da cui far partire il vostro test di carico. In questo esempio ne abbiamo configurati sono 2. Nulla toglie che, qualora ce ne fosse necessità, potremmo configurarne anche N a piacere.
Qui si conclude la prima parte del filone di articoli dedicata alle #webperformance, ai test di carico, e JMeter
Nell’articolo successivo mostrerò come configurare JMeter per eseguire un test di carico, come registrare la navigazione direttamente tramite il nostro browser utilizzando il proxy di JMeter e infine come visualizzare i risultati del test.
Nel terzo e ultimo articolo parleremo invece di un servizio JMeter managed in SAAS.
Stay tuned!
Condividete se l’articolo vi è sembrato interessante. 😊
Il confronto è sempre costruttivo.
I wish you a funny job
Fabio
Ringrazio Simone Milano che mi ha fornito la sua lunga serie di preziosi appunti che messi in ordine hanno permesso di stilare quest’articolo.
Vi lascio il link di questa newsletter qualora vogliate iscrivervi: https://www.linkedin.com/newsletters/web-in-cloud-6945274376917274624/
Principal Web Solutions Architect – Technology & Architecture Manager @ Accenture – Google Cloud Certified – Professional Cloud Architect
Parla di #web, #cloud, #websecurity, #webperformance e #webarchitecture