A WordPress lassú az első betöltés alkalmával
Adott a WordPress és adott a DotRoll tárhelyszolgáltató (annak is a Mini csomagja). Feltelepítek egy WordPress rendszert és tesztelem.
A főoldal betöltése első alkalommal akár 7 másodperces várakozást is mutat, azaz szerver oldalon tököl valamivel a rendszer. Ha frissítem az oldalt, már csak kb. 1 mp a várakozás. Ha belövöm a WP Super Cache-t, már csak 200-400 ms a várakozás.
Eltelik mondjuk egy óra, nincsen látogatás az oldalon, ekkor első alkalommal újra 5+ másodpercet tököl, mire a szerver rendereli, majd visszaküldi a böngészőnek a kimenetet.
Kérdés: a WordPress ilyen, a DotRoll környezete miatt viselkedik így a WordPress, vagy egyszerűen annyian használják a szerver erőforrásait (shared-hosting ugye), hogy amit nem pörgetnek a látogatók, azt kivágja a szerver memóriájából és később az első betöltés lassú lesz?
Teszem hozzá, hogy a WordPress admin folyamatosan 1+ másodperces várakozással szolgálja ki az oldalakat, ha lépkedek az adminban.
Próbáltam kikapcsolt pluginekkel, és például a 2015-ös default WordPress sablonnal, úgy is ugyanolyan lassú, tehát nem külső modul felelős a jelenségért.
Megjegyzés: várakozás alatt a Firefox beépített dev tooljában a sending és receiving idő közé ékelt waiting értéket értem.
■ A főoldal betöltése első alkalommal akár 7 másodperces várakozást is mutat, azaz szerver oldalon tököl valamivel a rendszer. Ha frissítem az oldalt, már csak kb. 1 mp a várakozás. Ha belövöm a WP Super Cache-t, már csak 200-400 ms a várakozás.
Eltelik mondjuk egy óra, nincsen látogatás az oldalon, ekkor első alkalommal újra 5+ másodpercet tököl, mire a szerver rendereli, majd visszaküldi a böngészőnek a kimenetet.
Kérdés: a WordPress ilyen, a DotRoll környezete miatt viselkedik így a WordPress, vagy egyszerűen annyian használják a szerver erőforrásait (shared-hosting ugye), hogy amit nem pörgetnek a látogatók, azt kivágja a szerver memóriájából és később az első betöltés lassú lesz?
Teszem hozzá, hogy a WordPress admin folyamatosan 1+ másodperces várakozással szolgálja ki az oldalakat, ha lépkedek az adminban.
Próbáltam kikapcsolt pluginekkel, és például a 2015-ös default WordPress sablonnal, úgy is ugyanolyan lassú, tehát nem külső modul felelős a jelenségért.
Megjegyzés: várakozás alatt a Firefox beépített dev tooljában a sending és receiving idő közé ékelt waiting értéket értem.
Wordpress
Azt a feladatot, amit a Wordpress elvégez (egyszerű információk megjelenítése) egy saját scripttel egy átlag szerveren nagyjából pártíz ezredmásodperc alatt ki lehet szolgálni.
Online magazin lesz belőle
Nem gondolnám, hogy alapból a WordPress a lassúság oka, mert példálul az imagazin.hu is WordPress alapon működik, és kellően gyors. Illetve local-ban (XAMPP) egy 8-9 éves PC-n a publikus felület olyan válaszidőkkel működik, mint a DotRoll szerverén WP Super Cache mellett, és az admin is jóval gyorsabb.
Leginkább arra lennék kíváncsi, hogy:
- a DotRoll-os cPaneles szerverkönyezetben van valami elcsavarva, ami miatt ilyen lassú (a cl02-es és a cl09-es szerveren is ugyanez a jelenség tapasztalható; én az előbbin, egy korábbi melóhely az utóbbin van)
- shared-hosting esetében a WordPress szükségszerűen ilyen lassú
- vagy…
10 év után végleg, és visszavonhatatlanul kiszálltam a programozósdiból, illetve az informatikát nagyobb léptékben is magam mögött hagytam. Az tehát szóba sem jöhet, hogy egy online magazin mögött kézzel vezérelt scriptek legyenek, egyedi fejlesztéssel.Rendben.
Janoszen jókat ír, én először a pluginek kikapcsolgatásával kezdeném a méricskélést.
Pluginek nélkül
PHP 7
Van
Update: átlőttem PHP 7-re, és a korábbi waiting értékhez képes -40% a várakozási idő.
domain
Akár
Hack
Ok
Wordpress
1. Shared hosting kornyezetben futsz, es ha nincs forgalom, a hosting kornyezet lezarja a szamodra nyitott PHP folyamatokat. Ha aztan jon egy uj request, idobe telik a Te usered alatti PHP ujrainditasa.
2. Opcache. Ha nincs hasznalva az oldalad, akkor kipotyog az opcache-bol a kodod es a PHP kodot ujra kell forgatni.
3. Lassu tarhely. A fentiekben siman kozrejatszhat, hogy egyszeruen nem eleg gyors a tarhely. Ez lehet disk, CPU, RAM, barmi.
4. Maga a Wordpress a lassu. Ha sok tartalmad van benne, erdemes megnezni a DB-t, mert a default WP telepites nem tesz mindenhova indexeket ahova kellene.
5. Valamelyik plugin a lassu. Eleg sok szemethalmaz WP plugin van, es ha sok plugin van, amugy is van egy sebesseg problemad.
Megoldaskent persze agyon lehet verni az egeszet valamilyen statikus cachelesi modszerrel, pl WP Total Cache, de a jobb az lenne, ha kideritened, hogy a fentiek kozul pontosan melyik a ludas.
Szűz telepítés
DotRoll Mini csomagról van szó, a honlapjukon írtak alapján van teljesítménybeli különbség az egyes csomagok között. Azt nem tudom megállapítani, hogy például a DotRoll Mini csomag által biztosított teljesítmény hol áll más szolgáltatókhoz képest.
Baj
Hozzáteszem, jó 5 éve nem dolgozok a DotRollnál és nem tudom, hogyan működik az új hosting architektúrájuk. Általánosságban attól tartok, hogy ha gyors oldalt szeretnél, kénytelen leszel olyan szolgáltatót/szolgáltatást választani, ami valamilyen szinten dedikált erőforrást biztosít. Csak így garantálható, hogy nem lesznek ilyen jellegű hideg cache / hiányzó PHP feldolgozó problémáid.
mindkettő
Természetes, hogy egy "mindenre jó" cms sokkal több kanyarral oldja meg ugyanazt.
Viszont ha Janoszen nek igaza van, és úgy jön be request, hogy nincs is futó PHP -d, akkor lehetsz akármilyen backend guru, nem fogsz tudni elfogadható időn belül response -t adni.
A Mini csomagjukat nem ismerem, Plusz csomagban, saját fejlesztéssel soha nem volt ilyen gondom náluk.
Mini csomaghoz írnak vmi RAM / CPU adatot? Vagy csak szimplán amennyi éppen jut?
Szerintem a Plusz is nagyon olcsó, én nem mennék az alá.
Re
Ami a futó / nem futó PHP kérdését illeti, árnyalódott a kép. Adott egy sima PHP script ami annyit csinál, hogy meghívja a phpinfo()-t. Ez a WordPress használatát követően 80 perccel minden gond nélkül szépen lefut, 300-400 millisec várakozással. Ekkor rábökök a WordPress címlapjára, ami 7-8 sec várakozással fut le első alkalommal.
Ez alapján tehát a PHP fut. A WordPress-nél két dolog van, ami a kis scriptnél nincsen: Apache rewrite, illetve DB elérés.
A Mini csomag erőforrásaiban fele annyit ad, mint a Plus. Korábban Plusom volt, de mivel nem használtam ki, visszaléptem Minire, és most itt teszteltem a rendszert, ami vagy a DotRoll-nál fut majd, vagy nem. Ezt még nem lehet tudni.
super cache
Nem tudnak normális query t írni, ezért statikusan, akár plusz memóriát foglalva bent tartja az eredményt? ... Nem egy jó út.
Egy php info t kiírni kimenetre ha többe kerül, mint 30-40 ms, akkor ott vmi nem kerek.
Szerintem 300 alatt meg már betölt php.
Db eléréshez pedig már fel is kell építeni egy connection, úgyhogy azzal együtt is kéne mérni.
Apache rewrite - ha nem egy egész regény - nem igazán észrevehető időben.
Tehát sanszos, hogy maradt a db connection.
Ha a Mini hez van dedikált erőforrás , akkor elvileg nem állhat le az interpreter, csak akkor lehet lassulás, ha egyszerre túl sok futó request van (egynek már várni kell arra, hogy egy másik végezzen).
Tehát ezek alapján amit írtál, minden rendben van, de mégse jól műxik...
Ez ugye nem stimmel.
Annyi még esetleg, hogy a szerveren történő futás időket mindig ott érdemes mérni. Az a biztos. Böngésző csak tippelni tud, simán lehet network gond is, amit browser nem (jol) lát.
A neve super, a működéséről
Nincsen lehetőségem arra, hogy más tárhelyszolgáltatókkal, esetleg más csomagokkal teszteljem a WP-t, így csak arról tudunk nyilatkozni, amit a DotRoll Mini csomaggal tapasztalok. Viszont valószínűleg architekturális dolog van a háttérben, mert másik Mini csomag, másik szerverükön is produkálja az első WP hívásnál a hosszú várakozást. (Erre utaltam a 2-es kommentben.)
Nincsen értelme a szerveren mérni, mert 10 MBit-es ADSL, és 4G-s mobilnet esetén is tapasztalható a jelenség, és mivel 5+ másodperces várakozásról beszélünk, emberi érzékeléssel is látványos a dolog.
Workaround lehet, ha mondjuk 30 percenként egy cron script cURL segítségével lekéri a WP admin belépő pontját, így életben tartja a nem tudjuk mit. Mert nem csak a frontend esetén van ez a várakozós jelenség, hanem az adminnál is.
Írok a support-nak mailt, hátha mondanak valami okosat.
A DotRoll support egyik
Fura