Valójában mekkora VPS kell a WordPresshez?

Kevesebbet, mint amit hallott, ha a webhely gyorsítótárazott. A gyorsítótárazott oldal egy fájl, amelyet a webszerver közvetlenül a lemezről küld (a PHP nem indul el, és az adatbázishoz sem nyúl), így egy olyan webhelyen, ahol a látogatók többsége gyorsítótárazott oldalakat lát, a RAM azt határozza meg, hány NEM gyorsítótárazott kérés futhat egyszerre, nem azt, hány látogatója lehet. Ezért visz el egy 1 GB-os gép egy valódi blogot: miután az operációs rendszer és az adatbázis elveszi a maga nagyjából 700 MB-ját, a maradék még mindig elfuttat néhány PHP workert, és néhány elég, ha tíz kérésből kilenc soha nem jut el a PHP-ig. Ahol a RAM valóban eldönti a kérdést, az egy webshop vagy egy tagsági oldal, mert a kosarak, a fizetési folyamatok és a bejelentkezett munkamenetek nem gyorsítótárazhatók, és mindegyikük élő PHP-kérés.

Az őszinte válasz az, hogy kívülről senki nem tudja megmondani, mert attól függ, hány kérése gyorsítótárazott, és mennyi ideig tart egy nem gyorsítótárazott. Amit adni tudunk, az a számítás: workerek = (RAM − 300 MB az operációs rendszernek − 400 MB az adatbázisnak) ÷ egy PHP worker memóriaigénye, és egy 200 ms-os worker másodpercenként öt kérést szolgál ki. Szorozzon, és legyen pesszimista. Aztán tesztelje: helyezzen üzembe egy gépet óránkénti díjazással, futtasson terheléstesztet a saját webhelyén a saját bővítményeivel, majd utána törölje a gépet. Ez néhány centbe kerül, és jobb minden becslésnél ezen az oldalon, a miénket is beleértve.

A sávszélesség, gyakrabban, mint gondolnák, és ezt a számot szinte egyetlen szolgáltató sem írja a csomag mellé. Egy tipikus WordPress-oldal körülbelül 2,5 MB, így százezer oldalmegtekintés nagyjából 244 GB, ami kényelmes. Egymillió körülbelül 2.4 TB, ami több, mint több olyan csomag kerete, amelyben még bőven van memória. Pontosan ezért mutat ez az oldal keretoszlopot: a(z) BD-8 32 TB-ot, a(z) C4-8-150 4 TB-ot tartalmaz, és egy médiában gazdag oldalnál ez a különbség többet számít, mint a magok.

Csak ha inkább nem végezné maga a frissítéseket. A VPS root hozzáférést ad és semmi mást: Ön telepíti a WordPresst, Ön frissíti, Ön készíti a mentéseket, és Ön felel, amikor egy bővítmény hajnali 2-kor tönkreteszi a webhelyet. Ez olcsóbb és rugalmasabb, és valóban több munka. Ha ezt a munkát nem szeretné, menedzselt szintjeink erre valók, és szívesebben irányítjuk oda, mint hogy olyan gépet adjunk el, amelyet nem fog karbantartani. A nem frissített WordPress a legmegbízhatóbban feltört dolog az interneten.

Egy webhelynél igen, szinte mindig. Szétválasztásuk minden lekérdezéshez egy hálózati ugrást, és egy második karbantartandó gépet ad, cserébe olyan tartalékért, amelyre valószínűleg még nincs szüksége. Akkor válassza szét őket, ha valóban az adatbázis a szűk keresztmetszet, és ezt meg is mérte, vagy ha több olyan nagy terhelésű webhelyet futtat, hogy az adatbázist elkülönítené. Ha szétválasztja, menedzselt adatbázis termékvonalunk üzemelteti Ön helyett a PostgreSQL-t és a MySQL-t, ami másfajta kompromisszum: több pénz, kevesebb elvesztegetett este.

Az, amelyik az olvasóihoz van a legközelebb, nem Önhöz. A távolság az egyik tényező, amely meghatározza, mennyi idő alatt kezd megérkezni egy oldal, és egy Európában olvasott webhelynek jobb Európában, még ha Ön nem is ott van. Ha az olvasói szétszórtan vannak, tegye a szervert a legnagyobb csoport közelébe, és tegyen CDN-t a statikus fájlok elé: ebben igazán jó egy CDN. Több régióban értékesítünk, és minden csomag oldala felsorolja azokat, ahol ténylegesen kiépíthető.

Igen, és ez egy fájlmásolás és egy adatbázis-mentés, nem külön termék. Bármelyik szokásos migrációs bővítmény elvégzi, vagy kézzel is áthelyezheti rsync és mysqldump segítségével, ha inkább érteni szeretné, mi történt. Helyezze üzembe az új gépet óránkénti díjazással, amíg a másolatot teszteli, irányítsa rá a domaint, ha elégedett, és törölje a régit. Az átfedés centekbe kerül, és azt jelenti, hogy a visszaállítás annyi, hogy „visszaállítja a DNS-t”.