[Case Study] Ottimizzare un sito da 3 milioni di visite al mese con un’infrastruttura server


Postato in data Aprile 16th, da Christian Cantinelli in Hosting. 4 comments

Con i servizi Serverplan compriamo esigenze diverse. C’è il webmaster che cerca un normalissimo hosting per sito web personale a chi ha bisogno di servizi particolari. Tipo un VPS? No, l’infrastruttura di server a volte è la soluzione per ottimizzare un intero percorso.

infrastruttura di server

Di cosa si tratta esattamente? Quali sono i vantaggi? Per illustrarti al meglio questa soluzione, invece di elencare semplicemente i vantaggi dell’infrastruttura di server, abbiamo deciso di presentare un piccolo case study che abbiamo affrontato con un nostro cliente.

Analisi preliminare: il cliente

Il contatto in questione lavora nel settore dell’editoria e possiede una testata giornalistica online con un volume di circa 3 milioni di visite al mese. Il lavoro di studio si è focalizzato, in primo luogo, sulla natura del portale.

Il sito web gira su WordPress con l’integrazione di numerose personalizzazioni che gestiscono le funzionalità che vanno dall’esperienza utente, alla gestione della pubblicità.

Esigenze dell’infrastruttura di server

Non si tratta di una richiesta di hosting condiviso e neanche di VPS o server dedicato. L’esigenza del cliente è diversa: un’infrastruttura che possa far fronte a diversi obiettivi.

  • Gestire traffico fino a 20.000 utenti contemporaneamente.
  • Evitare di perdere performance o rischiare down del servizio.
  • Poter gestire ADV esterna facilmente (core business aziendale).
  • Ottenere prestazioni elevate nel backend per gli editori.

Ovviamente in questa sede è giusto ringraziare anche l’agenzia www.dekoo.it che ha seguito lo sviluppo ideale del sito web e ci ha fornito il supporto necessario.

Cosa ha proposto Serverplan

Dopo l’analisi del sito (WordPress 5.2 + 24 Plugins), del database (25Gb, 17 milioni di record), del traffico e dei contenuti abbiamo deciso di puntare su una soluzione ad hoc. Dividendo lo stack su 3 macchine fisiche e mettendo un sistema di caching per avere minor uso di risorse.

Frontend

  • Varnish cache + terminale SSL Haproxy.
  • Server SuperMICRO X10SLD-F.
  • CPU Intel Xeon E3-1231 v3 a 3,40 GHz.
  • 16 Gb RAM, 2x120Gb SSD RAID-HW-1.

Backend

  • Apache, php 7.3 + opcache.
  • Gestione di altri servizi (ftp/posta/etc.) su cPanel.
  • Server Dell R440.
  • CPU Xeon Silver 4114 a 2,20 GHz.
  • 64 Gb RAM, 2×960 Gb SSD RAID-HW-1.

DB server

  • MySQL 5.6. Server Dell 630.
  • CPU Intel Xeon E5-2680 v4 a 2,40 GHz.
  • 256 GByte di RAM, RAID 1 960 GByte SSD.

Perché questa scelta specifica

WordPress ha una struttura molto articolata e dinamica, ideale soprattutto per blog e magazine. Il pannello amministrativo permette la gestione di qualsiasi componente del sito con facilità. Ogni componente installato richiede, per ogni visita frontend, risorse in termini di CPU e RAM.

Per un portale di news questo vuol dire che – nel momento in cui viene pubblicato un nuovo articolo – le pagine del sito vengono aggiornate e l’utente vedrà sempre gli stessi contenuti fino ad una nuova pubblicazione. Le uniche risorse dinamiche sono i banner pubblicitari che vengono caricati tramite javascript sui browser dai server delle agenzie esterne al sito.

Normalmente ogni visita che riceve il sito richiede un processo PHP: questo è tanto grande (in termini di RAM, CPU e I/O disco) quanto è carico il CMS e in questo processo incidono anche i plugin. Lo stesso processo, poi, interroga di volta in volta il database per restituire i contenuti.

Se i contenuti sono gli stessi per tutti (fino a nuovo aggiornamento), perché dobbiamo avere tanti processi PHP e interrogazioni al database? Ecco il motivo dell’infrastruttura di server.

Perché l’infrastruttura di server

In una soluzione standard, abbiamo un’unica macchina che gestisce PHP, file statici (immagini/css/javascript) e database. Ogni richiesta viene processata con risorse limitate.

infrastruttura di server
Clicca per ingrandire lo schema.

Se consideriamo un alto numero di accessi contemporanei, il carico da gestire sarà elevato. Ciò rallenta il server che lo dovrà sostenere con la conseguente lentezza o (nei casi più estremi) irraggiungibilità del sito. Con un servizio di caching Varnish abbiamo risolto il problema.

La necessità del Varnish

È inserito tra il web/db server e l’utente finale. Quando effettua una richiesta per la prima volta, Varnish interroga il web server Apache (che, nel caso di pagine PHP, lo fa con il database), elabora la richiesta e la restituisce. Così Varnish memorizza in RAM la pagina e la restituisce. 

Varnish
Clicca per ingrandire lo schema.

Per tutte le chiamate successive alla stessa pagina del sito, Varnish restituisce sempre quella che ha precedentemente memorizzato in RAM senza passare più la richiesta ad Apache.

Un apposito plugin su WordPress esegue un flush (svuotamento) della cache di Varnish ogni volta che un editore effettua una modifica tipo aggiunta articolo, modifica al tema, widget, etc. Questo ci ha permesso di scaricare molto il lavoro dai server Apache/Db.

Gestione richieste dinamiche

In Varnish sono state inserite una serie di regole per permettere alla richieste dinamiche, come ad esempio un form di contatti, di escludere la cache e altre regole che permettono di far passare il traffico quando si è autenticati nel pannello amministrativo di WordPress (wp-admin).

Contributo del cliente

Aabbiamo notato la presenza di diverse chiamate Ajax fatte dal browser che effettuano – per ogni pagina vista – una richiesta al server via POST (invio dati, quindi non cachata).

Tale comportamento era dovuto a un plugin che visualizzava in tempo reale il numero di condivisioni social degli articoli. Il cliente, dietro nostro consiglio, ha modificato la richiesta trasformandola in un GET con possibilità di cacharla) Tramite un cron apposito, e solo per quelle richieste, vengono ora aggiornati i contatori che tornano al browser con cadenza fissa.

Connessione SSL

Dato che Varnish non la supporta, è stato installato sulla stessa macchina il servizio Haproxy. Questo permette di avere un terminale SSL per il sito in HTTP/2 girando poi il traffico a Varnish.

Risultati ottenuti con il lavoro

Con quasi 20.000 utenti contemporanei collegati al sito, l’infrastruttura di server arriva a circa il 30% delle risorse nei momenti di picco. Gli editori lavorano senza rallentamenti sul backend nonostante i milioni di record presenti. Facciamo un esempio, ipotizziamo un Virtual Server con:

  • 4 CPU.
  • 5 Gb di RAM.
  • cPanel.
  • WordPress
  • Circa 1000 articoli.

Abbiamo replicato l’infrastruttura su una singola macchina (Varnish, Haproxy, Apache, PHP, MySQL). Questi sono i risultati sulla CPU con un benchmark che simula le visite a diverse pagine del sito – comprensive di immagini, js, css, etc. – con 50 utenze insieme per 2 minuti.

Risultati ottenuti con il lavoro
Clicca per ingrandire.

Nel primo test senza Varnish l’uso della CPU è stato in media del 98%. Nel secondo test, con Varnish e haproxy, l’uso della CPU è stato di circa il 30%. Rapportando il traffico del cliente?

Con 20.000 utenti contemporaneamente, e l’infrastruttura molto più grande c’è un risparmio notevole di uso delle risorse (circa il 70%) e maggiore velocità nella fruizione del servizio. Questo comporta un ampio margine di risorse disponibili anche con picchi molto maggiori.

Da leggere: qual è il miglior hosting per ecommerce?

A chi consiglieresti un’infrastruttura di server?

Questa infrastruttura la consiglierei soprattutto per siti web che forniscono pagine semi-statiche o con aggiornamenti a cadenza, con WordPress e numerose visite contemporanee. Di sicuro non è la soluzione adeguata per tutti ma può dare ottimi risultati su progetti che richiedono un gran numero di risorse e ha bisogno di server ottimizzati per ogni necessità.

Christian Cantinelli




4 commenti su “[Case Study] Ottimizzare un sito da 3 milioni di visite al mese con un’infrastruttura server

  1. Questo tipo d’infrastruttura è molto basic non garantisce la continuità di servizio in caso di fault di uno dei componenti dell’infrastruttura. In ambito enterprise dov’è richiesto una SLA elevato, questo genere d’infrastruttura non va bene.

    • Ciao Antonio,

      ti ringraziamo per l’osservazione. Questa infrastruttura è stata costruita per avere alte performance di erogazione e per garantire picchi di traffico preventivati con un occhio di riguardo anche al budget e alla struttura del sito.
      Abbiamo altri servizi che sono ancora più performanti, scalabili e in altà affidabilità ovvero le infrastrutture cluster (fisiche o virtuali) che puoi trovare qui:

      https://www.serverplan.com/servizi-avanzati/cluster-e-load-balancing

      Per saperne di più è possibile richiedere informazioni al reparto Marketing: questo tipo di infrastrutture sono proposte con un confronto preventivo insieme ai tecnici.

      Buon lavoro!

  2. Ciao, ottimo articolo, devo aggiungere che il vostro piano Enterprise Plus regge senza problemi 4.000 utenti contemporanei sul sito web. Ho montato solo la cache W3 Total Cache configurata come da vostre istruzioni. Questo sul sito zonacalciofaidate.it.

    Nel vostro esempio dove la Cpu va al 100% non sarebbe stato più semplice aumentare la Cpu? Parlo nel caso si fosse scelto una Vps.

    • Ciao Fabio,

      grazie dei tuoi complimenti!

      I piani Enterprise Plus offrono grandi performance per siti come il tuo e sono felice dei risultati che stai ottenendo! In via generale è il sistema di caching integrato nel CMS che fa veramente la differenza (oltre a macchine che hanno molte risorse disponibili).

      Nell’esempio non è stato utilizzato alcun sistema di caching su WordPress appositamente: questo per evidenziare come l’uso di CPU da parte di PHP sia veramente eccessivo in alcuni scenari.

      Aumentando la CPU, a parità di visite e configurazione, l’erogazione sarebbe più efficiente con possibilità di aumentare il traffico in ingresso.

      Buon lavoro!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

*

Shares