Drupal Tárhely: Mi Kell Ahhoz, Hogy Jól Fusson

A Drupal tárhely az a pont, ahonnan a “lassú a Drupal” hírnév nagy része származik, és szinte mindig beszerzési döntésről van szó, nem szoftveres problémáról. Egy webhely rendesen elkészül, aztán olyan csomagon indul el, amelyet néhány PHP fájlból álló bemutatkozó oldalra áraztak. Az eredmény egy komoly renderelési láncot futtató tartalomkezelő rendszer, amely olyan memóriakorláton belül fut, amelyet nem tud megváltoztatni, olyan opcode gyorsítótáron, amelyet nem ő irányít, és shell nélkül, így a saját eszközeit sem tudja futtatni.

Az összehasonlítás, amelyet mindenki fejben elvégez, a WordPress, és ez a rossz összehasonlítás. A WordPress szinte bármin elfogadhatóan fut, mert a piaci részesedése rákényszerítette a szolgáltatókat, hogy szinte bármin elfogadhatóan futtassák. A Drupal friss PHP-t, friss adatbázist, valódi gyorsítótár háttértárat, parancssort és olyan telepítési folyamatot feltételez, amely a kódbázist build eredményként kezeli, nem pedig szerkesztgetett mappaként.

Mire van valójában szüksége a Drupalnak egy tárhelytől? A kiadásához tartozó minimumot elérő vagy annál újabb PHP verzió, friss MySQL, MariaDB vagy PostgreSQL, a gyakorlatban 256 MB PHP memória, OPcache, shell hozzáférés a Composerhez és a Drushhoz, valódi cron bejegyzés, és külső objektum gyorsítótár, amint bejelentkezett felhasználói vannak. Az olcsó megosztott tárhely ezek közül háromon vagy négyen egyszerre bukik el.

Mit követel meg valójában a Drupal egy szervertől

A közzétett követelmények rövidek, konkrétak és nyilvánosak, és vásárlás előtt szinte senki nem olvassa el őket. Emellett verziófüggők is, ami éppen most számít, mert két küszöb 2026 decemberében elmozdul.

A PHP verzió küszöbe nem alku tárgya

A Drupal 11 legalább PHP 8.3-at követel, és a 8.3, 8.4 és 8.5 verziót támogatja. A Drupal 10 a 8.1-et kéri és 8.4-ig megy el, a Drupal 12 pedig ismét megemeli a küszöböt PHP 8.5-re. Ezek a számok a Drupal saját PHP követelmény dokumentációjából származnak, ami ennek a listának az egyetlen megbízható változata.

Ez többet nyom a latban, mint amennyinek látszik, mert maguk a PHP ágak is lejárnak. A php.net támogatott verziókat felsoroló oldala a PHP 8.2 biztonsági támogatásának végét 2026. december 31-re teszi, a 8.3-ét 2027. december 31-re, a 8.4-ét pedig 2028. december 31-re. A PHP 8.1 már túl van rajta. Az a szolgáltató, amely azzal hirdet, hogy “PHP 8.1 és 8.2 elérhető”, olyan rendszert kínál, amely már most javítatlan, vagy hónapokon belül azzá válik.

A két határidő egymásba csúszik. A Drupal 10 2026. december 9-én éri el a támogatás végét, és a Drupal 12 ugyanazon a héten jelenik meg, a core kiadási ütemterv szerint. Ha a szolgáltatója nem tud PHP 8.3-at vagy újabbat kiszolgálni, azután nem futtathat támogatott Drupalt. A Drupal migráció költségeiről, útjairól és határidőiről szóló útmutatónk arról szól, mit jelent ez, ha még a 10-en van.

Az adatbázismotorok és valódi minimumaik

A Drupal 11 MariaDB 10.6-ot vagy újabbat, MySQL 8.0-t vagy újabbat, PostgreSQL 16-ot vagy újabbat, illetve SQLite 3.45-öt vagy újabbat kér, az adatbázisszerver követelményei szerint. A Drupal 10 elnézőbb: MariaDB 10.3.7, MySQL 5.7.8, PostgreSQL 12 és SQLite 3.26 elég neki, és pontosan ezért kényszerít ki egy frissítés néha olyan adatbázis frissítést is, amire az ügyfél nem számított.

Két részlet szokott kimaradni. Az InnoDB legyen a tárolómotor MySQL és MariaDB alatt, mert a Drupal tranzakciókra és sor szintű zárolásra épít. PostgreSQL alatt a pg_trgm kiterjesztést a telepítés előtt létre kell hozni a Drupal adatbázisán, és az a felügyelt adatbázis szolgáltatás, amely nem engedi a CREATE EXTENSION parancsot, használhatatlan.

Az SQLite valóban támogatott és helyi fejlesztéshez rendben van, de éles üzemben nem válasz, amint több szerkesztő ment tartalmat, mert az írási párhuzamosság lesz a legelső korlát.

Memória, kiterjesztések és a webszerver

A Drupal dokumentált minimuma 64 MB PHP memória, és ez alatt figyelmeztetéseket jelenít meg. Ugyanaz az oldal megjegyzi, hogy éles környezetben a 128 MB vagy 256 MB a jellemző, és hogy a médiában gazdag telepítéseknek több kell. A gyakorlatban kezelje a 256 MB-ot munkaértéknek, és számítson arra, hogy a parancssor kedvéért emelnie kell rajta, mert a memóriaéhes műveletek a Composer és a nagy migrációk, nem az oldalak kiszolgálása.

A kiterjesztések listája nem tartogat meglepetést, és mégis érdemes ellenőrizni: PDO adatbázis illesztőprogrammal, XML, JSON, mbstring, cURL, OpenSSL a kimenő HTTPS-hez, és GD vagy ImageMagick a képváltozatokhoz. A Drupal 12 hozzáteszi az Argon2-t a jelszó hasheléshez, ami még egy dolog, ami egy nagyon régi PHP fordításban nincs benne.

A webszerver oldalán a Drupal az Apache 2.4.7-et vagy újabbat és az Nginx 1.1-et vagy újabbat támogatja, a Microsoft IIS-t pedig a Drupal 11.0.0 óta nem támogatja. Az Apache-nak kell a mod_rewrite a tiszta URL-ekhez és az AllowOverride All, hogy a szállított .htaccess érvényesüljön. Ez utóbbi sokakat megfog: a Drupal néhány védelmi szabálya csak a .htaccess fájlban létezik, ezért egy Nginx telepítésnek kézzel kell ezeket a szerver konfigurációjában reprodukálnia. Rutinlépés, amely rutinszerűen elmarad, és az egyik első dolog, amit egy szerver biztonsági auditban keresünk.

Miért bukik el a megosztott tárhely a Drupallal

A megosztott tárhely nem rossz tárhely. Más alkalmazásformára optimalizált tárhely, és a Drupal négy kiszámítható ponton ütközik a korlátaiba.

Shell nélkül nincs Composer és nincs Drush

A modern Drupal Composer projekt. A core, a közösségi modulok és azok PHP függőségei mind a Composeren keresztül oldódnak fel, és amint a Composer kezel egy modult, a core-t is kezelnie kell. A Composer és a kézi fájlfrissítések keverése az az út, amelynek a végén a webhely egyáltalán nem frissíthető.

Egy fájlkezelővel felszerelt vezérlőpult erre nem képes. Egy FTP kliens sem. SSH nélkül a Drush is elveszik, pedig a gyorsítótár újraépítés, a konfiguráció importálás, az adatbázis frissítés és a jelszó visszaállítás valójában ezzel történik. Az a webhely, amelyen nem tud drush cr parancsot futtatni, olyan webhely, ahol minden helyreállítási lépésből támogatási jegy lesz.

A korlátok, amelyeket nem lát, nemhogy módosítana

Egy megosztott fiókban a memory_limit értékét más állítja be, jellemzően 128 MB-ra, néha kevesebbre, és nincs mód megemelni azért az egy migrációért, amelynek 512 MB kell.

Az OPcache a nagyobb gond. A szkriptek előfordított bájtkódját tárolja osztott memóriában, hogy a PHP ne elemezze újra a fájlokat minden kérésnél, megosztott tárhelyen viszont ezen a memóriakészleten több száz fiók osztozik. A Drupalnak több ezer PHP fájlja van, tehát nehéz bérlője egy olyan készletnek, amelyért versenyez, és ki is szorul belőle. A tünet az a webhely, amely egy látogatás után egy percig gyors, egy órával később pedig ismét lassú.

Aztán ott van az, ami teljesen hiányzik: nincs Redis, nincs Memcached, nincs befolyás a PHP folyamatkezelőre, és nincs mód hosszan futó sorkezelő futtatására.

A cron, amely soha nem fut igazán

A Drupal Automated Cron modulja alapértelmezés szerint háromóránként fut, és a webhely látogatói indítják el. Forgalmas webhelyen ez azt jelenti, hogy időnként egy látogató fizeti meg a keresési indexelést a saját betöltési idejével. Csendes webhelyen azt jelenti, hogy a cron gyakorlatilag nem fut, így a keresési index elavul, a naplótáblákat soha nem nyesik meg, és az elérhető biztonsági frissítéseket soha nem ellenőrzi senki.

A dokumentáció ehelyett a cron külső indítását javasolja, mert így mindig időben lefut és kevesebb erőforrást használ. Ehhez valódi crontab bejegyzés kell, amit a legolcsóbb szint nem ad meg.

A gyorsítótár rétegei, és amelyikbe a látogatója beleütközik

A Drupal többet gyorsítótáraz, mint azt a legtöbben gondolják, és a rétegek nem alternatívák. Egymásra épülnek, és mindegyik felfogja azt, amit a fölötte lévő nem tudott.

Az OPcache teljes egészében a Drupal alatt helyezkedik el

Az OPcache nem Drupal funkció. A lefordított PHP bájtkódot gyorsítótárazza az értelmező szintjén, tehát minden kérésre vonatkozik, függetlenül attól, hogy bármelyik Drupal gyorsítótár talál-e. Ha ezt elrontja, semmi felette nem tudja ellensúlyozni, mert minden kérés kifizeti a keretrendszer újrafordítását, mielőtt egyáltalán az útválasztóig érne. Méretezze bőkezűen az osztott memóriát, és éles környezetben kapcsolja ki az időbélyeg ellenőrzést, ahol a fájlkészlet csak telepítéskor változik.

Internal Page Cache és Dynamic Page Cache

Az Internal Page Cache core modul, alapértelmezés szerint bekapcsolva, és kizárólag a névtelen látogatókat szolgálja ki. Abból indul ki, hogy minden névtelen látogató ugyanazt az oldalt látja, az első kérésnél eltárolja a teljes választ, és újra felhasználja. Egy személyre szabás nélküli marketing webhelyen ez a réteg végzi el majdnem az összes munkát.

A Dynamic Page Cache szintén a core része és szintén alapértelmezés szerint be van kapcsolva, és bárkinek gyorsítótáraz, a bejelentkezett felhasználóknak is. Úgy működik, hogy a renderelő rendszer az oldal valóban személyes részeit helyőrzőkké alakítja, és mindent gyorsítótáraz körülöttük. Ezért maradhat egy bejelentkezve megnézett Drupal oldal is nagyrészt gyorsítótárazva: valójában csak a felhasználói menü és néhány blokk dinamikus.

BigPipe és a renderelési gyorsítótár

Mindkettő alatt a renderelési gyorsítótár található, amely az egyes blokkokat, mezőket, nézeteredményeket és entitás megjelenítéseket tárolja. Az az oldal, amely elvéti az oldal gyorsítótárat, általában nagyrészt a renderelési gyorsítótár találataiból áll össze, nem az adatbázisból épül újra.

A BigPipe kezeli a maradékot. A Drupal 8.1 óta a core része, a 8.3 óta stabil, a 8.5 óta pedig benne van a szabványos telepítési profilban. Ahelyett, hogy megvárná minden helyőrző feloldását, azonnal kiküldi a gyorsítótárazható oldalt, és utána streameli be a személyre szabott töredékeket. Nem kell hozzá beállítás, és a bejelentkezett felhasználóknak sokkal többet segít, mint a névteleneknek.

Egy jól beállított webhelyen tehát a névtelen látogató az Internal Page Cache-be, vagy az előtte álló CDN-be fut bele, és ennek a nagy részét soha nem érinti. A bejelentkezett szerkesztő minden kérésnél a Dynamic Page Cache-t, a renderelési gyorsítótárat és a BigPipe-ot használja, és ezért kerül a bejelentkezett forgalom ennyivel többe.

A külső objektum gyorsítótár

A fenti összes rétegnek kell egy hely, ahol a bejegyzéseit tárolja. Alapértelmezés szerint ez az adatbázis, gyorsítótár táblákban, ami azt jelenti, hogy a gyorsítótár olvasásai ugyanazon a szerveren versengenek a tartalmi lekérdezésekkel.

A Redis modul a gyorsítótár, a zárolás, a flood és a sor háttértárait a Redisre vagy egy vele kompatibilis tárolóra, például a Valkey-re helyezi át, akár a PhpRedis kiterjesztéssel, akár a Relay kiterjesztéssel, akár a tiszta PHP-ben írt Predis könyvtárral. A Memcached ennek egyenértékű alternatívája. Egy kis, névtelen forgalmú webhelyen ez keveset változtat. Bejelentkezett felhasználókkal működő webhelyen viszont általában ez a legnagyobb elérhető javulás, mert leveszi az adatbázisról a leghangosabb írási terhelést, és olcsóvá teszi a zárolást.

Fordított proxy és CDN a Drupal előtt

Egy fordított proxy, például a Varnish vagy az Nginx, illetve egy CDN már azelőtt válaszol a kérésekre, hogy a PHP egyáltalán szóhoz jutna. Névtelen forgalomnál ez a különbség aközött, hogy egy oldal egy számjegyű ezredmásodperc alatt vagy néhány száz alatt megy ki. Ez egyben az a réteg, amelytől a legtöbben félnek, mert egy elavult gyorsítótár egy hírportálon vagy egy webáruházban látható hiba.

A gyorsítótár címkék teszik biztonságossá a CDN-t

A Drupal válasza a gyorsítótár címke. A gyorsítótár címkék adatfüggőségeket írnak le, és olyan szövegként jelennek meg, mint a node:5, a user:3 vagy a node_list. Minden gyorsítótárazott elem rögzíti, mely címkéktől függ, így az 5-ös node szerkesztése érvényteleníti az összes olyan gyorsítótárazott töredéket, oldalt és nézetet, amely hivatkozott rá, bárhol is jelent meg.

A lényeg az, hogy a Drupal ki tudja adni ezeket a címkéket kifelé is. Közösségi modulok Surrogate-Key fejlécként küldik a Fastlynek vagy Cache-Tag fejlécként a Cloudflare-nek, a CDN pedig címke szerint ürít, amikor a Drupal szól. Ezzel a CDN időalapú szerencsejátékból eseményvezérelt gyorsítótárrá válik: hosszú élettartamot állíthat be, mert egy szerkesztés másodperceken belül pontosan az érintett URL-eket üríti.

Figyeljen a fejléc keretre. A Cloudflare gyorsítótár címke szerinti ürítésről szóló dokumentációja a mezőnév utáni összesített Cache-Tag fejlécet 16 KB-ban maximálja, ami nagyjából 1 000 egyedi címke, egy API híváson belül címkénként legfeljebb 1 024 karakterrel, a vezérlőpultról indított ürítésnél pedig 100 címkével. Egy sok entitást listázó Drupal nézet ennél jóval több címkét is generálhat, így egy mindent felsoroló oldal csendben túlcsordítja a fejlécet, hacsak a modult nem állítják be a címkék rövidítésére vagy hashelésére.

Drupal tárhely választása: négy szint, őszintén

Négy valódi lehetőség van, és a helyeset az dönti el, hogy van-e bejelentkezett forgalma, és hogy van-e valakije, aki a szervert üzemelteti. Az alábbi sávok azt mutatják, amit tapasztalatunk szerint a brit ügyfelek jellemzően fizetnek, áfa nélkül, és tájékoztató jellegűek, nem egy szolgáltató ajánlatából származnak.

Megosztott tárhely

Senkinek nem való, aki éles üzemben futtat Drupalt. Egyszerre bukik el shell hozzáférésen, memórián, opcode gyorsítótáron, objektum gyorsítótáron és cronon. Ha a keret tényleg itt ér véget, egy hasonló árú kis, nem felügyelt példány jobb felhasználása a pénznek.

Nem felügyelt VPS vagy felhőpéldány

Nagyjából GBP 20 és GBP 120 között havonta olyan gépet kap, amelyen teljes root jogosultsága van, és ez a Drupal webhelyek nagy többségének megfelel. Ön választja ki a PHP verziót, méretezi az OPcache-t, telepíti a Redist, beállít egy crontabot és rendesen konfigurálja az Nginxet. Amit nem kap meg, az az ember, aki mindezt megcsinálja, javítja, figyeli vagy hajnali kettőkor visszaállítja. Ez a szint akkor helyes, ha van fejlesztője vagy ügynöksége havidíjas szerződéssel, és a valódi költség a szerződés, nem a példány.

Felügyelt, Drupalra szakosodott platformok

A felügyelt Drupal tárhely kis webhelynél havi GBP 40 körül indul, és a forgalommal, a környezetekkel és a támogatási szinttel gyorsan emelkedik. Amit vásárol, az egy előre eldöntött, már eleve helyes rendszer, mellé Git alapú telepítés, teszt környezetek, mentések és valaki a vonal végén, aki érti a Drupalt. Jó vétel, amikor az alternatíva a semmi, és rossz vétel, amikor platform árat fizet egy bemutatkozó oldalért, amely havi 4 000 látogatást kap.

Teljesen egyedi infrastruktúra

Külön adatbázis, dedikált gyorsítótár csomópontok, alkalmazásszerverek egy terheléselosztó mögött, objektumtár a fájloknak. Nagyjából havi GBP 400 felett kezd értelmet nyerni, és csak akkor, ha a bejelentkezett forgalom, az integrációk vagy a megfelelőségi elvárások kényelmetlenné teszik a felügyelt szinteket. Ez a legtöbbre képes és egyben a legtöbbet követelő szint, mert innentől a javítás, a felügyelet és a katasztrófa utáni helyreállítás is az Öné. A Drupal webfejlesztésről szóló útmutatónk arról szól, honnan ered ez a bonyolultság az alkalmazás oldalán.

Telepítés: a fájlokat nem a szerveren szerkesztjük

Mivel a Composer oldja fel a teljes függőségi fát, a szerveren lévő kódbázis eredmény, nem munkaterület. Egy modul fájljának helyben szerkesztése azt jelenti, hogy a következő composer update felülírja, és azt is, hogy az éles kód már semminek nem felel meg a Gitben.

Egy józan kiadási folyamat máshol állítja elő a build eredményét. Futtassa a composer install parancsot a verziókövetett composer.lock alapján a CI-ben, hogy a build megismételhető legyen, és hogy az éles kiszolgálónak soha ne kelljen sem Composer, sem PHP memória a függőségfeloldáshoz, sem írási jog a vendor könyvtárra. Küldje ki az eredményt, futtassa az adatbázis frissítéseket, importálja a konfigurációt, építse újra a gyorsítótárakat. A visszaállítás annyi, hogy az előző csomagra mutat.

Ez csendben eldönti a tárhely kérdést is. Az a szolgáltató, amely azt várja, hogy FTP-n szerkessze a fájlokat, összeegyeztethetetlen azzal, ahogyan a Drupalt karban kell tartani, bármi álljon az adatlapján.

Hol illeszkedik a konfiguráció szinkronizálása

A Drupal az aktív konfigurációt az adatbázisban tartja, és YAML fájlokba exportálja, így mozognak a tartalomtípusok, a mezők, a nézetek és a beállítások a környezetek között. A konfigurációkezelés dokumentációja elmagyarázza, hogy a webhely UUID azonosítójának egyeznie kell a forrás és a cél között, és rendszerint ezen bukik el az első import.

A gyakorlatban ez azt jelenti, hogy a konfiguráció kód. Verziókövetik, átnézik és a többivel együtt telepítik, az import lépés pedig a kiadás részeként fut le, nem pedig utólag kattintják végig az adminisztrációs felületen. A tárhelynek ezt támogatnia kell: kell egy hely, ahol az import lefuthat, és olyan környezet, ahol egy elbukott import visszavonható ahelyett, hogy félig alkalmazva maradna az éles rendszeren.

Fájlok, média és mentések

A Drupalnak két fájlrendszere van, és a különbség súlyos. A nyilvános a webgyökér alatt található, és közvetlenül a webszerver szolgálja ki. A privát a webgyökéren kívül van, és minden privát fájlra irányuló kérés áthalad a Drupalon, hogy a jogosultság ellenőrizhető legyen.

A privát fájlok ezért sokkal drágábbak a nyilvánosaknál, mert minden letöltés elindítja a PHP-t, így a nagy privát dokumentumokat kiszolgáló webhelynek olyan tartalékra van szüksége, amilyenre egy statikus fájlkiszolgálónak nem lenne.

A média áthelyezése objektumtárba

Amint a fájlok az alkalmazásszerveren élnek, a vízszintes skálázás és az újraépítés kínossá válik, és minden mentés magával viszi a teljes médiatárat. Ha a nyilvános fájlrendszert S3-kompatibilis objektumtárba helyezi át, a kettő szétválik, a CDN közvetlenül szolgálhatja ki a médiát, az alkalmazásszerver pedig valóban eldobhatóvá válik.

A visszaállítási teszt azt bizonyítja, amit a mentés nem tud

A mentés azt bizonyítja, hogy egy fájl létezik. A visszaállítási teszt azt bizonyítja, hogy a fájl teljes, hogy az adatbázis és a fájlok ugyanabból a pillanatból származnak, hogy a hozzáférései még működnek, és hogy tudja, mennyi ideig tart. Ez négy különálló hibalehetőség, és egyik sem látszik egy vezérlőpult zöld pipájából.

Tesztelje valódi stopperrel legalább évente kétszer, és írja fel a számot. Ha a visszaállítás hat órát vesz igénybe, a tűréshatára pedig egy óra, akkor az architektúra a probléma, nem a mentés. A helyreállítási idő tárhely követelmény, és a specifikációban a helye, nem egy üzemzavarban.

A Drupal tárhely helyes méretezése

Az oldalletöltés rossz mértékegység. Egy havi 200 000 névtelen oldalletöltést kapó webhely egy CDN mögött kényelmesen elfér egy kis példányon, míg egy havi 8 000 oldalletöltésű webhely megszenvedheti, ha ezek nagy része bejelentkezett felhasználótól érkezik.

A bejelentkezett forgalom a valódi mozgatórugó

A névtelen kéréseket az oldal gyorsítótár vagy a CDN a PHP érintése nélkül megválaszolhatja. A bejelentkezett kéréseket nem. Mindegyik végigfut a renderelési láncon, minden entitáson jogosultságot ellenőriz, feloldja a helyőrzőket és munkamenet adatot ír. A gyakorlati kérdés nem az, hány látogatása van, hanem az, hány egyidejűleg bejelentkezett felhasználója, és mit láthatnak ezek a felhasználók.

A szerkesztők a szélsőséges eset. A tartalomkezelő képernyők a Drupal legnehezebb oldalai közé tartoznak, és definíció szerint nem gyorsítótárazhatók, így egy tizenkét szerkesztővel egyszerre dolgozó webhelynek valódi párhuzamossági igénye van, amit a nyilvános forgalma sohasem sejtet.

Nézetek, taxonómia és sorkezelés

A bejelentkezett forgalmon túl a megbízható költséghelyek a sok szűrővel és kapcsolattal dolgozó nagy nézetek, amelyek drága összekapcsolásokat generálnak, a mély taxonómia fák, ahol a kifejezés hierarchiákat minden megjelenítéskor be kell járni, valamint a cron vagy sor jellegű munka, például a keresési indexelés, a hírcsatorna importok és a médiaváltozatok előállítása.

A sorkezelő folyamatok lehetőleg ne osztozzanak a webszerver erőforrásain a látogatókkal. Nagyobb webhelyen külön folyamatba vagy külön példányra valók, hogy egy felhalmozódott import ne lassítsa le a látható felületet. Ez vásárláskor meghozott architekturális döntés, és ez az a pont, ahol a felügyelt szintek már nem illenek, az egyedi infrastruktúra pedig illeni kezd.

A döntés helyes meghozatala

A minta állandó. A tárhely nem alulméretezett, hanem rossz formájú: nincs shell, nincs objektum gyorsítótár, az opcode gyorsítótárat más felügyeli, és a PHP verzió mindjárt kiesik a támogatásból. Ha ugyanazt a webhelyet hasonló áron egy helyesen specifikált példányra költözteti, az általában bármennyi kliensoldali optimalizálást felülmúl.

A Mecanik a webhelyfejlesztési munkánk részeként Drupal infrastruktúrát specifikál, épít és tart karban, a meglévő rendszereket pedig szerver biztonsági audittal nézi át, amikor a kérdés a kitettség, nem a sebesség. Ha inkább emberekre van szüksége, mint platformra, a Drupal fejlesztő felvételéről szóló útmutatónk arról szól, mit érdemes nézni.

Gyakran ismételt kérdések

Mik a Drupal 11 minimális szerverkövetelményei? PHP 8.3 vagy újabb, adatbázisként pedig MariaDB 10.6, MySQL 8.0, PostgreSQL 16 vagy SQLite 3.45. A webszerver oldalán Apache 2.4.7 vagy Nginx 1.1 és újabb, a Microsoft IIS pedig a Drupal 11.0.0 óta nem támogatott. A Drupal 64 MB PHP memória alatt figyelmeztet, éles üzemben viszont 256 MB a reális érték.

Futhat a Drupal megosztott tárhelyen? Telepszik és kiszolgál oldalakat, de a megosztott tárhely rendszerint három vagy négy követelményen bukik el egyszerre: nincs shell hozzáférés a Composerhez vagy a Drushhoz, a PHP memóriakorlátot nem tudja megemelni, nincs Redis vagy Memcached, és a cron csak akkor indul el, ha éppen betölt egy oldalt egy látogató. Ezek a körülmények szülik a Drupal lassúságáról szóló hírnevet.

Mennyibe kerüljön a Drupal tárhely? Egy kis Drupal webhely helyesen beállított, nem felügyelt példányon jellemzően havi GBP 20 és GBP 120 között van, mielőtt bárki üzemeltetné. A felügyelt Drupal platformok általában GBP 40 közelében indulnak, és a forgalommal és a környezetekkel több százig emelkednek. Az egyedi infrastruktúra nagyjából GBP 400 felett kezd értelmet nyerni. A legolcsóbb szint ritkán a legolcsóbb végeredmény.

Szüksége van a Drupalnak Redisre? Kis, névtelen forgalmú webhelyen nincs, ott a belső oldal gyorsítótár és az adatbázis elegendő. Amint bejelentkezett felhasználói, szerkesztői vagy tagi területe van, egy külső objektum gyorsítótár, például a Redis vagy a Memcached leveszi az adatbázisról a gyorsítótár olvasásokat, a zárolásokat és a sorokat, és ez általában a pénzért elérhető legnagyobb javulás.

Biztonságos a CDN egy dinamikus Drupal webhely előtt? Igen, feltéve, hogy gyorsítótár címke szerint érvénytelenít, nem idő szerint. A Drupal olyan címkéket rögzít, mint a node:5, mindenre, amitől egy válasz függ, a modulok pedig ezeket Cache-Tag vagy Surrogate-Key fejléccé fordítják, így a CDN pontosan azokat az oldalakat üríti, amelyeket egy szerkesztés érintett. Címke szerinti érvénytelenítés nélkül elavult oldalak és soha nem segítő gyorsítótár között választ.