Găzduire Drupal: Ce Rulează Drupal Cu Adevărat Bine

Găzduirea Drupal este sursa celei mai mari părți din reputația de lentoare a Drupal și este aproape întotdeauna o decizie de achiziție, nu o problemă de software. Un site este construit corect, apoi este pus în funcțiune pe un plan tarifat pentru un site de prezentare cu o mână de fișiere PHP. Rezultatul este un sistem de management al conținutului cu o conductă de randare serioasă, care rulează într-o limită de memorie pe care nu o poate schimba, pe un cache de opcode pe care nu îl controlează, fără shell pentru propriile unelte.

Comparația pe care o face toată lumea în gând este cea cu WordPress și este cea greșită. WordPress rulează acceptabil pe aproape orice pentru că, prin cota lui de piață, i-a obligat pe furnizorii de găzduire să îl facă să ruleze acceptabil pe aproape orice. Drupal presupune un PHP actual, o bază de date recentă, un backend de cache adevărat, o linie de comandă și un proces de livrare care tratează codul ca pe un artefact de build, nu ca pe un folder pe care îl editezi.

De ce are nevoie Drupal, de fapt, de la o găzduire? O versiune de PHP la nivelul pragului pentru versiunea voastră sau peste, un MySQL, MariaDB sau PostgreSQL recent, în practică 256 MB de memorie PHP, OPcache, acces shell pentru Composer și Drush, o intrare cron adevărată și un cache de obiecte extern de îndată ce aveți utilizatori autentificați. Găzduirea partajată ieftină pică la trei sau patru dintre acestea deodată.

Ce cere Drupal cu adevărat de la un server

Cerințele publicate sunt scurte, precise și publice, iar aproape nimeni nu le citește înainte de a cumpăra. Sunt și legate de versiune într-un fel care contează chiar acum, pentru că două dintre praguri se mută în decembrie 2026.

Pragul versiunii de PHP nu este negociabil

Drupal 11 cere cel puțin PHP 8.3 și acceptă 8.3, 8.4 și 8.5. Drupal 10 cere 8.1 și merge până la 8.4, iar Drupal 12 ridică din nou pragul la PHP 8.5. Cifrele acestea vin din documentația Drupal despre cerințele PHP, singura versiune a acelei liste în care merită să ai încredere.

Contează mai mult decât pare, pentru că ramurile PHP în sine expiră. Pagina versiunilor acceptate de pe php.net fixează sfârșitul suportului de securitate pentru PHP 8.2 la 31 decembrie 2026, pentru 8.3 la 31 decembrie 2027 și pentru 8.4 la 31 decembrie 2028. PHP 8.1 este deja dincolo de această limită. Un furnizor care își face reclamă cu “PHP 8.1 și 8.2 disponibile” oferă o stivă care este deja fără patch-uri sau va fi în câteva luni.

Cele două termene se ciocnesc. Drupal 10 ajunge la sfârșitul suportului pe 9 decembrie 2026, iar Drupal 12 apare în aceeași săptămână, potrivit calendarului de lansări al nucleului. Dacă furnizorul vostru nu poate servi PHP 8.3 sau mai nou, după acea dată nu mai puteți rula un Drupal cu suport. Ghidul nostru despre costurile, opțiunile și termenele migrării Drupal explică ce înseamnă asta dacă sunteți încă pe 10.

Motoarele de baze de date și minimele lor reale

Drupal 11 vrea MariaDB 10.6 sau mai nou, MySQL 8.0 sau mai nou, PostgreSQL 16 sau mai nou ori SQLite 3.45 sau mai nou, conform cerințelor pentru serverul de baze de date. Drupal 10 este mai îngăduitor, cu MariaDB 10.3.7, MySQL 5.7.8, PostgreSQL 12 și SQLite 3.26, și exact de aceea un upgrade forțează uneori o actualizare de bază de date la care clientul nu se aștepta.

Două detalii sunt sărite. InnoDB trebuie să fie motorul de stocare pe MySQL și MariaDB, pentru că Drupal se bazează pe tranzacții și pe blocarea la nivel de rând. Pe PostgreSQL, extensia pg_trgm trebuie creată pe baza de date Drupal înainte de instalare, iar un serviciu de baze de date administrat care nu vă lasă să rulați CREATE EXTENSION nu este utilizabil.

SQLite chiar este acceptat și este în regulă pentru dezvoltarea locală, dar nu este un răspuns în producție de îndată ce mai mulți redactori salvează conținut, pentru că accesul concurent la scriere devine primul plafon.

Memorie, extensii și serverul web

Minimul documentat de Drupal este de 64 MB de memorie PHP și sub acest prag afișează avertismente. Aceeași pagină notează că 128 MB sau 256 MB sunt obișnuite în producție și că instalările bogate în media cer mai mult. În practică, tratați 256 MB ca valoare de lucru și așteptați-vă să o ridicați pentru linia de comandă, pentru că operațiunile lacome de memorie sunt Composer și migrările mari, nu servirea paginilor.

Lista de extensii nu are nimic ieșit din comun și merită totuși verificată: PDO cu un driver de bază de date, XML, JSON, mbstring, cURL, OpenSSL pentru HTTPS de ieșire și fie GD, fie ImageMagick pentru derivatele de imagini. Drupal 12 adaugă Argon2 pentru hashingul parolelor, încă un lucru pe care o compilare PHP foarte veche nu îl are.

Pe partea de server web, Drupal acceptă Apache 2.4.7 sau mai nou și Nginx 1.1 sau mai nou și nu mai acceptă Microsoft IIS începând cu Drupal 11.0.0. Apache are nevoie de mod_rewrite pentru URL-uri curate și de AllowOverride All pentru ca fișierul .htaccess livrat să se aplice. Ultimul punct prinde multă lume: unele reguli de protecție ale Drupal există doar în .htaccess, așa că o instalare pe Nginx trebuie să le reproducă manual în configurația serverului. Este un pas de rutină care este sărit de rutină și unul dintre primele lucruri pe care le căutăm într-un audit de securitate al serverului.

De ce găzduirea partajată eșuează cu Drupal

Găzduirea partajată nu este găzduire proastă. Este găzduire optimizată pentru o altă formă de aplicație, iar Drupal se lovește de restricțiile ei în patru locuri previzibile.

Fără shell nu există Composer și nici Drush

Drupalul modern este un proiect Composer. Nucleul, modulele contribuite și dependențele lor PHP sunt rezolvate toate de Composer, iar de îndată ce Composer administrează un modul trebuie să administreze și nucleul. Amestecarea Composer cu actualizări manuale de fișiere este felul în care un site ajunge să nu se mai poată actualiza deloc.

Un panou de control cu manager de fișiere nu poate face asta. Nici un client FTP. Fără SSH pierdeți și Drush, cu care se fac de fapt reconstrucțiile de cache, importurile de configurație, actualizările bazei de date și resetările de parole. Un site pe care nu puteți rula drush cr este un site unde fiecare pas de recuperare devine un tichet de suport.

Limitele pe care nu le vedeți, darămite să le schimbați

Un cont partajat vă dă un memory_limit stabilit de altcineva, de obicei 128 MB și uneori mai puțin, fără nicio cale de a-l ridica pentru singura migrare care are nevoie de 512 MB.

OPcache este problema mai mare. Păstrează în memoria partajată bytecodul precompilat al scripturilor, ca PHP să nu reanalizeze fișierele la fiecare cerere, iar pe o găzduire partajată acel bazin de memorie este împărțit între sute de conturi. Drupal are mii de fișiere PHP, deci este un chiriaș greu al unui bazin pentru care concurează, și ajunge evacuat. Simptomul este un site rapid un minut după o vizită și lent din nou o oră mai târziu.

Apoi este ce lipsește cu totul: fără Redis, fără Memcached, fără control asupra managerului de procese PHP și fără vreo cale de a rula un worker de coadă de lungă durată.

Cron care nu rulează niciodată cu adevărat

Modulul Automated Cron al Drupal rulează la fiecare trei ore în mod implicit și este declanșat de vizitatorii site-ului. Pe un site aglomerat asta înseamnă că, din când în când, un vizitator plătește indexarea căutării cu timpul lui de încărcare. Pe un site liniștit înseamnă că, practic, cronul nu rulează, deci indexul de căutare se învechește, tabelele de log nu sunt niciodată curățate, iar actualizările de securitate disponibile nu sunt niciodată verificate.

Documentația recomandă în schimb declanșarea cronului din exterior, pentru că atunci rulează mereu la timp și consumă mai puține resurse. Asta cere o intrare crontab adevărată, pe care treapta cea mai ieftină nu o oferă.

Straturile de cache și cel pe care îl atinge vizitatorul vostru

Drupal păstrează în cache mai mult decât își imaginează majoritatea, iar straturile nu sunt alternative. Se suprapun, iar fiecare prinde ce nu a putut prinde stratul de deasupra.

OPcache stă în întregime sub Drupal

OPcache nu este o funcție Drupal. Păstrează în cache bytecodul PHP compilat la nivelul interpretorului, deci se aplică fiecărei cereri, indiferent dacă vreun cache Drupal răspunde sau nu. Greșiți aici și nimic de deasupra nu poate compensa, pentru că fiecare cerere plătește recompilarea framework-ului înainte de a ajunge la router. Dimensionați generos memoria partajată și dezactivați validarea marcajelor de timp în producție, unde setul de fișiere se schimbă doar la livrare.

Internal Page Cache și Dynamic Page Cache

Internal Page Cache este un modul din nucleu, activ implicit, și servește doar utilizatorii anonimi. Presupune că fiecare vizitator anonim vede aceeași pagină, stochează întregul răspuns la prima cerere și îl refolosește. Pentru un site de marketing fără personalizare, acesta este stratul care face aproape toată treaba.

Dynamic Page Cache este tot din nucleu și tot activ implicit, iar el păstrează în cache pentru oricine, inclusiv pentru utilizatorii autentificați. Funcționează lăsând sistemul de randare să transforme în substituenți părțile cu adevărat personale ale unei pagini și punând în cache tot ce le înconjoară. De aceea o pagină Drupal văzută autentificat poate rămâne în mare parte în cache: doar meniul utilizatorului și câteva blocuri sunt cu adevărat dinamice.

BigPipe și cache-ul de randare

Sub amândouă stă cache-ul de randare, care păstrează blocuri individuale, câmpuri, rezultate de view-uri și randări de entități. O pagină care ratează page cache-ul este de obicei asamblată în mare parte din potriviri în cache-ul de randare, nu reconstruită din baza de date.

BigPipe se ocupă de ce rămâne. Este în nucleu de la Drupal 8.1, stabil de la 8.3 și în profilul de instalare standard de la 8.5. În loc să aștepte rezolvarea fiecărui substituent, trimite imediat pagina care poate fi pusă în cache și transmite după aceea fragmentele personalizate. Nu are nevoie de configurare și îi ajută pe utilizatorii autentificați mult mai mult decât pe cei anonimi.

Așadar, pe un site bine configurat, vizitatorul anonim atinge Internal Page Cache, sau CDN-ul din fața lui, și nu ajunge niciodată la cea mai mare parte din restul. Redactorul autentificat atinge la fiecare cerere Dynamic Page Cache, cache-ul de randare și BigPipe, motiv pentru care traficul autentificat costă mult mai mult.

Cache-ul de obiecte extern

Fiecare strat de mai sus are nevoie de un loc unde să își țină intrările. În mod implicit acela este baza de date, în tabele de cache, ceea ce înseamnă că citirile voastre din cache concurează cu interogările de conținut pe același server.

Modulul Redis mută backendurile de cache, de blocări, de flood și de cozi pe Redis sau pe un depozit compatibil precum Valkey, folosind extensia PhpRedis, extensia Relay sau biblioteca Predis scrisă în PHP pur. Memcached este alternativa echivalentă. Pentru un site mic și anonim asta schimbă puțin. Pentru un site cu utilizatori autentificați este de obicei cea mai mare îmbunătățire disponibilă, pentru că scoate din baza de date cea mai zgomotoasă sarcină de scriere și ieftinește blocările.

Reverse proxy și CDN în fața Drupal

Un reverse proxy precum Varnish sau Nginx, ori un CDN, răspunde cererilor înainte ca PHP să fie implicat. Pentru traficul anonim asta este diferența dintre a servi o pagină în milisecunde dintr-o cifră și a o servi în câteva sute. Este și stratul de care oamenilor le este cel mai frică, pentru că un cache învechit pe un site de știri sau într-un magazin este o defecțiune vizibilă.

Etichetele de cache sunt cele care fac un CDN sigur

Răspunsul Drupal sunt etichetele de cache. Etichetele de cache descriu dependențele de date și se scriu ca șiruri de tipul node:5, user:3 sau node_list. Fiecare element din cache înregistrează de ce etichete depinde, așa că editarea nodului 5 invalidează fiecare fragment, pagină și view din cache care îl referea, oriunde ar fi apărut.

Partea importantă este că Drupal poate publica acele etichete în exterior. Modulele contribuite le emit ca antet Surrogate-Key pentru Fastly sau Cache-Tag pentru Cloudflare, iar CDN-ul golește apoi după etichetă atunci când spune Drupal. Asta transformă un CDN dintr-un pariu bazat pe timp într-un cache condus de evenimente: puteți seta o durată de viață lungă, pentru că o editare golește exact URL-urile afectate în câteva secunde.

Atenție la bugetul de antet. Documentația Cloudflare despre golirea după etichetă de cache limitează antetul Cache-Tag agregat la 16 KB după numele câmpului, aproximativ 1.000 de etichete unice, cu maximum 1.024 de caractere pe etichetă într-un apel API și 100 de etichete pe golire din panou. Un view Drupal care listează multe entități poate genera mult mai multe etichete de atât, așa că o pagină care listează totul va face antetul să depășească limita în tăcere, dacă modulul nu este configurat să le scurteze sau să le treacă prin hash.

Alegerea găzduirii Drupal: patru trepte, sincer

Există patru opțiuni reale, iar cea corectă se decide după cum aveți sau nu trafic autentificat și după cum aveți sau nu pe cineva care să opereze serverul. Benzile de mai jos sunt ce plătesc de obicei clienții britanici, din experiența noastră, fără TVA, și sunt orientative, nu cotații de la vreun furnizor.

Găzduire partajată

Nu i se potrivește nimănui care rulează Drupal în producție. Pică simultan la acces shell, memorie, cache de opcode, cache de obiecte și cron. Dacă bugetul chiar se oprește aici, o instanță mică neadministrată la un preț asemănător este o folosire mai bună a banilor.

VPS sau instanță cloud neadministrată

Aproximativ GBP 20 până la GBP 120 pe lună cumpără o mașină cu root complet, ceea ce se potrivește marii majorități a site-urilor Drupal. Alegeți versiunea de PHP, dimensionați OPcache, instalați Redis, puneți un crontab și configurați Nginx cum trebuie. Ce nu primiți este cineva care să facă asta, să aplice patch-uri, să monitorizeze sau să restaureze la două noaptea. Treapta aceasta este cea corectă când aveți un dezvoltator sau o agenție pe abonament, iar abonamentul este costul real, nu instanța.

Platforme specializate de Drupal administrat

Găzduirea Drupal administrată pornește pe la GBP 40 pe lună pentru un site mic și urcă repede cu traficul, mediile și nivelul de suport. Ce cumpărați este o stivă impusă care este deja corectă, plus livrare bazată pe Git, medii de testare, copii de siguranță și cineva care înțelege Drupal la celălalt capăt al firului. Merită banii când alternativa este nimeni și nu îi merită când plătiți prețuri de platformă pentru un site de prezentare cu 4.000 de vizite pe lună.

Infrastructură complet personalizată

Bază de date separată, noduri de cache dedicate, servere de aplicație în spatele unui echilibrator de încărcare, stocare de obiecte pentru fișiere. Începe să aibă sens peste aproximativ GBP 400 pe lună și numai când traficul autentificat, integrările sau cerințele de conformitate fac treptele administrate incomode. Este treapta cea mai capabilă și cea mai solicitantă, pentru că acum sunt ale voastre și patch-urile, și monitorizarea, și recuperarea în caz de dezastru. Ghidul nostru de dezvoltare web cu Drupal arată de unde vine acea complexitate pe partea de aplicație.

Livrare: nu editați fișiere pe server

Pentru că Composer rezolvă întregul arbore de dependențe, codul de pe server este un rezultat, nu un spațiu de lucru. Editarea pe loc a fișierului unui modul înseamnă că următorul composer update îl va suprascrie și înseamnă că, în producție, codul vostru nu mai corespunde cu nimic din Git.

Un proces de lansare sănătos construiește artefactul în altă parte. Rulați composer install din fișierul composer.lock comis, în CI, ca build-ul să fie reproductibil și ca serverul de producție să nu aibă nevoie niciodată de Composer, de memorie PHP pentru rezolvarea dependențelor sau de drept de scriere în vendor. Trimiteți rezultatul, rulați actualizările bazei de date, importați configurația, reconstruiți cache-urile. Revenirea înseamnă să arătați spre artefactul anterior.

Asta rezolvă discret și întrebarea despre găzduire. Un furnizor care se așteaptă să editați fișiere prin FTP este incompatibil cu felul în care se întreține Drupal, orice ar scrie în fișa lui tehnică.

Unde se potrivește sincronizarea configurației

Drupal ține configurația activă în baza de date și o exportă în fișiere YAML, și așa se mută tipurile de conținut, câmpurile, view-urile și setările între medii. Documentația despre managementul configurației explică faptul că UUID-ul site-ului trebuie să coincidă între sursă și destinație, ceea ce este motivul obișnuit pentru care un prim import eșuează.

Practic, asta înseamnă că configurația este cod. Este comisă, revizuită și livrată împreună cu restul, iar pasul de import rulează ca parte din lansare, în loc să fie apăsat după aceea în interfața de administrare. Găzduirea trebuie să suporte asta: aveți nevoie de un loc unde să rulați importul și de un mediu în care un import eșuat să poată fi anulat, nu aplicat pe jumătate în producție.

Fișiere, media și copii de siguranță

Drupal are două sisteme de fișiere, iar diferența contează. Cel public stă sub rădăcina web și este servit direct de serverul web. Cel privat stă în afara rădăcinii web, iar fiecare cerere pentru un fișier privat trece prin Drupal, ca dreptul de acces să fie verificat.

Fișierele private sunt deci mult mai scumpe decât cele publice, pentru că fiecare descărcare pornește PHP, așa că un site care servește documente private mari are nevoie de o rezervă de care un server de fișiere statice nu ar avea nevoie.

Mutarea mediei pe stocare de obiecte

De îndată ce fișierele stau pe serverul de aplicație, scalarea orizontală și reconstrucțiile devin dureroase, iar fiecare copie de siguranță cară cu ea toată biblioteca de media. Mutarea sistemului public de fișiere pe stocare de obiecte compatibilă S3 le separă, lasă CDN-ul să servească media direct și face serverul de aplicație cu adevărat de unică folosință.

Un test de restaurare dovedește ce nu poate dovedi o copie de siguranță

O copie de siguranță dovedește că un fișier există. Un test de restaurare dovedește că fișierul este complet, că baza de date și fișierele vin din același moment, că datele voastre de acces încă funcționează și că știți cât durează. Sunt patru moduri de eșec diferite și niciunul nu se vede dintr-o bifă verde într-un panou de control.

Testați-l cu un cronometru adevărat cel puțin de două ori pe an și notați cifra. Dacă restaurarea durează șase ore, iar toleranța voastră este de o oră, arhitectura este problema, nu copia de siguranță. Timpul de revenire este o cerință de găzduire și își are locul în caietul de sarcini, nu într-un incident.

Dimensionarea corectă a unei găzduiri Drupal

Afișările de pagină sunt unitatea greșită. Un site cu 200.000 de afișări anonime pe lună în spatele unui CDN poate sta comod pe o instanță mică, în timp ce un site cu 8.000 de afișări se poate chinui dacă majoritatea sunt văzute de utilizatori autentificați.

Traficul autentificat este factorul real

Cererile anonime pot fi servite de page cache sau de CDN fără să atingă PHP. Cele autentificate nu. Fiecare dintre ele parcurge conducta de randare, verifică drepturile pe fiecare entitate, rezolvă substituenții și scrie date de sesiune. Întrebarea practică nu este câte vizite primiți, ci câți utilizatori autentificați simultani aveți și ce au voie să vadă acei utilizatori.

Redactorii sunt cazul extrem. Ecranele de administrare a conținutului sunt printre cele mai grele pagini din Drupal și nu pot fi puse în cache prin definiție, așa că un site cu doisprezece redactori care lucrează în același timp are o cerință reală de concurență pe care traficul lui public nu o sugerează niciodată.

View-uri, taxonomie și munca de coadă

Dincolo de traficul autentificat, centrele de cost sigure sunt view-urile mari cu multe filtre și relații, care generează îmbinări scumpe, arborii de taxonomie adânci, unde ierarhiile de termeni sunt parcurse la fiecare randare, și munca de cron sau de coadă, precum indexarea căutării, importurile de fluxuri și generarea derivatelor de media.

Workerii de coadă nu ar trebui să împartă resursele serverului web cu vizitatorii, dacă puteți evita asta. Pe un site mai mare, locul lor este într-un proces sau într-o instanță separată, ca un teanc de importuri să nu poată încetini partea vizibilă. Este o decizie de arhitectură luată la cumpărare și este punctul în care treptele administrate încetează să se potrivească și începe să se potrivească infrastructura proprie.

Cum luați decizia corect

Tiparul este constant. Găzduirea nu este subdimensionată, ci are forma greșită: fără shell, fără cache de obiecte, un cache de opcode controlat de altcineva și o versiune de PHP pe cale să iasă din suport. Mutarea aceluiași site pe o instanță specificată corect, la un preț asemănător, bate de obicei orice cantitate de optimizare pe partea vizibilă.

Mecanik specifică, construiește și întreține infrastructură Drupal ca parte din munca noastră de dezvoltare de site-uri web și revizuiește stivele existente printr-un audit de securitate al serverului când preocuparea este expunerea, nu viteza. Dacă aveți nevoie de oameni, nu de o platformă, ghidul nostru despre angajarea unui dezvoltator Drupal arată la ce să vă uitați.

Întrebări frecvente

Care sunt cerințele minime de server pentru Drupal 11? PHP 8.3 sau mai nou și, ca bază de date, MariaDB 10.6, MySQL 8.0, PostgreSQL 16 sau SQLite 3.45. Pe partea de server web, Apache 2.4.7 sau Nginx 1.1 și mai nou, Microsoft IIS nemaifiind acceptat începând cu Drupal 11.0.0. Drupal avertizează sub 64 MB de memorie PHP, dar 256 MB este cifra realistă în producție.

Poate rula Drupal pe găzduire partajată? Se instalează și servește pagini, dar găzduirea partajată pică de obicei la trei sau patru cerințe deodată: fără acces shell pentru Composer sau Drush, o limită de memorie PHP pe care nu o puteți ridica, fără Redis sau Memcached și un cron care pornește doar când se nimerește ca un vizitator să încarce o pagină. Aceste condiții produc reputația de lentoare a Drupal.

Cât ar trebui să coste găzduirea Drupal? Un site Drupal mic pe o instanță neadministrată configurată corect stă de obicei între GBP 20 și GBP 120 pe lună, înainte să îl administreze cineva. Platformele Drupal administrate pornesc de obicei pe la GBP 40 și urcă în sute odată cu traficul și mediile. Infrastructura proprie începe să aibă sens peste aproximativ GBP 400. Treapta cea mai ieftină este rareori și rezultatul cel mai ieftin.

Are Drupal nevoie de Redis? Nu pentru un site mic și anonim, unde page cache-ul intern și baza de date sunt suficiente. De îndată ce aveți utilizatori autentificați, redactori sau o zonă de membri, un cache de obiecte extern precum Redis sau Memcached scoate din baza de date citirile de cache, blocările și cozile, și este de obicei cea mai mare îmbunătățire pe care o puteți obține pe banii aceia.

Este sigur un CDN în fața unui site Drupal dinamic? Da, cu condiția să invalidați după etichetă de cache, nu după timp. Drupal înregistrează etichete precum node:5 pentru tot de ce depinde un răspuns, iar modulele le traduc în anteturi Cache-Tag sau Surrogate-Key, ca CDN-ul să golească exact paginile afectate de o editare. Fără invalidare după etichetă alegeți între pagini învechite și un cache care nu ajută niciodată.