Marco Marcoaldi, titolare di Dreamsnet.it, è uno dei migliori sistemisti italiani. Ecco un'intervista specifica su WordPress.
Quando hai cominciato ad occuparti dell’ottimizzazione server per WordPress?
Diciamo che ufficialmente mi sono verticalizzato su ottimizzazioni server per WordPress agli inizi del 2014. In verità avevo maturato un background piuttosto ampio nella configurazione ed ottimizzazione di server UNIX, pertanto mi sono “limitato” ad applicare il mio know how sul trend e le esigenze del momento, WordPress in primis.
Rispetto ad altri CMS, quali sono i punti di forza di WordPress in termini di ottimizzazione della performance?
Rischierò di essere frainteso, ma di base WordPress non si pone come uno strumento che miri alle performance ed alle ottimizzazioni. Il fatto di essere un ottimo strumento per la gestione dei contenuti con ambiti applicativi sfociati in prodotti editoriali di successo con picchi di visite davvero notevoli, ha fatto si che la comunità sviluppasse innumerevoli plugin per venire incontro a queste esigenze , prima singolari ed adatte ai pochi gruppi editoriali degni di nota, successivamente con l’avvento del web 2.0 , dei social e del content marketing virale anche a piccolissime realtà che necessitano di avere performance degne di nota pur con budget ristrettissimi. Tutto questo per dire che i punti di forza di WordPress sono i plugin e la community dietro ai plugin stessi, che permettono a qualsiasi utente (dal novizio, al sistemista skillato) di implementare sistemi di caching veramente performanti tramite l’utilizzo di plugin come ad esempio W3 Total Cache o il meno conosciuto WP-FFPC. A livello minifizzazione troviamo veramente molto sia per CSS che per JS, nonché lo stripping di commenti, la generazione di sprite e l’ottimizzazione di immagini in fase di upload come l’ottimo WP Smush. Ancora una volta : i punti di forza li fanno i plugin.
Molti sviluppatori e clienti non hanno ben chiari i vantaggi che comporta l’uso di un web server come Nginx. Puoi riassumerli?
Diciamo che volendo rispondere a questa domanda dovrò necessariamente pormi in un ottica di “passato prossimo”, dicendo sin da subito che oggi come oggi non è NGINX il Top web server sul mercato, ma GWAN. NGINX sicuramente ha goduto e continua a godere il meritato rispetto laddove uno sconosciuto GWAN o un pachiderma come Apache perdevano seriamente terreno. Diciamo pure che NGINX a differenza di Apache è stato l’unico a dare una soluzione elegante al problema C10k; brevemente : il problema di ottimizzare socket di rete per gestire un elevato numero di clienti concorrenti, come suggerisce l’abbreviazione appunto 10 mila connessioni. L’architettura di Nginx e Apache differisce notevolmente: mentre il primo ha uno schema di funzionamento asincrono, il secondo è di tipo process-based. Nginx e Lighttpd sono probabilmente i due server asincroni più conosciuti e Apache è indubbiamente è il miglior server process-based. il vantaggio principale dell’approccio asincrono è la scalabilità. In un server process-based, ogni connessione simultanea richiede un thread che implica un overhead significativo. Un server asincrono, dall’altra parte, è event-driven e gestisce le richieste in un singolo (o almeno, pochi) thread. Voler entrare nello specifico si dovrebbe impiegare un intero volume fino ad arrivare a concetti a livello di sistema operativo come Mutua esclusione , IPC, Semafori e Deadlock, concetti utili per preparare un esame di Sistemi operativi, ma non adeguati per introdurre NGINX che è tutt’ora fortemente consigliato in ambienti ad alto traffico.
L’ottimizzazione del database è fondamentale. Quali sono i maggiori vantaggi nell’uso di Percona Server invece di MySQL?
Anche per questa domanda debbo necessariamente tirare in ballo l’abilità e labilità con cui nel mondo IT tutto si stravolge dall’oggi al domani. Diciamo che Percona Server è stata (ed è) la più promettente alternativa a MySQL fino al 5.6 offrendo maggiori performance in manierà pressochè indolore a chiunque volesse migrare da Oracle MySQL a Percona Server, essendo esso un replacement drop in appunto con la sostituzione del vecchio motore transazionale InnoDB di InnoBase col nuovo e performance Percona XtraDB. Ciò ha permesso una curiosità iniziale davvero notevole fino al punto da essere preso in considerazione per ambienti di produzione in realtà notevoli. Personalmente credo fermamente nella bontà delle loro soluzioni offerte con licenza GPL che in molti casi riescono a portare soluzione a problemi noti che non hanno soluzioni (se non commerciali) nel mondo Oracle MySQL. Basti pensare ai backup a caldo, in cui troviamo contrapposti MySQL Enterprise Backup (5000 dollari / anno per server), e Percona Xtrabackup, che essendo GPL ed oltretutto Free offre migliorie in ambito di performance e feature rispetto al suo concorrente commerciale. A livello sistemistico diciamo che il know how maturato in ambito MySQL può essere riversato in modo indolore in ambito Percona Server, considerando che abbiamo la stessa sintassi del file di configurazione, pertanto a noi “comuni mortali” non cambia nulla interfacciarci con il DMBS. Ciò che sta “sotto il cofano”, poi è ambito molto ristretto per i pochi addetti ai lavori che ne seguono e partecipano attivamente allo sviluppo, basti pensare che comunque già con l’avvento del nuovo MySQL 5.7 abbiamo ribaltato completamente la situazione con performance nettamente a favore di MySQL 5.7 rispetto all’ormai stabile e veterano Percona Server 5.6. Che all’uscita di Percona Server 5.7 cambieranno di nuovo le carte in tavola con un sorpasso di Oracle MySQL ? Potete scommetterci.
Quali sistemi di caching usi e consigli?
Mi piace scherzare spesso con chi pone questa domanda, rispondendo che non esiste una “ricetta” ufficiale, ma dipende molto dall’utilizzo che il CMS deve avere. In una situazione di real time ad esempio, parole come Caching vengono mal viste, o comunque debbono avere un approccio molto diverso rispetto alla classica testata giornalistica o prodotto editoriale WordPress based. Diciamo che di base, uso un mix di componenti per minimizzare l’overhead a livello di sistema e fornire contenuti nel minor tempo possibile risparmiando cicli di CPU vitali. Brevemente imposto il tutto a partire da un buon caching di PHP utilizzando un Opcode Cacher come Zend OpCache che di base è già fornito ed incluso a partire da PHP 5.6 che ovviamente lascio girare in modalità PHP-FPM in separazione dei privilegi per garantire isolamento ai vari siti ospitati in virtual hosting sulla stessa macchina. Successivamente mi preoccupo di andare a fare un caching spinto a livello DB in modo di evitare continue query in un contesto di ripetute SELECT piuttosto che di INSERT, DELETE o UPDATE. Un buon tuning della configurazione MySQL permette di sfruttare con cognizione di causa ed intelligenza l’hardware alla base (memoria RAM in primis) ed evitare quel fastidioso collo di bottiglia che avviene solitamente a livello DB. Fatto ciò mi preoccupo di cachare le pagine Wordpress e le varie entità come gli oggetti, utilizzando la memoria RAM, in questo caso tramite Memcached, un sistema di caching distribuito in RAM per oggetti, e molto usato nell'ambito di applicazioni web dinamiche per alleviare il carico sul database, facendo in modo di servire alcuni dei dati ai quali l'accesso e piu frequente, direttamente dalla memoria RAM. Allo strato ancora superiore vado ad “inglobare” gli sforzi fatti fino ad ora con Varnish, un accelleratore di applicazioni Web che lavora in reverse proxy. E’ sufficiente installarlo avanti ad un comune webserver per ottenere un miglioramento delle prestazioni davvero notevole anche nell’ordine del 1000% o più. Pensate semplicemente a quanto lavoro deve fare un webserver per caricare ogni pagina tra l’esecuzione del codice Php e le query al db MySql. Varnish non fa altro che salvare in memoria la pagina alla prima richiesta e fornirla direttamente alla successiva. A livello “sperimentale” (ma in produzione in realtà su siti ad alto traffico come Calciatoribrutti o Oltreuomo) effettuo caching su REDIS un key-value store open source residente in memoria con persistenza facoltativa. Ciò permette di incrementare in modo davvero notevole le performance.
Usare un sistema di CDN è importante. Qualche consiglio per districarsi nel mare di offerte di questo tipo di servizio?
Avrei continuato la risposta alla domanda precedente proprio introducendo questo argomento. Va detto che utilizzare un sistema di CDN aiuta a sgravare dalla nostra struttura pesanti compiti, come la distribuzione dei contenuti, siano essi statici o il caching di quelli dinamici. A livello mondiale esistono moltissimi fornitori, dallo storico Akamai utilizzato da BIG del settore come Microsoft, Adobe, Facebook, a soluzioni più modeste come CloudFlare, MaxCDN o Incapsula. Personalmente mi sono sempre focalizzato su CloudFlare e Incapsula considerando la piena validità ed efficacia anche con piani Free oltre che quelli a pagamento. Consiglio di dare vivamente uno sguardo ad Incapsula, che oltre ad avere una configurazione indolore sembra avere maggiore stabilità rispetto a Cloudflare nonché un WAF (Web Application Firewall) più efficace ed efficiente.
La sicurezza di temi e plugin è un punto dolente di WordPress. Come vedi questo problema?
Personalmente mi rendo conto che la sicurezza è un processo e non un prodotto, e se non posso avere il controllo sui processi di sviluppo di temi e plugin mi affido alla sorte e alla competenza di chi sviluppa. Software come Oracle DBMS sono utilizzati quotidianamente in ambienti mission critical come Casinò o Banche, periodicamente sono affetti da bug di gravità mastodontiche che potrebbero mettere a rischio la privacy di utenti e ingenti somme di denaro ? Che facciamo allora ? Togliamo tutti gli Oracle dagli istituti di credito per rimpiazzarli con? Il punto è questo, le vulnerabilità ci sono e sempre ci saranno, Murphy è dietro l’angolo ed è sempre solo questione di tempo. Non posso sapere a prescindere se un tema è vulnerabile o meno, allo stesso modo di come non posso saperlo dei plugin, come non posso saperlo del core di WordPress, o meglio dell’interprete PHP, del DB in cui gira, della rete del fornitore. Vivere in uno stato d’ansia crea solo paranoia che non porta a niente. Vivere in uno stato conscio del possibile problema alle porte ed adottare le best practice in ambito di patching, backup e disaster recovery è l’atteggiamento giusto al fine di salvaguardare il proprio business. Voglio anche sottolineare che molto spesso un singolo plugin possa mettere in ginocchio anche il più carrozzato dei server a prescindere dalla sua configurazione. Un uso moderato di plugin ed un tema snello è sicuramente uno dei requisiti fondamentali per un sito performante oltre che sicuro.
In base alla tua esperienza di sistemista Linux, pensi che in generale i sistemisti conoscano bene i requisiti specifici di WordPress?
Molti dei miei clienti migliori vengono da situazioni di disagio dopo essere stati clienti di sistemisti ed aziende che vendevano prodotti e non servizi. Un’auto che deve correre il Gran Premio di Montecarlo ha bisogno di consulenza ad-hoc. Non si può pretendere di “cucire addosso” il solito “vestito” ed aspettarsi che il cliente sia contento e felice delle prestazioni. Credo che molti sistemisti avrebbero il know how adeguato per mettere in piedi un sistema performante ed ottimizzato, ma che pochi capiscano l’utilità di un lavoro “certosino” che preveda test e bechmark fino a trovare la configurazione ottimale. La fossilizzazione derivata in alcuni casi dalla predominanza di Apache fa si che non si guardi “oltre” a nuove soluzioni per i vecchi problemi, soprattutto laddove le soluzioni “standard” non siano sufficienti ad effetti slashdotting o ad una user experience adeguata alle aspettative del navigatore.
A quale progetto stai lavorando attualmente?
Attualmente mi trovo a lavorare per il Jet Propulsion Laboratory della NASA (ci siete cascati vero ?), scherzi a parte, sto sviluppando con WordPress un portale editoriale a carattere culturale che sta prendendo piede nella mia provincia (www.tychemagazine.it) e allo stesso tempo sto focalizzandomi sull’utilizzo di HHVM in combinazione con Magento nell’attesa di PHP7 che rivoluzionerà le performance in ambito server per tutte le applicazioni PHP e quindi anche il nostro amato WordPress. State pur certi che l’accoppiata PHP 5.7 (detto anche PHPNG o PHP 7) e l’accoppiata MySQL 5.7 faranno faville, portandovi a risultati mai visti prima.