Come evitare il disastro del CMS: come prevenire i tempi di inattività del sito Web

Cosa significa effettivamente per un sito essere considerato inattivo ?

Spesso dipende da chi chiedi.

Affinché un sito Web sia considerato inattivo, può significare una serie di cose diverse:

• Il sito web è completamente indisponibile.
• Il sito è online ma inutilizzabilmente lento.
• Il sito Web fornisce messaggi di errore per determinati utenti o posizioni.
• Il sito Web funziona per la maggior parte dei visitatori, ma alcuni semplicemente non possono accedere al proprio CMS, ad esempio per creare, modificare o pubblicare contenuti.

Indipendentemente dalla causa o dal grado, l'impatto dei tempi di inattività del sito Web può essere grave, dalla perdita di ordini e-commerce e utenti frustrati all'indebolimento della fiducia dei clienti.

Nella terza delle nostre serie Avoiding CMS Disaster , esploriamo le classiche cause principali dei tempi di inattività del sito Web e il ruolo che il monitoraggio continuo e altri fattori svolgono nell'evitarlo.

In primo luogo, il ruolo svolto dal monitoraggio continuo

Monitoriamo diversi aspetti di un sito Web, in modo da poter sapere quando qualcosa non funziona correttamente in uno qualsiasi dei diversi livelli che compongono la nostra piattaforma VIP WordPress completamente gestita. Questi livelli includono:

• Connettività di rete
• Bilanciatori di carico
• Server web
• Memorizzazione nella cache degli oggetti (Memcached)
• Banche dati
• Ricerca elastica
• Servizio file (CDN)

Cerchiamo di individuare i problemi in anticipo in modo da poter anticipare problemi futuri che potrebbero influire sulla stabilità del sito web. I registri incrociati di diversi componenti di sistema ci consentono di rivedere i periodi in cui un sito Web è stato segnalato come instabile. Poiché una combinazione di fattori piuttosto che un singolo problema potrebbe essere responsabile dei tempi di inattività, utilizziamo una serie di strumenti per confrontare i dati tra sistemi e applicazioni.

Nella maggior parte dei casi, l'instabilità del sito Web è il risultato del codice dell'applicazione, ad esempio il tema WordPress personalizzato o di terze parti e il codice del plug-in. Ecco alcune cose che cerchiamo quando esaminiamo un sito instabile e come mitigarli.

Cache insufficiente

La cosa più importante che puoi fare per assicurarti che un sito sia performante e stabile è assicurarti che qualsiasi pagina intera che può essere memorizzata nella cache sia memorizzata nella cache. Le pagine non memorizzate nella cache devono essere create sul server ogni volta che vengono richieste, il che è un processo più lento e più soggetto a errori.

La risposta VIP di WordPress:

La piattaforma VIP di WordPress fornisce una potente memorizzazione nella cache delle pagine tramite una rete globale di server edge cache, ciascuno utilizzato per archiviare e servire i contenuti più vicini a un utente finale. Il tempo di risposta da un server edge cache è quasi sempre molto più veloce di qualsiasi cosa che aggiri la memorizzazione nella cache delle pagine e raggiunga i server di origine.

Sfide di memorizzazione nella cache

Poiché richiedono un'esperienza personalizzata e completamente interattiva, alcuni siti, in particolare quelli di e-commerce, semplicemente non possono essere memorizzati nella cache a livello di cache della pagina.

Spesso si può trovare un compromesso in base al quale una pagina statica viene servita da edge cache, con funzionalità dinamiche (ad es. stato di accesso, carrelli della spesa) aggiunte tramite JavaScript. Le richieste asincrone da JavaScript possono quindi essere utilizzate per comunicare con un endpoint dell'API REST di WordPress progettato con un sovraccarico molto inferiore rispetto a un caricamento a pagina intera.

In alternativa, è qui che entra in gioco la memorizzazione nella cache degli oggetti. La pagina può rimanere dinamica ma parti della pagina e tutti i dati in essa utilizzati possono essere archiviati e recuperati nella cache degli oggetti per evitare di dover eseguire query sul database.

La risposta VIP di WordPress:

Ogni ambiente di applicazione VIP di WordPress ha il proprio cluster Memcached dedicato, che memorizza i dati della cache degli oggetti in memoria per un recupero rapido ed efficiente.

Distribuzioni di codice non testate

Questo è un altro colpevole comune dei tempi di inattività del sito Web e abbastanza facile da diagnosticare, basato sulla pura causa ed effetto.

Se il tuo sito web ha appena distribuito codice non testato, causando problemi immediati al sito, c'è la tua probabile causa. Se puoi, ripristina il codice sospetto alla versione precedente il prima possibile.

La cosa migliore da fare per evitare questa situazione? Testare accuratamente ogni pezzo di codice in un ambiente di sviluppo o staging separato prima di rilasciarlo in produzione.

La risposta VIP di WordPress:

Poiché tutte le implementazioni del nostro sito avvengono tramite GitHub, i clienti VIP di WordPress possono facilmente ripristinare il codice da soli, senza perdere le nuove modifiche al codice, che rimangono archiviate in modo sicuro nella cronologia delle revisioni di GitHub. Facoltativamente, in situazioni di emergenza, possiamo eseguire il rollback del sito Web di un cliente a una distribuzione precedente per suo conto, indipendentemente da GitHub.

Per quanto riguarda gli ambienti, tutte le applicazioni ospitate sul nostro servizio completamente gestito possono avere un ambiente di sviluppo o di staging separato. Sincronizzare i dati dalla produzione è facile, consentendoti di testare il codice rispetto alla stessa quantità e allo stesso tipo di dati del tuo sito Web di produzione.

Errori PHP

WordPress utilizza il codice PHP sul server. Un errore PHP potrebbe essere "fatale", il che significa che una volta che si verifica l'errore, la pagina Web, lo script o il comando smetteranno di funzionare. Questi verranno quasi sempre visualizzati come errori visibili da qualche parte e verranno registrati nei log di PHP.

Nota: alcuni avvisi PHP in PHP 7 diventano errori irreversibili in PHP 8, quindi è importante prendere sul serio questi errori.

La risposta VIP di WordPress (oltre a consigli utili):

La nostra piattaforma registra automaticamente tutti gli errori PHP, rendendoli disponibili ai clienti VIP di WordPress nella loro dashboard e ai nostri ingegneri.

Suggerimento per professionisti : indirizza e correggi tutti gli errori PHP, anche se un sito sembra funzionare correttamente. Di routine, vediamo log pieni di errori PHP, anche fatali, su un sito che sembra stabile. Tuttavia, ciò non significa necessariamente che il sito funzioni correttamente . Mantenere i registri PHP chiari risolvendo errori e avvisi minori rende più facile trovare errori più gravi durante il debug.

Query lente al database MySQL

Ogni sito Web WordPress utilizza un database per archiviare il contenuto del sito Web e i dati di configurazione. Le query del database recuperano i dati del contenuto per le pagine Web, ma a volte tali query vengono scritte in modo inefficiente. Possono funzionare bene per siti con poche centinaia di pagine, ma si bloccano quando si gestiscono grandi quantità di dati (alcuni siti Web sulla nostra piattaforma hanno milioni di record archiviati).

Una query lenta impegna le risorse del database, con un potenziale impatto sulla stabilità del sito, non solo per la pagina, lo script o il comando che esegue l'SQL, ma nell'intera applicazione. I siti spesso hanno problemi perché le query di database singole o multiple sono lente, ad esempio, qualsiasi query che richiede più di 0,75 secondi per essere eseguita.

La risposta VIP di WordPress:

WordPress VIP aiuta a mitigare i colli di bottiglia del database fornendo a ciascuna applicazione un cluster di database dedicato con un database primario, in cui si verificano tutte le query di scrittura del database e uno o più database di replica di sola lettura. Ciò aumenta il numero di query simultanee al database che possono essere eseguite, distribuendo il carico di risorse quando un sito è sotto pressione. Detto questo, le query lente del database non possono sempre essere risolte semplicemente aggiungendo risorse di database aggiuntive. Ecco perché consigliamo ai clienti di monitorare le query lente del database utilizzando Query Monitor e New Relic (forniti dalla nostra piattaforma). Questi evidenziano l'origine delle query nel database, in modo che il team di sviluppo possa eseguirne il refactoring per ottimizzare le prestazioni.

Infine, il nostro supporto per le applicazioni e gli ingegneri Premier possono anche aiutare il tuo team a trovare e analizzare queste domande e suggerire modi per migliorarle in termini di velocità ed efficienza.

Scritture eccessive del database

A volte una funzionalità, come la registrazione personalizzata o il codice di monitoraggio, aggiorna il database a ogni richiesta. Questo può portare all'instabilità per due motivi:

• Repliche del database precedenti : tutte le query di scrittura vengono indirizzate al database primario; anche le successive query di database per la stessa tabella (o tabelle) nella stessa richiesta di pagina verranno indirizzate lì. Non sfruttando le repliche del database, ciò limita la scalabilità del sito.
• Bypass della cache della pagina : affinché una scrittura del database avvenga su ogni richiesta di pagina, la cache della pagina deve essere ignorata. Ma così facendo significa che la prima (e migliore) linea di difesa è stata compromessa.

La risposta VIP di WordPress:

In queste circostanze, consigliamo di refactoring della funzione. Ad esempio, l'analisi del contenuto è in genere meglio delegata a un servizio esterno che utilizza uno snippet di JavaScript nella pagina anziché codice lato server, che non funziona bene con la memorizzazione nella cache e può causare scritture eccessive del database.

Altre cause note di fermo macchina e come evitarle

Plugin

Ci sono migliaia di plugin di terze parti popolari e utili nell'ecosistema di WordPress che forniscono fantastiche caratteristiche e funzionalità. Alcuni, tuttavia, presentano difficoltà di ridimensionamento, che potenzialmente portano a problemi di tempi di inattività quando vengono aggiunti a un sito Web con tonnellate di contenuto e traffico.

La risposta VIP di WordPress:

Come buoni amministratori dell'ecosistema, contattiamo regolarmente i fornitori con suggerimenti per migliorare le prestazioni dei loro plug-in in ambienti ad alto traffico. Possiamo anche suggerire plugin alternativi che sono stati provati e testati su larga scala sulla nostra piattaforma.

Registrazione personalizzata

La registrazione personalizzata è un potente strumento di debug, spesso l'unico metodo praticabile per rintracciare un bug o un problema che sembra verificarsi solo in un sito di produzione. In numerose occasioni, tuttavia, abbiamo visto la registrazione personalizzata costruita in PHP su un sito ad alto traffico rallentare le cose o mettere un sito in pericolo di tempi di inattività a causa di scritture eccessive del database.

La risposta VIP di WordPress:

Per i clienti, forniamo l'accesso ai registri PHP standard nel pannello Salute del dashboard dell'applicazione VIP di WordPress. Lì possono registrare errori personalizzati (e anche su New Relic), che non avranno un impatto negativo sul database.

Chiamate API remote

Alcuni siti Web sfruttano le chiamate dell'API REST lato server ad altre applicazioni o servizi. Questi sono piuttosto veloci in circostanze normali, ma a volte il codice dell'applicazione sottostante porta a una risposta lenta, timeout o genera un errore.

La risposta VIP di WordPress:

Per ridurre al minimo questi problemi, consigliamo la "codifica difensiva". Dipende dallo scopo della chiamata remota, ma spesso quando una richiesta remota ha esito negativo, è possibile ripiegare su una risposta memorizzata nella cache di una richiesta precedente, o almeno "gestire l'errore con garbo", in modo che il resto della pagina possa ancora carico. Forniamo una serie di funzioni di supporto per gestire questi scenari. Mantenere un timeout basso significa anche che le risorse PHP vengono liberate più rapidamente se l'API remota non risponde.

Leggi di più nella nostra serie Come evitare il disastro CMS

Quando la tua azienda è in gioco, non puoi permetterti di inviare nuovi affari altrove e offuscare il tuo marchio facendo in modo che il tuo sistema di gestione dei contenuti (CMS) offra un'esperienza digitale scadente. In Come migliorare le prestazioni del sito Web , diagnostichiamo cinque comuni colpevoli di rallentamento e come potenziare le cose utilizzando un CMS agile.

I giorni ad alto traffico dovrebbero essere motivo di festa, non un incubo per gli ingegneri che cercano di mantenere un sito e le applicazioni attivi e ronzanti per gestire il carico e la tua reputazione intatta. In Scaling WordPress for High Traffic , esploriamo quattro approcci per consentire a un sito Web WordPress di gestire quelle ondate di traffico.