In questo articolo presentiamo un test di performance e tuning per un server LAMP: di seguito vengono esposti alcuni dettagli.Lo scenario preso in considerazione è il seguente:
- page load: da 70 a 140 / secondo;
- utenti virtuali connessi in contemporanea: 4250;
- frequenza: circa 12 milioni di impression giornaliere.
Nota: se il tuo portale possiede numeri di questo tipo puoi valutare la nostra offerta di hosting dedicato oppure cloud hosting.
Il test in questione, di cui presentiamo i primi due casi, è stato effettuato mediante il software HP LoadRunner: si tratta di un sistema per effettuare il test di performance prodotto dall’azienda Hewlett-Packard. Esso può simulare un certo numero di client concorrenti in contemporanea al fine di verificare il comportamento dell’applicazione in contesti molto simili a quelli reali, loggando dettagliatamente la reazione dei singoli componenti (WEB server, database server e via dicendo). L’hardware considerato era invece un HP performance center, mentre l’obiettivo del test era quello di gestire correttamente 4250 utenze concorrenti con un carico di 70 caricamenti di pagina al secondo. Per caricamento di pagina si intende:
– 1 file PHP con accesso a MySQL;
– 4 file JS
– 7 file CSS
– 8 immagini
Dettagli hardware e configurazione LAMP (Linux Apache MySQL PHP):
- Server: Dell R300
- RAM: 2GB (2 x 1GB chips)
- Sistema Operativo: CentOS 5.5
- Application-server Apache v2.2.3 (prefork mode)
- MySQL: v5.0.77
- PHP: v5.1.6
- eAccelerator: v0.9.5.3 con 32 MB di memoria, ottimizzate e con caching
- Banda: 120Mbits
Test 1. Il primo test è stato effettuato con la configurazione di default, incluse le iptable di Linux. L’utilizzo della CPU è stato di circa l’8%, mentre la RAM è stata sfruttata soltanto a metà (50%): MySQL ha dimostrato di essere il collo di bottiglia dell’esperimento, e questo per via degli errori di connessione che si sono verificati. Il target è stato qui soddisfatto al 42% delle aspettative.
Test 2. Il secondo test di configurazione è stato effettuato sfruttando la configurazione huge di Apache, riconfigurando la rete e risettando diversi parametri come riportato di seguito.
<IfModule prefork.c>StartServers 16MinSpareServers 10MaxSpareServers 40ServerLimit 512MaxClients 512MaxRequestsPerChild 8000</IfModule>e successivamente:
[mysqld]# Memory usageskip-lockingmax_connections = 500max_user_connections = 500max_connect_errors = 999999key_buffer = 384Mmax_allowed_packet = 1Mtable_cache = 512sort_buffer_size = 2Mread_buffer_size = 2Mread_rnd_buffer_size = 8Mmyisam_sort_buffer_size = 64Mthread_cache_size = 8query_cache_size = 32M# Try number of CPU's*2 for thread_concurrency (eHound has 4 CPU's)thread_concurrency = 8# Disable Federated by defaultskip-federated[mysqld_safe]log-error=/var/log/mysqld.logpid-file=/var/run/mysqld/mysqld.pid[mysqldump]quickmax_allowed_packet = 16M[mysql]no-auto-rehash[isamchk]key_buffer = 256Msort_buffer_size = 256Mread_buffer = 2Mwrite_buffer = 2M[myisamchk]key_buffer = 256Msort_buffer_size = 256Mread_buffer = 2Mwrite_buffer = 2M[mysqlhotcopy]interactive-timeoutQuesta nuova configurazione impediva al server MySQL di dare gli errori di connessione precedenti, testando il tutto con 58 caricamenti completi di pagina e portando il tutto al 59% del target atteso. La CPU funzionava ancora al 10% ma, in compenso, si è registrato un uso massivo della memoria RAM (fino all’80% circa)
(tradotto parzialmente da questo articolo)
