Questo è un mio articolo, originariamente pubblicato su Wazi
WordPress, il popolare sistema di gestione contenuti (CMS), è facile da configurare e utilizzare, e ben supportato sia dalla sua comunità che da consulenti professionali. WordPress dipende per il suo funzionamento da uno stack completo che comprende un sistema operativo, database, server web e PHP. Se è possibile ottimizzare questo stack, è possibile migliorare le prestazioni del vostro sito. Ecco alcuni trucchi e best practice per una configurazione in grado di migliorare le prestazioni senza forzare ad un aggiornamento hardware.
Cominciamo con uno sguardo al sistema operativo Linux, database MySQL e web server nginx. Più tardi arriveremo al PHP, alle impostazione e plugin per WordPress stesso, ed il sistema di Cache Varnish , un acceleratore di applicazioni web.
Sistema Operativo
In teoria è possibile eseguire WordPress su un server Windows utilizzando un software come EasyPHP, un pacchetto che permette di usufruire di tutte le potenza e la flessibilità che il linguaggio dinamico PHP offre con Windows. Il pacchetto include un server Apache, un database MySQL, phpMyAdmin, e strumenti di sviluppo per i siti web ed applicazioni.
Ma per la sua licenza, prestazioni e funzionalità di ottimizzazione, utilizzeremo GNU/Linux, e in particolare CentOS 6. Si tratta di una distribuzione Linux stabile e libera basata su Red Hat Enterprise 6, quindi tutti i pacchetti e comandi funzionano esattamente come fanno in RHEL 6. Se si preferisce un’altra distribuzione, come ad esempio Debian o Arch, avrete alcuni file che si trovano in percorsi leggermente diversi o pacchetti con nomi diversi o versione, ma i concetti qui espressi sono applicabili su qualsiasi distribuzione GNU/Linux.
Per quanto riguarda l’ottimizzazione di CentOS 6, e in generale per qualsiasi distribuzione GNU/Linux, ho tre consigli:
- Se il server (reale o virtuale) dove si sta installando CentOS 6 ha più di 3 GB di RAM, installare un sistema a 64 bit, altrimenti scegliere la versione a 32 bit – questo vi salverà un po di RAM.
- CentOS 6 utilizza Ext4 come tipo di filesystem. Ext4 è un filesystem journaled, che registra tutti i cambiamenti, per cui se il sistema va in crash si può recuperare i file interessati. Per impostazione predefinita il timestamp dei file Linux viene registrato ad ogni accesso, il che significa che ogni volta che un processo accede a un file c’è un piccolo overhead per scrivere il timestamp. In un ambiente affollato, la rimozione di questa funzionalità può velocizzare le operazioni.Per rimuovere i timestamp di accesso ai file, modificare il file /etc/fstab e aggiungere, nella linea che si riferisce al file systemdove risiede WordPress, l’opzione
noatimedopo le opzioni di default:
/dev/sda7 /srv ext4 defaults,noatime 1 2 |
- Questo ultimo suggerimento è vero per tutti i software nello stack, ma io lo scriverò solo qui: Assicurarsi di eseguire l’ultima versione del software. Questo dovrebbe essere privo di bug, e così ci salverà da eventuali problemi noti.
Sotto Linux si desidera gestire tutto il nostro stack di software con yum, quindi dovremo aggiungere il repository EPEL (pacchetti extra per Enterprise Linux) al nostro sistema. Il repository EPEL è stato sviluppato dalla comunità di Fedora per fornire ulteriori pacchetti ed add-on per RHEL, il che significa che è compatibile con CentOS.
Per aggiungere EPEL su un sistema a 32 bit, eseguire questo comando come root da una finestra di terminale:
rpm -ivh http://download.fedora.redhat.com/pub/epel/6/i386/epel-release-6-5.noarch.rpm |
Se avete un sistema a 64 bit, eseguire:
rpm -ivh http://download.fedora.redhat.com/pub/epel/6/x86_64/epel-release-6-5.noarch.rpm |
Quando si aggiungono repository extra, tenete a mente che molti includono nuove versioni dei pacchetti che sono disponibili attraverso i canali standard. Ciò può causare problemi, in quanto i pacchetti possono essere aggiornati automaticamente quando non si desidera e creare problemi non previsti. Per attenuare questo problema, utilizzare yum priority e dare al repository EPEL una priorità più bassa rispetto al repository ufficiale CentOS.
Infine, controllare e aggiornare il sistema con:
yum check-update yum update |
Dataabse Server
Il server database è il cuore di ogni sistema CMS. Perché è dove tutti i contenuti e le informazioni di configurazione sono memorizzati, si possono avere un sacco di richieste al secondo, quindi migliorare questo strato può produrre enormi benefici.
Iniziare installando l’ultima versione del server MySQL con il comando
yum install mysql-server |
. Una installazione di default di WordPress 3,2 installa le tabelle del database come MyISAM, quindi per risparmiare un po’ di memoria è possibile dire a MySQL di saltare il caricamento delle InnoDB, un altro storage engine di default di MySQL, questa operazione può far risparmiare fino 100MB di RAM sul server. Ora diamo uno sguardo ad alcuni dei parametri più importanti:
Il key buffer memorizza gli indici delle tabelle in memoria, consentendo ricerche veloci e joins. Il parametro accetta un valore che indica quanta memoria allocare per questa operazione. Vi suggerirò un valore generico di seguito, ma si può regolare in seguito con MySQLTuner.
L’apertura di tabelle può essere costosa. Ad esempio, con MyISAM, MySQL segna campi di intestazione MYI per indicare che una tabella è attualmente in uso. Non si vuole aprire troppe tabelle troppo spesso, è meglio tenerle aperte per le prestazioni. È possibile ottenere questo regolando la table cache a una dimensione che è grande abbastanza per tenere la maggior parte delle tabelle aperte. Iniziate con il numero che ho messo nei profili qui sotto e fate un set up con MySQLTuner nel tempo.
MySQL ha una query cache che memorizza i risultati fino ad una certa dimensione in memoria. La cache è utile per recuperare rapidamente i dati comunemente accessibili quando tutte le altre forme di caching (tra cui reverse proxy, cache della pagina, e le cache WordPress) non sono state richiamate.
Qui ci sono alcune impostazioni di esempi di configurazione per server con dimensioni di memoria differenti, che abbiano in esecuzione MySQL e un server web sulla stessa macchina. Questi dati non sono perfetti, ma sono buoni punti di partenza.
Per Server con 512MB RAM:
thread_cache_size=50 key_buffer=40M table_cache=384 sort_buffer_size=768K read_buffer_size=512K read_rnd_buffer_size=512K query_cache_limit=2M query_cache_size=16M query_cache_type=1 thread_concurrency=2*CPU skip-innodb
Per Server con 1GB RAM:
thread_cache_size=80 key_buffer=150M table_cache=512 sort_buffer_size=1M read_buffer_size=1M read_rnd_buffer_size=768K query_cache_limit=4M query_cache_size=32M query_cache_type=1 thread_concurrency=2*CPU skip-innodb
Per Server con 2GB RAM:
thread_cache_size=80 key_buffer=350M table_cache=1024 sort_buffer_size=2M read_buffer_size=2M read_rnd_buffer_size=768K query_cache_limit=4M query_cache_size=64M query_cache_type=1 thread_concurrency=2*CPU skip-innodb
Una volta che WordPress è stato installato e funzionante da qualche tempo è possibile modificare le impostazioni con una esecuzione di MySQLTuner, uno script Perl che analizza le prestazioni di MySQL e, sulla base delle statistiche che raccoglie, dà consigli su quali variabili si dovrebbe regolare per aumentare le prestazioni. Con MySQLTuner, è possibile ottimizzare il file my.cnf per ottenere fino all’ultimo bit di prestazioni dal vostro server MySQL e farlo funzionare in modo più efficiente.
Popular Posts:
- None Found
