HostingServer

Test di performance per server LAMP

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       16
MinSpareServers    10
MaxSpareServers   40
ServerLimit      512
MaxClients       512
MaxRequestsPerChild  8000
</IfModule>

e successivamente:

[mysqld]
# Memory usage
skip-locking
max_connections = 500
max_user_connections = 500
max_connect_errors = 999999
key_buffer = 384M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 32M
# Try number of CPU's*2 for thread_concurrency (eHound has 4 CPU's)
thread_concurrency = 8
# Disable Federated by default
skip-federated
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
[isamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M
[myisamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M
[mysqlhotcopy]
interactive-timeout

Questa 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)

Mostra altro

Ti potrebbe interessare anche

Lascia un commento

Back to top button