ugrás a tartalomhoz

A WordPress lassú az első betöltés alkalmával

Max Logan · 2016. Nov. 10. (Cs), 15.50
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.
 
1

Wordpress

Hidvégi Gábor · 2016. Nov. 11. (P), 10.19
Azt javasolnám, hogy azonnal hagyd abba a Wordpress használatát. Ha valami ilyen válaszidőket produkál alapból, az a háttérben rengeteg műveletet végez, és szükségképpen bonyolult, sok elemből áll. Mindegyik elem el tud romlani (Murphy), plusz jönnek a köztük lévő interakciók, ebből pedig egyenesen következik, hogy előbb-utóbb be fognak törni a rendszeredbe.

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.
2

Online magazin lesz belőle

Max Logan · 2016. Nov. 11. (P), 10.49
Mivel egy online magazin felépítése van napirenden, egy kellően népszerű, (pluginekkel) testreszabható, könnyen alakítható, és könnyen sablonozható (értsd: letöltöm a sablont, esetleg finomítom, és kész) rendszer kell, aminek az adminja is korrekt. A WordPress támogatottsága nagy, mind plugin, mind pedig sablonok terén. (Nekem a Drupal jóval kevésbé szimpatikus, mint a WordPress, nem dolgoznék vele egy ilyen projecten.)

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.
5

Rendben.

Hidvégi Gábor · 2016. Nov. 11. (P), 13.21
Értem, ez így világos. Úgy gondolom, hogy ha valamit el szeretnél készíteni, nagyjából mindegy, milyen utat választasz, a végső ár ugyanannyi lesz, ígyis-úgyis ki kell fizetni, csak másképp.

Janoszen jókat ír, én először a pluginek kikapcsolgatásával kezdeném a méricskélést.
6

Pluginek nélkül

Max Logan · 2016. Nov. 11. (P), 13.30
Kikapcsolat pluginekkel, és stock WordPress sablonnal is ugyanolyan a sebesség, mint egy letöltött sablonnal és 3 db bekapcsolt pluginnel.
7

PHP 7

Hidvégi Gábor · 2016. Nov. 11. (P), 14.00
Van esetleg lehetőség PHP 7-et választani?
8

Van

Max Logan · 2016. Nov. 11. (P), 14.25
Igen, van.

Update: átlőttem PHP 7-re, és a korábbi waiting értékhez képes -40% a várakozási idő.
10

domain

Hidvégi Gábor · 2016. Nov. 13. (V), 11.32
Meg tudnád írni, hol elérhető publikusan az oldal? Szívesen végigfuttatnám rajta a wordpress-törő scriptcsomagomat.
11

Akár

Max Logan · 2016. Nov. 13. (V), 12.54
Szívesen végigfuttatnám rajta a wordpress-törő scriptcsomagomat.
Mármint?
12

Hack

Hidvégi Gábor · 2016. Nov. 13. (V), 13.34
Kíváncsi vagyok, mennyire törhető.
13

Ok

Max Logan · 2016. Nov. 13. (V), 13.59
Pm ment.
3

Wordpress

janoszen · 2016. Nov. 11. (P), 10.54
Alapvetoen a Wordpress lassusagaban tobb dolog is kozrejatszhat. Nezzuk a listat:

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.
4

Szűz telepítés

Max Logan · 2016. Nov. 11. (P), 11.07
Mivel friss telepítésről van szó, 3-4 teszt bejegyzéssel, alap beállításokkal fut a WordPress, tippem szerint az első három pont egyike, vagy mindegyike okozza a jelenséget.

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.
9

Baj

janoszen · 2016. Nov. 11. (P), 18.14
Az a baj, hogy egy tömegszolgáltató elég nehezen tudja megoldani azt, hogy minden ügyfelének folyamatosan fusson legalább egy PHP szál. Egyszerűen nincs elég memória. Az új szálak indítása pedig, különösen egy terhelt rendszeren, eltart egy darabig.

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.
14

mindkettő

Pepita · 2016. Nov. 21. (H), 01.12
Ha nem is ennyire szélsőségesen, de Gábornak is van igaza, a WP egy eléggé erőforrás zabáló cms. Olyan téren én is az egyedi fejlesztés híve vagyok, hogy így tudod elérni, hogy a szoftver pontosan azt és nagyon jó teljesítménnyel tudja, amit a megrendelő kér.
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á.
15

Re

Max Logan · 2016. Nov. 21. (H), 15.15
Nem ismerte a WordPress belső működését, illetve a filozófiát, ami mentén létrehozták, de látva némiképp a logikát, ami alapján működik a sablonozáson keresztül DB elérése, tippem az, hogy cél volt, hogy a háttérben történő működést elég jól elfedjék a user elől. Ezzel elérték, hogy hobbi szintű HTML, CSS és PHP tudással szépen lehet alakítani a WordPress-t a sablonozáson keresztül. Illetve azt is, hogy egymástól független, optimalizálatlan lekérdezések futnak le a renderelés során. (Amin persze egy WP Super Cache elég sokat segít.)

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.
16

super cache

Pepita · 2016. Nov. 21. (H), 19.51
Erre azért kíváncsi lennék, mitől super...
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.
17

A neve super, a működéséről

Max Logan · 2016. Nov. 21. (H), 21.43
A neve super, a működéséről nem tudok nyilatkozni, mármint a motorház alatti részről. A WP belső hívásai lefutnak, rendereli a HTML-t, majd x másodpercre ezt cache-be teszi. Így a következő hívás alkalmával már a korábban létrehozott HTML-t szolgálja ki.

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.
18

A DotRoll support egyik

Max Logan · 2016. Nov. 25. (P), 13.44
A DotRoll support egyik releváns válasza a kérdésben:
A problémát okozhatja az, hogy a tárhelyeinken a gyorsabb kiszolgálás érdekében SSD meghajtókra kerülnek cachelésre azon oldalak amelyeket látogatnak. Ez bizonyos inaktivitás elteltével törli a becachelt tartalmat. Ilyen esetben az első betöltődés nem SSD-ről történik hanem sima lemezről, amelynek lényegesen lassabb a válasz ideje mint az SSD meghajtóknak. Ebből adódhat, hogy az első betöltődési idő jelentősen nagyobb mint az azt követőek.
19

Fura

janoszen · 2016. Nov. 28. (H), 21.22
Ez ket okbol fura. 1. a tanyeros lemez ennyire nem kellene, hogy lassu legyen. Valamit ott lehetne tekerni a caching algoritmuson. 2. rengeteg szolgaltato mar valtott a full SSD megoldasra, ami jelentosen meggyorsitja a kiszolgalast. Ezt is lassan meglephetnek.