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.
Nella prima parte di questa guida abbiamo visto cosa verificare e modificare nel sistema operativo e sul database server (mysql)
Nella seconda parte vi ho invece presentato delle istruzioni per impostare il server http (Nginx per l’esattezza) e PHP.
Oggi vedremo APC, la configurazione di WordPress e Varnish.
Alternate PHP Cache
Vi consiglio caldamente di installare il la “cache alternativa di PHP” ( APC ), una cache di opcode che è facile da installare e configurare. La Opcode cache salva il compilato degli script PHP nella memoria condivisa per evitare l’overhead dell’analisi e della compilazione del codice ogni volta che lo script viene eseguito. Ciò consente di risparmiare RAM e riduce i tempi di esecuzione dello script.
Per installare APC eseguire yum install php53u-PECL-apc
. È possibile trovare il file di configurazione del programma in /etc/php.d/apc.ini. Tra i parametri presenti c’è apc.shm_size, che specifica la quantità di memoria da utilizzare per APC. Di seguito è riportato un esempio di configurazione che uso su un sistema Linux con 512MB:
extension=apc.so apc.enabled=1 apc.shm_size=64 apc.cache_by_default="1" apc.shm_segments="1" apc.ttl="7200" apc.user_ttl="7200" apc.gc_ttl="1800" apc.optimization = 0 apc.num_files_hint="1024" apc.use_request_time = 1 apc.mmap_file_mask="/tmp/apc.XXXXXX" apc.enable_cli="0" apc.slam_defense="0" apc.file_update_protection="2" apc.max_file_size="1M" apc.stat="1" apc.write_lock="1" apc.report_autofilter="0" apc.include_once_override="0" apc.rfc1867="0" apc.rfc1867_prefix="upload_" apc.rfc1867_name="APC_UPLOAD_PROGRESS" apc.rfc1867_freq="0" apc.localcache="0" apc.localcache.size="512" apc.coredump_unmap="0"
Per una spiegazione completa di queste impostazioni, fare riferimento alla documentazione online.
APC include una pagina web dove è possibile vedere l’utilizzo della cache, tra cui la frammentazione e altre informazioni utili. Copiate /usr/share/doc/php53u-pecl-apc-3.1.9/apc.php nella vostra document root e puntate il browser su questo link.
Una parola di avvertimento: se non si riavvia periodicamente PHP-FPM, la cache potrebbe diventare frammentata, come potrete vedere visitando quella pagina web. Per evitare questo, periodicamente svuotare la cache. Io uso un cron che una volta al giorno chiama una pagina web sul mio sito, che io chiamo apc-clear.php, che svuota la cache. Inoltre questa pagina controlla che l’indirizzo che la sta invocando sia locale in modo che non possa essere chiamato dall’esterno. Ecco il contenuto di apc-clear.php:
<?php if (in_array(@$_SERVER['REMOTE_ADDR'], array('127.0.0.1', '::1'))) { apc_clear_cache(); apc_clear_cache('user'); apc_clear_cache('opcode'); echo json_encode(array('success' => true)); } else { die('SUPER TOP SECRET'); }
E questa è la mia linea di cron:
0 6 * * * /usr/bin/curl --silent http://myserver.com/subdir/apc-clear.php
WordPress
Ora che avete creato l’infrastruttura, è possibile installare WordPress facilmente seguendo guida all’installazione in 5 minuti su wordpress.org. Installate anche il plugin per la compatibilità con nginx ; vi renderà la vita più facile se si utilizzano a short link e permalink.
Dopo l’installazione iniziale è un buon momento per eseguire un primo benchmark delle prestazioni. Pingdom e WebPagetestpossono darvi il tempo totale per caricare il vostro sito WordPress e qualche valutazione ulteriore.
Un plugin in particolare è in grado di migliorare l’esperienza per gli utenti del vostro sito. W3 Total Cache (W3TC) questo plugin può mettere in cache ogni aspetto del vostro sito, riducendo i tempi di download e fornendo in maniera trasparente l’integrazione con un Content Delivery Network (CDN) . Una volta installato tramite la sezione amministrativa del vostro sito WordPress, si aggiunge una sezione Prestazioni in basso a sinistra nel vostro pannello di controllo. W3TC ha troppe opzioni per spiegarle tutti qui, ma vediamo le caratteristiche principali e come è possibile modificare le impostazioni in base alle esigenze del proprio sito.
Nella pagina principale W3TC configurate
Page Cache: Enable Page Cache Method: Disk Basic
Per gli ambienti tipici, basic disk è la scelta migliore, o disk enhanced se siete in un ambiente condiviso. È sempre possibile testare i vari metodi per vedere quali si adattano bene al vostro sito, l’impostazione migliore dipende anche dal tipo di stress da cui si sta cercando di ottimizzare il server. In genere, con la opcode cache , le pagine vengono memorizzati in RAM, quindi sono servite più velocemente, ma l’interprete php si occupa di servire le richieste, cosa che può mettere un alto carico sulla CPU. Al contrario, con la cache su disco, non c’è carico sull’interprete php se una pagina è già in cache, ma la cache del disco è più lenta della RAM.
I valori di default vanno bene per molte altre opzioni, ma modificare i seguenti:
Minify: Enable Minify Mode: Manual Minify Cache Method: Opcode Alternative PHP Cache (APC) Database Cache: Enable Database Cache Method: Opcode Alternative PHP Cache (APC)
You might need to modify these settings, depending on how you use your site. For instance, on my site I use a plugin that for every article read does an update to count the visit. If I enable the database cache, this plugin stop working. In a shared environment, database caching can slow down everything, so test it by enabling and disabling it before you go live.
Object caching increases performance for highly dynamic sites – ones that use the Object Cache API:
Object Cache: Enable Object Cache Method: Opcode Alternative PHP Cache (APC)
Attivare la compressione HTTP e aggiungere le intestazioni per ridurre il carico del server e diminuire il tempo di caricamento del file:
Browser Cache: Enable
se avete una CDN è possibile impostare nei campi specific, dopo di che i file del tema, i media, i CSS e file JavaScript si caricheranno istantaneamente per i visitatori del sito:
CDN: Enable CDN Type: Select your CDN
Configurazione di Page Cache
Tanto lavoro sulla prima pagina. Ma ora andate in Page cache Setting e guardate la cache di preload (precaricamento). Con questa opzione, è possibile riempire automaticamente la cache utilizzando una sitemap in XML. Per fare questo, impostare le seguenti opzioni:
Automatically prime the page cache: Enabled Update interval: 3600 Pages per interval: 100 Sitemap URL: http://yoursite.com/sitemap.xml
Minify Settings
Minify è un’applicazione che accelera il vostro sito, eliminando commenti e interruzioni di riga in CSS, HTML e file JavaScript, combinando i file simili insieme, e li comprime. Con minify, la dimensione dei file è ridotta e quindi il caricamento del sito risulta più veloce, ma la configurazione di minify è la parte più difficile della configurazione W3TC, devi specificare l’elenco di tutti i vostri JavaScript e/o file CSS, ed alcuni di loro potrebbero non funzionare una volta minificati, quindi è una procedura per tentativi ed errori. Se siete a disagio con il guardare il codice sorgente HTML e la ricerca di file CSS e JavaScript, saltate questa sezione. Non c’è bisogno di minify; la cache di pagina funziona bene. Ma è possibile utilizzare minify per spremere ogni bit di ottimizzazione delle prestazioni e la velocità del sito. Per usarlo:
Enable JS minify settings, and in the section “JS file management” mettete tutti i vostri JavaScript. Abilita le impostazioni CSS di minify e nella “gestione dei file CSS” mettere tutti i vostri file CSS.
Le impostazioni di base degli altri tabs di W3TC dovrebbero andare bene. È ora possibile salvare tutte le impostazioni. Dopo il salvataggio, W3TC ti dirà se c’è qualcosa di sbagliato o non configurato.
Ora avete configurato ogni aspetto di W3TC. Per attivarlo è necessario caricare alcune regole in nginx.
Nella scheda denominata Installazione troverete tutte le regole che avete bisogno di caricare nella vostra configurazione di Nginx per consentire di attivare tutte le vostre scelte. La cosa più semplice da fare è copiare le regole di rewrite da questa pagina e incollarle in un file. W3TC suggerirà un percorso, una buona posizione è /etc/nginx/conf.d/w3tc.conf. Tornate al vostro file di configurazione di nginx e aggiungete questa linea poco prima della ultima} :
include /etc/nginx/conf.d/w3tc.conf;
Fate ripartire nginx con il comando service nginx restart.
Ora effettuate nuovamente i benchmark del vostro sito. Le modifiche apportate dovrebbe essere sufficienti per darvi un risultato soddisfacente – ma se si vuole di più, e se non avete paura di una configurazione in più, c’è Varnish Cache, un progetto open source, che è lo stato dell’arte per gli application cache.
varnish
Prima di installare Varnish, siate consapevoli che se si hanno un sacco di pagine dinamiche che utilizzano i cookie ed i form, Varnish sarà inutile, o potrebbe anche causare problemi se si configura male. Se il vostro sito non è così dinamico ed è possibile rimuovere la maggior parte dei cookie, otterrete risultati meravigliosi.
Per utilizzare varnish, è necessario configurare nginx in ascolto sulla porta 8080 in modo che Varnish possa essere messo in ascolto sulla porta 80 e inoltrare le richieste che non sono nella cache al server di backend (nginx). Per fare questo, è sufficiente modificare la direttiva listen del vostro host virtuale in /etc/httpd/conf.d/yoursite.conf da 80 a 8080, quindi riavviare nginx.
Varnish è disponibile nel repository EPEL. Installarlo con il comando yum install varnish
.
Il file di configurazione principale del programma è /etc/varnish/default.vcl. Per fare in modo che Varnish metta in cache un sito web WordPress opportunamente , cancellare tutti i cookie scambiati tra il server e il client ad eccezione di quelli impostati per l’amministrazione di WordPress. Se non si esegue questa operazione, non si riuscirà ad effettuare il login con l’account admin perché le pagine saranno memorizzate nella cache. Questo è un esempio di un file VCL per un sito WordPress:
backend default { .host = "localhost"; .port = "80"; } acl purge { "localhost"; } sub vcl_recv { if (req.request == "PURGE") { if (!client.ip ~ purge) { error 405 "Not allowed."; } return(lookup); } # Remove cookies and query string for real static files if (req.url ~ "^/[^?]+\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)(\?.*|)$") { unset req.http.cookie; set req.url = regsub(req.url, "\?.*$", ""); } # Unset all cookies if not WordPress admin - otherwise login will fail if (!(req.url ~ "wp-(login|admin)")) { unset req.http.cookie; } } sub vcl_hit { if (req.request == "PURGE") { set obj.ttl = 0s; error 200 "Purged."; } } sub vcl_fetch { # Drop any cookies WordPress tries to send back to the client. if (!(req.url ~ "wp-(login|admin)")) { unset beresp.http.set-cookie; } }
Varnish and W3TC
W3TC supporta Varnish , è possibile eliminare la cache ogni volta che si inserire un nuovo articolo per fare questo, nella pagina principale è sufficiente attivare l’opzione “Enable varnish cache purging” e mettere 127.0.0.1 come indirizzo del server Varnish.
Spiegare tutte le direttive del linguaggio di controllo di varnish va oltre quello che posso coprire in questo articolo, ma nella documentazione di varnish potete trovare un spiegazione completa dei comandi e molti esempi.
Dopo aver fatto funzionare Varnish, ripetete i benchmark. Dovreste vedere un altro miglioramento.
La configurazione di WordPress e sua ottimizzazione è un argomento complesso. Spero che questo articolo vi dia del materiale con cui lavorare. Mentre ho anche presentato alcune impostazioni comuni che potrebbe essere perfette per voi, o che potrebbero avere bisogno di essere cambiate, a seconda del vostro hardware, software, o tipo di servizio. Verificare le varie opzioni e ripetete i test fino a trovare il setup ideale per il vostro sito.
Popular Posts:
- None Found
Awesome guide! It’s been a big help with setting up APC on my server.
One question: where did you add the cron? I tried adding it in root with crontab -e, but it won’t run. If I add it in Cronjob Manager within cPanel it gives me the “Top secret”-message. I edited the script now, so it doesn’t check where the request comes from and it works. But I’d like to make it safe anyway… Any suggestions?
I become the user that run nginx, www-data on Debian and i did a crontab -e there.
0 6,18 * * * /usr/bin/curl --silent http://linuxaria.com/apc-clear.php
On my server Nginx is run by “nobody” and I’m not sure how to run a cron under nobody.
In this case you can put that crontab under the root account.
I tried doing that, but that also doesn’t work. That’s why I edited the file to not check for IP.
Forgot to subscribe 🙂