Al crescere dell’indice da gestire possiamo notare in Vufind un decadime nto delle prestazioni fino al suo completo blocco. La piattaforma presenta più componenti pertanto gli interventi di tuning coinvolgono sia la componente php/apache che gestisce il livello di presentazione che la componente java che gestisce l’indice della nostra biblioteca. Per poter monitorare le performance è buona norma mettere in piedi una procedura di stress test che simuli il carico di produzione, per questo vufind consiglia di usare jmeter o WCAT( Web Capacity Analysis Tool) di Microsoft. Per esigenze ho usato WCAT che, configurato correttamente, permette di simulare n accessi concorrenti con le query più disparati al fine di valutare il comportamento della nostra piattoforma sotto carico. A questo punto scarichiamo WCAT versione 32 bit o 64 bit e configuriamo il nostro client definendo lo scenario tramite un apposito file e il numero di utenti da simulare.
Esempio di file scenario.txt che simula una ricerca libera
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
scenario { warmup = 1; duration = 120; cooldown = 20; transaction { id = "onesearch"; weight = 1000; request { url = "/vufind/Search/Results?lookfor=" + rand("1", "1000000"); secure = false; } } } |
E’ possibile aggiungere altre transazioni per simulare altre ricerche.
Esempio di file settings.txt che simula 30 utenti
|
1 2 3 4 |
settings { virtualclients = 30; } |
A questo punto potete aprire 2 shell cmd per avviare il testing e ipotizzando che il nostro vufind giri sul nostro localhost scriveremo
|
1 |
wcctl -s localhost -t scenario.txt -f settings.txt -c 1 |
|
1 |
wcclient localhost |
A questo punto il client incomincia ad avviare un utente dopo l’altro e a simulare le chiamate configurate. A fine esecuzione sarà possibile consultare il report che indicherà quante richieste sono state effettuate e quante di esse hanno avuto esito positivo. A questo punto per aumentare le prestazioni, se i tempi di risposta non sono soddisfacenti, occorre agire sulla RAM del solr, sul numero di CORE e il tipo di Garbage Collection del nostro server. A questo punto ci viene in soccorso la doc ufficiale di vufind che riporta questo schema di prestazioni per un indice da 8,8 milioni di record:
| CPU Cores (2.7GHz) | Memory (GB) | Garbage Collection | Fresh (Req/s) | Cached (Req/s) |
|---|---|---|---|---|
| 24 | 30 | ConcMarkSweepGC | 327.9 | 705.9 |
| 24 | 30 | G1GC | 93.3 | 167.5 |
| 24 | 30 | ParallelGC | 320.6 | 701.2 |
| 24 | 8 | ConcMarkSweepGC | 205.5 | 780.0 |
| 24 | 8 | G1GC | 64.0 | 147.2 |
| 24 | 8 | ParallelGC | 250.7 | 788.3 |
| 2 | 30 | ConcMarkSweepGC | 81.1 | 161.4 |
| 2 | 30 | G1GC | 65.6 | 123.9 |
| 2 | 30 | ParallelGC | 75.6 | 220.9 |
Il report evidenzia la differenza di prestazione tra le ricerche nuove e le ricerche mantenute in cache.