Register.it: lo shared hosting dedicato a Joomla
Joomla sotto stress, come si comporta il piano di Register.it
Nelle precedenti recensioni, per eseguire gli stress test al webserver, ho utilizzato il solito un forum phpbb2 con 800 MB dati in database. Dovendo eseguire gli stress test su un piano che prevede l'utilizzo di joomla, ho creato per l'occasione un sito di test, senza installare plugin o temi, ed ho lasciato i contenuti demo di base. Successivamente ho raccolto circa 250 link, relativi ad altrettante pagine del cms, ed ho eseguito gli stress test con siege .
Il primo test riportato è stato eseguito simulando 10 utenti contemporanei:
Transactions: 322 hits
Availability: 86.79 %
Elapsed time: 600.00 secs
Data transferred: 2.56 MB
Response time: 0.99 secs
Transaction rate: 0.54 trans/sec
Throughput: 0.00 MB/sec
Concurrency: 0.53
Successful transactions: 317
Failed transactions: 49
Longest transaction: 3.86
Shortest transaction: 0.07
A differenza di quanto constatato con wordpress, Joomla esegue un numero maggiore di query/pagina ed il limite di 10.000query/orarie non permette di portare a termine neanche gli stessi stress test eseguiti durante la precedente recensione del WP Application Pack; ciò accade perché viene superato il limite imposto e Joomla ritorna errori di connessione al database.
Dopo aver spiegato il problema ai tecnici di Register, il provider ha deciso di eliminare il query limit ed ho potuto finalmente portare a termine gli stress test senza problemi.
Simulazione con 10 utenti contemporanei:
root@siegemachine:~# siege -t10M -i -c10 -d30
** SIEGE 2.68
** Preparing 10 concurrent users for battle.
The server is now under siege...
Lifting the server siege... done.
Transactions: 357 hits
Availability: 100.00 %
Elapsed time: 599.17 secs
Data transferred: 3.09 MB
Response time: 1.01 secs
Transaction rate: 0.60 trans/sec
Throughput: 0.01 MB/sec
Concurrency: 0.60
Successful transactions: 356
Failed transactions: 0
Longest transaction: 8.64
Shortest transaction: 0.07
Simulazione con 25 utenti contemporanei:
root@siegemachine:~# siege -t10M -i -c25 -d30
** SIEGE 2.68
** Preparing 25 concurrent users for battle.
The server is now under siege...
Lifting the server siege... done.
Transactions: 925 hits
Availability: 100.00 %
Elapsed time: 599.21 secs
Data transferred: 7.74 MB
Response time: 0.85 secs
Transaction rate: 1.54 trans/sec
Throughput: 0.01 MB/sec
Concurrency: 1.32
Successful transactions: 913
Failed transactions: 0
Longest transaction: 5.28
Shortest transaction: 0.06
Simulazione con 100 utenti contemporanei:
root@siegemachine:~# siege -t10M -i -c100 -d30
** SIEGE 2.68
** Preparing 100 concurrent users for battle.
The server is now under siege...
Lifting the server siege... done.
Transactions: 3782 hits
Availability: 100.00 %
Elapsed time: 599.13 secs
Data transferred: 30.39 MB
Response time: 0.78 secs
Transaction rate: 6.31 trans/sec
Throughput: 0.05 MB/sec
Concurrency: 4.90
Successful transactions: 3734
Failed transactions: 0
Longest transaction: 9.84
Shortest transaction: 0.06
I risultati degli ultimi test mostrano una situazione nella norma: il server riesce a gestire un buon carico di lavoro e, anche con picchi di 100 visitatori, i tempi di risposta sono più che accettabili.
