Prestashop su AWS: la guida definitiva

First things first

Prestashop è un CMS Open Source, sviluppato in PHP, famoso per il suo largo impiego nel mondo della vendita online. Come ogni progetto Open Source trova nella sua community appassionati e professionisti che sviluppano costantemente moduli (gratis e a pagamento) e supportano gli utenti nella personalizzazione dei propri. La moltitudine di moduli a disposizione sicuramente mettono Prestashop in lizza per il CMS più utilizzato in ambito E-Commerce, insieme a Magento, WordPress e tutti gli altri CMS in circolazione.

Diverse sono le informazioni che su svariati forum, oltre quello ufficiale di Prestashop, si trovano per poter installare il prodotto, configurarlo al meglio, ottimizzarlo e personalizzarlo sulle proprie necessità. Tuttavia quando si parla di implementare la soluzione in ambiente AWS le informazioni iniziano a scarseggiare, per questo abbiamo pensato di redigere questa guida con una serie di osservazioni utili ad ottimizzare l’ambiente in un contesto Cloud quale quello di Amazon.

Iniziamo quindi a vederne i dettagli della configurazione

MySQL? Sì, ma Maria!

La scelta del Database Engine è tutt’altro che scontata e in questo specifico contesto MariaDB, Database Open Source ideato dagli stessi creatori di MySQL, ci è parso quello maggiormente performante a confronto. Da alcuni test è infatti emerso che anche senza alcuna personalizzazione sulle parametriche il passaggio da MySQL a MariaDB può fornire immediatamente un riscontro in latenza pari a -0.2s.

Per chi stesse valutando un’ottimizzazione del proprio Prestashop, a prescindere che sia questo in ambiente Cloud, il passaggio è indolore in quanto parliamo di un “Fully Compatible”, vi basterà importare il vostro DB e il gioco sarà fatto.

Ecco una serie di parametri sui quali intervenire per poter ottimizzare le performance del proprio MariaDB:


"performance_schema" : "OFF"
"innodb_lock_wait_timeout" : "120"
"max_allowed_packet" : "16777216"
"key_buffer_size" : "134217728"
"read_buffer_size" : "2097152"
"read_rnd_buffer_size" : "1048576"
"thread_cache_size" : "80"
"join_buffer_size" : "2097152"
"sort_buffer_size" : "2097152"
"max_connections" : "400"
"tmp_table_size" : "33554432"
"max_heap_table_size" : "33554432"
"table_definition_cache" : "8192"
"query_cache_size" : "33554432"
"innodb_buffer_pool_size" : "3221225472"
"innodb_log_file_size" : "134217728"
"innodb_log_buffer_size" : "8388608"
"innodb_flush_log_at_trx_commit" : "2"
"innodb_thread_concurrency" : "32"
"innodb_read_io_threads" : "8"
"innodb_write_io_threads" : "8"
"innodb_flush_method" : "O_DIRECT"
"innodb_file_per_table" : "1"
"innodb_io_capacity" : "2000"
"innodb_file_format" : "Barracuda"
"innodb_buffer_pool_dump_at_shutdown" : "ON"
"innodb_buffer_pool_load_at_startup" : "ON"
"innodb_log_compressed_pages" : "0"

Chiaramente queste impostazioni fanno riferimento ad una prima customizzazione, eventuali modifiche dovranno essere effettuate per rispondere a specifiche peculiarità del vostro ambiente.

PHP con il Turbo

Che PHP sia goloso di CPU si sa, ma senza necessariamente dover pensare ad una migrazione a PHP7 – che in tal senso ha introdotto diverse migliorie – si può pensare di utilizzare PHP-FPM. Per chi non sapesse cos’è, PHP-FPM è un interprete PHP in grado di restituire diverse migliorie in termini di performance. Molto utilizzato nel mondo dell’editoria on-line torna molto utile quando si vuole tirar fuori il meglio dal proprio CMS, soprattutto se quest’ultimo si ritrova a gestire dei carichi impegnativi.

Poche sono le configurazioni che suggeriamo in questo caso, principalmente due:

  1. utilizzare come configurazione “ondemand” invece di “dynamic”
  2. utilizzare come protocollo di comunicazione lo UNIX socket

La prima modifica è un’ottimizzazione che riguarda essenzialmente carichi la cui curva d’utilizzo varia molto nel dominio del tempo, qualora il vostro Prestashop avesse un traffico costante di visitatori potrebbe aver senso ottimizzare il profilo dynamic opportunamente.
La seconda invece vale quasi sempre, lo UNIX socket è notoriamente più veloce del TCP che invece apre una porta (di default la 9000) su localhost per la fruizione del contenuto dinamico.

Web al quadrato

Quello che a prima vista potrebbe sembrare un problema facile, in realtà può essere ben più complicato soprattutto se si pensa che parametri come latenza, velocità di caricamento dei contenuti statici, velocità d’elaborazione delle logiche applicative etc. sono dei fattori cruciali per uno store on-line. Se una pagina impiega più di due secondi per essere aperta l’utilizzatore medio la chiude, quindi il tempo – in un E-Commerce – è una delle chiavi per un conversion rate maggiore. Questa esperienza di navigazione, poi, dev’essere costante all’aumentare delle connessioni altrimenti l’elevato traffico (tipicamente un fattore positivo) diventa il peggior nemico del commercio on-line.

Parliamo quindi della parte di elaborazione del contenuto statico e la fruizione del contenuto dinamico che non è relegata (solo) ad Apache. Abbiamo scelto di implementare sia Nginx che Apache per poter giovare dei benefici di ognuno dei Web Server, senza però subirne gli svantaggi. Nginx infatti si preoccupa semplicemente di ruotare le richieste che arrivano dal web (su porta 80 o 443) su di una porta diversa dove è in ascolto Apache che tramite PHP-FPM rende fruibile tutto il contenuto generato da PHP.

Questa configurazione permette di velocizzare di molto le connessioni, sfruttando la velocità di Nginx (che non interpreta il PHP) e la solidità di Apache con PHP-FPM aumentando al contempo la sicurezza e la semplicità nella gestione di diversi protocolli di comunicazione (HTTP e HTTPS).

Bilanciamento, è tutta questione di equilibrio

Le connessioni vengono redirezionate su più server, sia per alta affidabilità che per scalabilità con la possibilità di aggiungerne e sottrarne all’occorrenza per adottare un modello “capacity on demand” che permette di rendere questa soluzione efficiente dal punto di vista economico. Per questo si utilizza un bilanciatore, in ambiente AWS chiamato ELB, che consente di gestire un grosso numero di connessioni tramite diverse macchine presenti in diverse Availability Zones (dei Datacenter, per intenderci).

Con il bilanciatore, però, aggiungiamo di fatto un “layer” alla nostra infrastruttura che dovrà gestire le connessioni e quindi avremmo diversi timeout da gestire. AWS offre già delle linee guida per poter gestire questo genere di cascata che potete trovare qui, tuttavia il nostro scenario è leggermente diverso. Infatti la connessione parte dall’ELB, arriva ad Nginx che a sua volta rigira su Apache. Senza quindi volerci addentrare nello strato PHP-FPM abbiamo 3 “livelli” e non due. Ognuno di questi deve avere un timeout diverso per poter ottimizzare tutti i Child Processes che entrambi i Web Server vanno a creare.

  • Nginx avrà un timeout pari al doppio di quello impostato nell’Elastic Load Balancer, con un parametro di “work_processes” opportunamente configurato sulla base del numero di vCPU a disposizione
  • Apache avrà invece un timeout che può variarie tra il doppio di quello impostato nell’Elastic Load Balancer e il doppio di quello impostato in Nginx, mentre la sua configurazione prevederà il modulo MPM in modalità prefork, worker o event sulla base dell’analisi del proprio carico specifico

Non abbiamo ancora finito

Vi abbiamo già mostrato in altri articoli (qui e qui) quanto l’Infrastructure as a Code torni utile in diversi scenari e quali sono i risvolti positivi in processi ICT molto importanti quali il Configuration Management, vogliamo condividere un template da noi sviluppato per l’intera creazione di un ambiente Prestashop sul quale effettuare i propri sviluppi. Trovare il template a questo link, qui di seguito una breve guida per l’implementazione

 

 

Alcune varianti…

Chiaramente il template è libero ad ogni modifica, vi suggeriamo delle varianti da poter introdurre per migliorare ulteriormente il vostro store:

  • Continuous Integration e CodeDeploy, impostare la Continuout Integration e il Deploy tramite il prodotto di AWS garantisce che alla creazione di nuove macchine quest’ultimo si preoccupi del Deploy dell’ultima versione attualmente in uso
  • Cloudfront, Prestashop ha una funzionalità (media server) che permette di fruire di contenuti statici (immagini, video etc.) tramite una Content Distribution Network che permette di diminuire il tempo di caricamento tramite le Edge Location
  • Elasticache, tramite il modulo memcached già installato nel template è possibile esternalizzare il caching degli oggetti su di un cluster RAM

Vuoi un ambiente Cloud personalizzato per il tuo E-Commerce?
Contattaci






Ho letto e acconsento al trattamento dei dati personali