Le performance e la scalabilità sono punti chiave per ogni applicazione relativa ad imprese, e ciò è particolarmente vero per Magento. Solitamente, i nostri clienti sono favorevolmente colpiti dalle caratteristiche e dall’estendibilità di Magento, ma ci si preoccupa se possa essere adatto a diverse migliaia di ordini giornalieri o a un vasto catalogo.

Questa preoccupazione è tale solo in parte, perchè le prime versioni di Magento avevano dei problemi di performance, e i concorrenti utilizzavano questi argomenti a favore dei loro prodotti. Tuttavia, è vero anche che portare Magento ad essere veloce e scalabile richiede la conoscenza di tutto il software sottostante – come la configurazione PHP e quella del web server – e ha bisogno di un piccolo sviluppo personalizzato, al fine di ottimizzarlo ai propri specifici usi. Questo articolo verte su come ottenere il massimo da un solo servere o da una macchina virtuale; come vedrete, questi consigli potranno portarvi già molto lontano.

Vision lavora prevalentemente su grandi progetti e quest’aspetto coinvolge un consulto su infrastrutture, performance e cose del genere. Ci sono due problemi: il primo è che tutti voglio avere il tempo di caricamento più breve possibile che è ciò che si intende con performance. Amazon e Google hanno fatto alcune ricerce in proposito e hano trovato che 100 millisecondi di ritardo possono diminuire il tasso di conversione. La performance è importante sia per i grandi progetti che per i piccoli, quindi cercheremo di andare in profondità.

Il secondo problema è, letteralmente, la scalabilità: il mio sito rimarrà veloce anche quando ci sono dei visitatori? Pensare a questo è come pensare al corrispettivo digitale dello stare in fila alla cassa. Se sei l’unico consumatore, puoi andare e pagare direttamente – quindi la performance è buona. Ma se ci sono molti consumatori, ognuno di essi deve aspettare il proprio turno; in altre parole un singolo cassiere non è adeguato ad un grande supermercato.

Chiaramente ci sono due conseguenze – se fornisci al cassiere una cassa migliore, la performarce migliorerà e le code si ridurranno leggermente. Ma anche con casse migliori ci vorrà molto tempo e, prima o dopo, si avrà bisogno di un secondo cassiere. Nel mondo Magento, questo significa trasferire alcune parti del negozio su un server separato, o anche su un sistema di cluster completamente sviluppato, Mettere in piedi un sistema di cluster è difficile e richiede tempi lungi. Non vedremo qui come fare. Il nostro obiettivo sarà ottenere la scalabilità e le performance migliori possibili da un singolo server dalle dimensioni adeguate.

Essenzialmente, vi mostrerò i passaggi che compiamo alla Visions quando facciamo consulenza di infrastrutture in questi casi. Per prima cosa vi mostrerò alcune piccole messe a punto di configurazione che vi permetteranno di raggiungere piccole semplici vittorie. Successivamente daremo un’occhiata a due strumenti che vi aiuteranno a capire da dove vengono fuori i tempi di caricamento di Magento e a stimare quanto è scalabile la vostra attrezzatura.

Quando avrete i numeri, vorrete migliorarli. Vedremo come migliorare tre valori atraverso l’uso di FastCGI al posto di mod_php, l’abilitazione del Block Caching per il catalogo selezionato e per i blocchi CMS, e persuadere i propri designer a ridurre le richieste HTTP per ogni pagina caricata

Semplici Vittorie

Assicuratevi che la cache di Magento sia abilitata

MySQL possiede una cache delle query, che può salvare i risultati delle query SELECT per un piccolo periodo di tempo. Quanti benefici si ottengando dalla cache delle query dipende fortempente dal tipo di applicazione che si usa – questo è il motivo per cui la cache delle query non è abilitata di default. Tutti i test hanno dimostrato che, quando è presente in Magento, se ne guadagna in ulteriore scalabilità. Per abilitare il caching delle query, andate a my.cnf e impostate le seguenti opzioni nella sezione [mysqld]:

query_cache_type=1
query_cache_size=64M

Salvate i cambiamenti e riavviate il server MySQL

Ci sono anche altre ottimizzazioni che possono essere fatte a livello di MySQL, ma si allontanano dall’obiettivo di questo articolo. Date un occhiata ai capitoli 6 e 7 della seconda edizione di “’Reillys High-Performance MySQL” per avere un eccellente guida. Gli autori scrivono anche su un fantastico blog a questo proposito all’indirizzo http://www.mysqlperformanceblog.com/2006/07/27/mysql-query-cache/.

Abilitare Expires Headers

I browser usano ampiamente il caching e salvano una miriade di elementi, inclusa una versione locale del sito in modo da non servirsi della della cache del servere alla prossima richiesta. Questa mossa può essere utile per velocizzare leggermente i tempi di caricamento. Il problema del browser è sapere quando un file può essere o non può essere servito dalla cache. Per risolvere questo problema, i browser si affidano a due header HTTP: Expires e Cache-Control.

Il file di Magento default .htaccess li configura automaticamente in base ai consigli di Yahoo sulla performance, ma non li abilita di default. Per abilitarli bisogna aggiungere le seguenti righe al propria configurazione del server Apache (di solito si trova in /etc/apache2/apache.conf):

? <IfModule mod_expires.c> ExpiresActive On </IfModule>

Se non si ha l’accesso alla configurazione del server, queste righe possono essere aggiunte al file di Magento .htaccess – ma c’è bisogno di stare molto attenti quando si aggiorna Magento che i cambiamenti fatti non vadano persi.

Usare APC come backend della cache:

Di default, Magento conserva i dati della cache nel file di sistema. Di solito questa soluzione funziona per i siti piccoli, ma al crescere delle riichieste ottenute si rallentano i tempi di lettura e scrittura del file di sistema. Questo accade specialmente se si è sistemato il proprio Magento su un networked drive, come NFS, che è più lento di un disco locale. Se si sta usando APC, il problema si aggrava maggiormente a seconda dell’architettura dell’APC.

Se si usa APC, solitamente si possono migliorare le capacità produttive di Magento conservando i dati della cache su APC invece che sulla cache stessa.
Apri il file app/etc/local.xml e aggiungi le linee seguenti:

<global> <cache> <backend>apc</backend> <prefix>MAGE_</prefix> </cache> </global>

Dopo aver salvato i cambiamenti, ricordate di aggiornare la cache di configurazione attraverso il pannello di controllo

Abilitare il chaching delle query di MySQL

MySQL possiede una cache delle query, che può salvare i risultati delle query SELECT per un piccolo periodo di tempo. Quanti benefici si ottengando dalla cache delle query dipende fortempente dal tipo di applicazione che si usa – questo è il motivo per cui la cache delle query non è abilitata di default. Tutti i test hanno dimostrato che, quando è presente in Magento, se ne guadagna in ulteriore scalabilità. Per abilitare il caching delle query, andate a my.cnf e impostate le seguenti opzioni nella sezione [mysqld]:

query_cache_type=1
query_cache_size=64M

Salva i cambiamenti e riavvia il server MySQl.

Ci sono anche altre ottimizzazioni che possono essere fatte a livello di MySQL, ma si allontana dall’obiettivo di questo artigolo. Date un occhiata ai capitoli 6 e 7 della seconda edizione di “’Reillys High-Performance MySQL” per avere un eccellente guida. Gli autori scrivono anche su un fantastico blog a questo proposito all’indirizzo http://www.mysqlperformanceblog.com/2006/07/27/mysql-query-cache/.

Misura il tuo Magento
Comprendi i tempi di caricamento con Fiddler

Quando si carica una pagina web nel browser, ogni utente ha la sensazione che quel sito sia veloce o meno. Questa sensazione è molto importante, specialmente per i propri utenti finali. Putroppo non è un informazione analizzabile, perchè tutto quello che si sà è che la pagina non è veloce, ma non è dato sapere dove cambiare codici e configurazione.

Per fortuna, Microsoft ha rilasciato un tool freeware molto utile che si chiama Fiddler, disponibile solo per Windows. Fiddler lavora con un proxy HTTP sul desktop del computer, tracciando il contenuto di ogni richiesta e le risposte fornite dal browser. Alla fine puoi rivedere tutto ciò. Fiddler può essere un strumento valido dal debugging di Ajax al miglioramento delle performance in genereale, quindi può valere la pena guardare qualche screencast sul loro sito mentre si legge la documentazione.

Vogliamo capire cosa compone il tempo di caricamenteo delle pagine del nostro Mangento Store, e Fiddler può mostarci la timeline che fa esattamente questo. Quindi, dopo aver istallato Fiddler, e dopo aver configurato il browser all’uso, svuotate la cache del browser e andate alla pagina del negozio che vi interessa. Vedrete un logo per ogni richiesta nella finestra di Fiddlre. Selezionate tutte le richieste e cliccate su “Timeline” nel pannello.

Vedrete un immagine come questa:


Figura 1 – Risultati di Fiddler

Questa timeline è stata presa da un negozio dimostrativo, e mostra che Magento ha lavorato soltanto un secondo (la barra blu sopra il pannelo di destra). Il browser ha caricato la pagina completa soltato dopo 11 secondi – e 3 di questi sono stati impiegati aspettando che Javascript caricasse! Quando si pensa di migliorare il proprio sito, è fondamentale pensare che il caricamento di oggetti statici può aver bisogno di 10 volte il tempo necessario per far funzionare Magento. Prima di metter mano all’appliczione di Magento, è meglio assicurarsi di aver ottimizzato la consegna dei propri file statici.

Usa YSlow per ulteriori consigli

Yahoo ha rilasciato un add-on gratuito per Firefox chiamato Yslow che può fornire informazioni sui tempi di caricamento delle pagine e – a differenza di Fiffler – fornisce semplici consigli su come migliorare le performance. Andate a http://developer.yahoo.com/yslow/ per il download e per ulteriori informazioni – c’è una guida molto ben fatta.

Simulate il comportamento degli utenti con Siege

Siege è uno strumento Open Source sviluppato in Perl che permette di simulare la navigazione degli utenti sul tuo sito. E’ il modo migliore per avere un idea di quanto il server possa sostenere il caricamento della propria applicazione, data la sua configurazione.

Molti amministratori e molti sviluppatori stimano la scalabilità del proprio sito martellando (per finta) un server con diverse richieste.
sostanzialmente, significa chiamare ripetutamente lo stesso url e vedere quante richieste sostiene per secondo. Questo può essere fatto, ad esempio, con Apache Benchmark tool ab2.

Il problema di questo approccio è che gli utenti reali non si comportano in questo modo. I numeri che si ottengono sono fuorvianti:
per prima cosa, se abiliti la cache, strumenti come ab2, quanto la tua applicazione è scalabile se il picco della frequenza di cache è vicina al 100%. Nella realtà dei fatti, il piccolo sarà di gran lunga inferiore perchè i visitatori vanno in tante pagine diverse contemporaneamente.

Allo stesso tempo, è difficile interpretare le cifre ottenute. Supponiamo che il vostro server possa sostenere 5 richieste dinamiche al secondo. Significa forse che possiamo avere solo 5 visitatori contemoraneamente? Ovviamente no, perchè gli umanifanno richieste molto più lentamente rispetto ad uno strumento di benchmarking. Quante sessioni sostiene il vostro server è ancora difficile da stimare e dipende da molti fattori. Simulare la navigazione degli utenti in modo diretto è il modo migliore per questo problema, ed è fortmente raccomandato di usare un tool come Siege prima di andare online con il proprio Magento store. Troppi siti si bloccano immediatamente dopo il caricamento, perchè la capacità del server era drasticamente sovrastimanat; nessuno immagina quanti server dalle grandi dimensioni sono inattivi a causa del problema opposto.

L’Home page di Siege, all’indirizzo http://www.joedog.org/index/siege-home, fornisce tutte le informazioni per cominciare. Se usate Linux, guardate se c’è un pacchetto pronto per l’uso prima di istallarmo manualmente. Come scritto nel README, bisogna creare un file di testo contenente le richieste fatte in ogni sessione. Siege tiene traccia dei cookie, così potrete avere utenti che prima si loggano, poi aggiungono qualcosa al carrello, etc..

Iniziare con Siege richiede un pò di tempo e pratica, così come impostare il file degli URL per il test. Tuttavia, avere in mano strumenti del genere è fondamentale per la riuscita del progetto

Tre azioni per migliorare la scalabilità e le performance
Abilita il blocco del caching dove ha senso

Magento può mettere da parte un blocco fuori dalle proprie pagine. Quando il prossimo utente richiederà lo stesso blocco, l’output che era stato precedentemente calcolato può essere restitutito direttamente – senza andare in tutte le query del database e richiamare di nuovo i modelli. Quest’aspetto è veramente utile per quelle parti di pagina che non cambiano molto spesso ma sono in qualche modo costose da calcolare – come le pagine delle categorie. Chiaramente ha molto più senso calcolare l’output una volta e successivamente nasconderlo 5 minuti, piuttosto che richiamare lo stesso modello con gli stessi risultati.

Il blocco del caching non è abilitato, perchè non si ha bisogno di impostare la giusta cache che si adatti al proprio uso. Per esempio, se i prezzi dipendono da un gruppo di consumatori, c’è bisogno di aggiungere il gruppo di consulatori alla chiave della cache.

Il mio consiglio è di leggere la pagina wiki su questo argomento e estendere la classe del file Mage_Catalog_Block_Category_View class per abilitare il caching. E’ abbastanza comune che questo semplice cambiamento raddoppi il numero di sessioni sopportate dal servere.

Ottenere meno richieste HTTP dal vostro Theme

Quando Yslow vi dà l’allarme, avere molte richieste HTTP da caricare può uccidere le performance di una pagina web. Anche se sei capace di sopravvivere o di usare un network di consegna di contenuto, caricare piccole immagini è ancora più lento di un solo grande file che contiene tutte le immagini. Ridurre il numero di richieste HTTP è in gran parte causa della misura della performance, ma aiuta anche un pochino la scalabilità.

Usando image sprites, si possono inserire tutte le icone, pulsanti etc presenti nel proprio tema in un unico fali che può essere scaricato velocemente e poi si può mostrare solo la parte necessaria. Per tutto ciò bisogna smanettare un pochino con CSS. A List Apart presenta un tutorial ben fatto per cominciare all’indirizzo http://www.alistapart.com/articles/sprites/.

Usa FastCGI per eseguire PHP

Se si usa Apache come web server, ci sono due modi per impostare PHP. Il primo è usare il modulo mod_php che è il più semplice da usare e quindi quello standard con molti hosting provider. In questo caso, un interprete PHP viene eseguito durante ogni processo del web server e finchè lo script non viene eseguito.

Se ti stupisci perchè Apache ha bisogno di molta memoria, probabilmente gran parte della risposta è che stai usando mod_php. Su un grande sito potrebbero esserci centinaia di processi Apache in corso e ognuno di essi ha il proprio interprete PHP. Ad ogni modo, soltato pochi di esse – più o meno una decina – hanno bisogno di eseguire PHP. Il resto serve file statici o semplicemente attende nuove richieste. A causa dello smodato uso di memoria di PHP, è una buona idera vedere se si riesce ad evitare i costi operativi generati dall’avere dozzine e dozzie di PHP inattivi durante l’esecuzione dei processi.

Il modo per evitare questi costi operativi è usare FastCGI invece di mod_php. Con FastCGI, un diverso daemon interno viene eseguito sul proprio serve e viene contattato solo quando si richiede l’esecuzione di PHP. Così, non si avraà bisogno di caricare il bagaglio di PHP su ogni richiesta.

Impostare FastCGi richide di fare alcuni cambiamenti alla configuraazione del server, ma i vantaggi saranno grandi. Un buon punto di padtenza è questo articolo: http://2bits.com/articles/apache-fcgid-acceptable-performance-and-better-resource-utilization.html. Per ulteriori dettagli controllate il sito di Apache e la documentazione della propria distribuzione.

Alternativa: Spegnere Keep-Alive se bisogna usare mod_php

Se non potete, o non volete, passare a FastCGI, qualcos’altro può essere fatto per ridurre l’uso di memoria per singolo visitatore. e’ importante perchè ogni server ha un certa quantità di memoria, e se si riesce a servire un visitatore con meno memoria, si potranno servire più visitatori e andare più lontano con le stesse risorse.

Come ho detto precedentemente, il problema con mod_php è che ha bisogno di esegurie un interprete PHP con ogni processo di Apache, e che la maggior parte delle richieste di Apache non coinvolgono PHP. Apache abilità di default una funzine che si chiama HTTP Keep Alice, che permette ai visitatori di riusare una connessione per diverse richieste. Questo rende il sito più veloce per il visitatore, perchè immagini ed altri file statici possono essere caricati senza riconnettersi al server in continuzazione. Inoltre significa anche che il tuo server avrà molti processi inattivi, che attendono nuove richieste che potrebbero non arrivare mai. Ognuno di questi processi inattivi esegue un interprete PHP completo.

Per spegnere Keep-Alive, cercate i file di configurazione di Apache nelle directive di KeepAlive. Se la directive non è impostata, aggiungi la seguente riga al file di configurazione.

<IfModule mod_expires.c> ExpiresActive On </IfModule>
 e riavviate Apache. Se è impostato assicuratevi che sia settato su “off”. Bisognerebbe iniziare per vedere immediatamente un uso minore di memoria.

Usa un Content Delivery Network

Un’altra maniera di evitare stress ai propri server avere una sezione esterna che serva i file statici al posto vostro. Questi servizi, chiamati Content Delivery Networks (CDN), stanno diventando molto popolari e i prezzi, da qualche anno, sono calati. Un CDN può veramente migliorare la user experience sul proprio sito, ed è un altro modo per aggirare i problemi creati da mod_php.

Impostre un CDN è abbastanza facile con l’estenzione gratuita One Pica CDN ottenibile attraverso Magento Connect.

Andando avanti

Avete seguito tutti i passaggi di questa guida e Magento ancora non scala al livelo di cui avete bisogno? Per prima cosa controllate ancora se avete effettuato correttamente tutti i passaggi. La configurazione che ho spiegato sopra funziona molto bene su quasi tutti i Magento Store, servendo centinaia di migliaia di pagine viste al giorno. Controllate che l’hardware funzioni bene e che non ci siano limiti di banda sul server.

Se il sito è particolarmente grande, vi vorrete trasferire in un infrastuttura che fornisca grandi coperture assicurative contro malfunzionamenti di software e hardware. Bisogna impostare una copia di MySQL per il proprio database e bilanciare il carico tra i server. In pratica, in questo modo ci si trasferisce ad un infrattuttura specializzata o si ottiene consulenza esterna per impostare l’infrastruttura al vostro posto.

Magento è molto adatto per questi sviluppi. Si possono impostare diverse connessioni al database per leggere e scrivere query, il che è importante quando si usano copie di My SQL, quando si usa memoria cache distribuita come cache backend. Quindi Magento non porrà limiti.

Conclusioni

Performace e scalabilità sono importanti, ma sono argomenti delicati. Ho provato a farvi prendere confidenza con gli strumenti e le strategie che si possono usare per ottenere di più dalle infrastrutture esistenti. Molto spesso,soltanto uploadando le modifice “Semplici vittorie” si ottengono risultati sufficienti per ottenere la potenza necessaria al proprio Magento Shop.

Nota a margine: voglio precisare che la maggior parte degli argomenti trattati, non riguarda direttamente Magento ma la configurazione del servere. E questa è una cosa da tenere in mente: spesso la performance e la scalabilità non sono problemi di Magento ma di infrattutura, ma siccome Magento è una applicazione abbastanza complessa, ci si imbatterà più rapidamente rispetto ad applicazioni simili.

Fonte: Vision su Magentocommerce.com