Evitarea dezastrelor CMS: Cum să preveniți timpul de nefuncționare a site-ului

Ce înseamnă, de fapt, ca un site să fie considerat dezamăgit ?

Adesea depinde de cine întrebi.

Pentru ca un site web să fie considerat defect, poate însemna o serie de lucruri diferite:

• Site-ul web este complet indisponibil.
• Site-ul este online, dar nefolositor de lent.
• Site-ul web oferă mesaje de eroare pentru anumiți utilizatori sau locații.
• Site-ul web funcționează pentru majoritatea vizitatorilor, dar unii pur și simplu nu se pot conecta la CMS-ul lor, de exemplu, pentru a crea, edita sau publica conținut.

Indiferent de cauza sau gradul, impactul perioadei de nefuncționare a site-ului poate fi grav, de la comenzile de comerț electronic pierdute și utilizatorii frustrați până la slăbirea încrederii clienților.

În a treia din seria Avoiding CMS Disaster , explorăm cauzele fundamentale ale perioadei de nefuncționare a site-ului web și rolul pe care monitorizarea continuă și alți factori îl joacă în evitarea acestui lucru.

În primul rând, rolul pe care îl joacă monitorizarea continuă

Monitorizăm diferite aspecte ale unui site web, astfel încât să putem spune când ceva nu funcționează corect la oricare dintre diferitele straturi care compun platforma noastră VIP WordPress complet gestionată. Aceste straturi includ:

• Conectivitate la rețea
• Echilibratoare de sarcină
• Servere web
• Memorarea în cache a obiectelor (Memcached)
• Baze de date
• Elasticsearch
• Serviciul de fișiere (CDN)

Încercăm să identificăm problemele din timp, astfel încât să putem anticipa problemele viitoare care ar putea afecta stabilitatea site-ului. Încrucișarea jurnalelor de la diferite componente ale sistemului ne permite să revizuim perioadele în care un site web a fost raportat instabil. Deoarece o combinație de factori, mai degrabă decât o singură problemă, ar putea fi responsabilă pentru timpul de nefuncționare, folosim o serie de instrumente pentru a compara datele atât între sisteme, cât și aplicații.

În cele mai multe cazuri, instabilitatea site-ului web este rezultatul codului aplicației, adică al unei teme WordPress personalizate sau terță parte și al codului pluginului. Iată câteva lucruri pe care le căutăm atunci când investigăm un site instabil și cum să le atenuăm pe fiecare.

Nu este suficientă cache

Cel mai important lucru pe care îl puteți face pentru a vă asigura că un site este performant și stabil este să vă asigurați că orice pagină completă care poate fi stocată în cache este stocată în cache. Paginile necacheate trebuie să fie construite pe server de fiecare dată când sunt solicitate, ceea ce este un proces mai lent și mai predispus la erori.

Răspunsul WordPress VIP:

Platforma VIP WordPress oferă un stocare puternic în cache a paginii printr-o rețea globală de servere edge cache, fiecare folosit pentru a stoca și a difuza conținutul cel mai aproape de un utilizator final. Timpul de răspuns de la un server cache edge este aproape întotdeauna cu mult mai rapid decât orice ocolește stocarea în cache a paginii și atinge serverele de origine.

Memorarea în cache a provocărilor

Deoarece necesită o experiență personalizată, complet interactivă, unele site-uri, în special cele de comerț electronic, pur și simplu nu pot fi stocate în cache la nivel de cache a paginii.

Adesea poate fi găsit un compromis prin care o pagină statică este servită de memoria cache marginală, cu caracteristici dinamice (de exemplu, starea de autentificare, coșuri de cumpărături) adăugate prin JavaScript. Solicitările asincrone de la JavaScript pot fi apoi utilizate pentru a comunica cu un punct final API REST WordPress proiectat cu o suprasarcină mult mai mică decât o încărcare completă a paginii.

Alternativ, aici intervine caching-ul obiectelor. Pagina poate rămâne dinamică, dar părți ale paginii și orice date utilizate în ea pot fi stocate și preluate în cache-ul obiectelor pentru a evita necesitatea interogării bazei de date.

Răspunsul WordPress VIP:

Fiecare mediu de aplicație WordPress VIP are propriul cluster Memcached dedicat, care stochează în memorie datele cache a obiectelor pentru o recuperare rapidă și eficientă.

Implementări de cod netestate

Acesta este un alt vinovat comun al timpului de nefuncționare a site-ului și destul de ușor de diagnosticat, pe baza pură cauză și efect.

Dacă site-ul dvs. tocmai a implementat cod netestat, ceea ce duce la probleme imediate ale site-ului, există cauza probabilă. Dacă puteți, reveniți codul suspect la versiunea anterioară cât mai curând posibil.

Cel mai bun lucru de făcut pentru a evita această situație? Testați cu atenție fiecare bucată de cod într-un mediu separat de dezvoltare sau de punere în scenă înainte de lansarea în producție.

Răspunsul WordPress VIP:

Deoarece toate implementările site-ului nostru sunt prin GitHub, clienții WordPress VIP pot reveni cu ușurință la codul ei înșiși, fără a pierde modificările noi ale codului, care rămân stocate în siguranță în istoricul revizuirilor GitHub. Opțional, în situații de urgență, putem derula site-ul web al unui client la o implementare anterioară în numele acestuia, independent de GitHub.

În ceea ce privește mediile, toate aplicațiile găzduite pe serviciul nostru complet gestionat pot avea un mediu separat de dezvoltare sau staging. Sincronizarea datelor din producție este ușoară, permițându-vă să testați codul cu aceeași cantitate și același tip de date ca pe site-ul dvs. de producție.

erori PHP

WordPress folosește cod PHP pe server. O eroare PHP poate fi „fatală”, ceea ce înseamnă că odată ce apare eroarea, pagina web, scriptul sau comanda se va opri. Acestea vor apărea aproape întotdeauna ca erori vizibile undeva și vor fi înregistrate în jurnalele PHP.

Notă: Unele avertismente PHP din PHP 7 devin erori fatale în PHP 8, așa că este important să luăm aceste erori în serios.

Răspunsul WordPress VIP (plus sfaturi utile):

Platforma noastră înregistrează automat toate erorile PHP, făcându-le disponibile pentru clienții WordPress VIP în tabloul de bord și pentru inginerii noștri.

Sfat profesionist : remediați și remediați toate erorile PHP, chiar dacă un site pare să funcționeze bine. În mod obișnuit, vedem jurnalele pline de erori PHP, chiar fatale, pe un site care pare stabil. Cu toate acestea, asta nu înseamnă neapărat că site-ul funcționează corect . Menținerea jurnalelor PHP clare prin abordarea erorilor minore și a avertismentelor face mai ușor să găsiți erori mai grave în timpul depanării.

Interogări lente de baze de date MySQL

Fiecare site web WordPress folosește o bază de date pentru a stoca conținutul site-ului web și datele de configurare. Interogările din baze de date preiau acele date de conținut pentru paginile web, dar uneori acele interogări sunt scrise ineficient. Acestea pot funcționa bine pentru site-uri cu doar câteva sute de pagini, dar se blochează atunci când manipulează cantități mari de date (unele site-uri web de pe platforma noastră au milioane de înregistrări stocate).

O interogare lentă leagă resursele bazei de date, putând afecta stabilitatea site-ului — nu doar pentru pagina, scriptul sau comanda care rulează SQL, ci pentru întreaga aplicație. Site-urile se luptă adesea pentru că interogările de bază de date individuale sau multiple sunt lente, de exemplu, orice interogare care durează mai mult de 0,75 secunde pentru a se executa.

Răspunsul WordPress VIP:

WordPress VIP ajută la atenuarea blocajelor în bazele de date, oferind fiecărei aplicații un cluster de baze de date dedicat, care include o bază de date primară, în care apar toate interogările de scriere a bazei de date și una sau mai multe baze de date replici doar pentru citire. Acest lucru crește numărul de interogări simultane de baze de date care pot avea loc, împrăștiind încărcarea resurselor atunci când un site este sub presiune. Acestea fiind spuse, interogările lente ale bazei de date nu pot fi întotdeauna rezolvate pur și simplu prin adăugarea de resurse suplimentare ale bazei de date. De aceea, sfătuim clienții să monitorizeze interogările lente ale bazei de date utilizând Query Monitor și New Relic (furnizate de platforma noastră). Acestea evidențiază locul în care interogările provin din baza de date, astfel încât echipa de dezvoltare să le poată refactoriza pentru a optimiza performanța.

În cele din urmă, asistența pentru aplicații și inginerii noștri Premier vă pot ajuta, de asemenea, echipa să găsească și să analizeze aceste interogări și să sugereze modalități de a le îmbunătăți pentru viteză și eficiență.

Scrieri excesive în baza de date

Uneori, o caracteristică, cum ar fi înregistrarea personalizată sau codul de urmărire, actualizează baza de date la fiecare solicitare. Acest lucru poate duce la instabilitate din două motive:

• Replicile bazei de date anterioare : Toate interogările de scriere sunt direcționate către baza de date primară; interogările ulterioare ale bazei de date pentru același tabel (sau tabele) din aceeași cerere de pagină vor fi, de asemenea, direcționate acolo. Nefolosind replicile bazei de date, acest lucru limitează scalabilitatea site-ului.
• Ocolirea stocării în cache a paginii : Pentru ca o scriere a bazei de date să aibă loc la fiecare solicitare de pagină, stocarea în cache a paginii trebuie să fie ocolită. Dar acest lucru înseamnă că prima (și cea mai bună) linie de apărare a fost compromisă.

Răspunsul WordPress VIP:

În aceste circumstanțe, recomandăm refactorizarea funcției. De exemplu, analiza conținutului este de obicei delegată cel mai bine unui serviciu extern care utilizează un fragment de JavaScript în pagină, mai degrabă decât codul de pe partea serverului, care nu funcționează bine cu stocarea în cache și poate duce la scrieri excesive în baza de date.

Alte cauze cunoscute ale timpului de nefuncționare și cum să le evitați

Pluginuri

Există mii de pluginuri populare și utile de la terți în ecosistemul WordPress care oferă caracteristici și funcționalități fantastice. Unii, totuși, au dificultăți de scalare, ceea ce poate duce la probleme de nefuncționare atunci când sunt adăugate la un site web cu o mulțime de conținut și trafic.

Răspunsul WordPress VIP:

În calitate de buni administratori ai ecosistemului, contactăm în mod regulat furnizorii cu sugestii pentru ca pluginurile lor să funcționeze mai bine în medii cu trafic ridicat. De asemenea, putem sugera pluginuri alternative care au fost încercate și testate la scară pe platforma noastră.

Înregistrare personalizată

Înregistrarea personalizată este un instrument puternic de depanare, adesea singura metodă viabilă de a urmări o eroare sau o problemă care pare să se întâmple doar pe un site de producție. Cu toate acestea, în numeroase ocazii, am văzut logare personalizată construită în PHP pe un site cu trafic ridicat încetinind lucrurile sau punând un site în pericol de nefuncționare prin scrieri excesive în baze de date.

Răspunsul WordPress VIP:

Pentru clienți, oferim acces la jurnalele PHP standard în panoul Sănătate din tabloul de bord al aplicației VIP WordPress. Acolo pot înregistra erori personalizate (și, de asemenea, în New Relic), care nu vor avea un impact negativ asupra bazei de date.

Apeluri API la distanță

Unele site-uri web profită de apelurile API REST de pe partea de server către alte aplicații sau servicii. Acestea sunt destul de rapide în circumstanțe normale, dar uneori codul aplicației de bază duce la un răspuns lent, expiră sau generează o eroare.

Răspunsul WordPress VIP:

Pentru a minimiza aceste probleme, recomandăm „codarea defensivă”. Depinde de scopul apelului de la distanță, dar adesea, atunci când o solicitare de la distanță eșuează, este posibil să se recurgă la un răspuns în cache de la o solicitare anterioară – sau cel puțin să „trateze eroarea cu grație”, astfel încât restul paginii să poată încărcă încă. Oferim o serie de funcții de ajutor pentru a gestiona aceste scenarii. Menținerea unui timeout scăzut înseamnă, de asemenea, că resursele PHP sunt eliberate mai rapid dacă API-ul de la distanță nu răspunde.

Citiți mai multe în seria noastră Avoiding CMS Disaster

Când afacerea dvs. este pe linie, nu vă puteți permite să trimiteți noi afaceri în altă parte și să vă pătați marca prin sistemul dvs. de management al conținutului (CMS) să ofere o experiență digitală slabă. În Cum să îmbunătățim performanța site-ului web , diagnosticăm cinci vinovați obișnuiți de încetinire și cum să turboalimentăm lucrurile folosind un CMS agil.

Zilele cu trafic intens ar trebui să fie un motiv de sărbătoare, nu un coșmar pentru inginerii care încearcă să mențină site-ul și aplicațiile în funcțiune și fredonând pentru a face față sarcinii - și reputația ta intactă. În Scaling WordPress for High Traffic , explorăm patru abordări pentru a permite unui site web WordPress să gestioneze acele valuri de trafic.