Drupal oldal nagyon lassú betöltődése

Fórumok

Sziasztok,

szeretném a segítségeteket kérni Drupal 7.73 lassulásával kapcsolatban. Feltételezem a serveremen történt frissítés okozhatta (Debian 8.11 – PHP - 5.6.40-29+0~20200514.35+debian8~1.gbpcc49a4).

A hiba jelensége egyszerű a Druapl oldalam betöltése teljesen belassul. Nagyon lassan töltődik be, pontosítva nagyon hosszú a várakozási idő az oldal elérésnél. A server terhelését is nézem htop-al, nem igazán látok sehol se nagy erőforrás igényt a processzor és memória meg se mozdul 0% körül van.

A kérdésem, hogy hogyan lehetne megtudnom, mit kellene megnéznem, hogy mi okozza a hihetetlen lassú oldal betöltést?

Tapasztalat még annyi, ha újra indítom a servert, akkor jelentősebb gyorsulást is tapasztalok, de idővel vissza lassul.

Előre is köszönöm!

Kalmi

Hozzászólások

Drupal alatt/felett nincs valami template engine pluszban? Esetleg egy cache ami megtelik. (Jobb lenne a helyzet ha elsore lassú, később felgyorsul.

Erdemes lenne megnezni hogy a dom felepitese mennyi idő, azaz a szerver lassú vagy csak a html kód bena? (Böngésző fejlesztői eszközök tool).

Ami még eszembe jutott: eddig php-fpm-mel ment most meg apache modul lett belőle esetleg? 

Szerkesztve: 2020. 10. 07., sze - 18:07

Én is ilyesmire gondolok. Most kikapcsolom a chache modulokat, lehet ez nem jó. Az oldal: https://matrixcbs.com/

Szerkesztve: 2020. 10. 08., cs - 14:01

-

a nyitóban 5.6-os php-ról írsz, alább már 7.3-as van a logban. nézd meg, hogy egyáltalán melyik verziót és annak milyen poolját használod az oldaladon. ezt itt tudod megtenni az oldaladon: https://matrixcbs.com/admin/reports/status/php , a szerveren meg az adott virthost configjában. ha ez megvan, akkor tudsz továbblépni.

a ~20 mp-s TTFB eszméletlen sok, és kétszer is "beleáll a földbe" az oldalad: egyszer a drupal betöltésekor, utána pedig (nálam pl.) kétszer is 404-et kap két képre a főoldalon, és azon rugózik. ez valami nagyon alapvető hiba lesz, hiszen ha 10-20 mp kell egy sima kép kiszolgálásához, ott tényleg baj van (1mp-en belül vissza kéne adja bőven, hogy 404, azt csá): https://matrixcbs.com/sites/default/files/images/bg-jm-bottom-container…

emiatt én első körben a webszerver konfigját nézném meg, meg azt, hogy van-e .htaccess fájl (és ha igen, mit tartalmaz, a megfelelőt tartalmazza-e) a sites/default/files könyvtárad. illetve a fájlok kiszolgálását bízd rá a webszerverre egyelőre (nyilvános): https://matrixcbs.com/admin/config/media/file-system

kapcsold ki a memcache-t, opcache-t. nézd meg, nélkülük milyen betöltési időket kapsz. nézd meg, hogy nincsenek-e ezek hibásan beállítva, és nem-e az történik, hogy mindig ellenőrzi az összes fájlt, vagy éppen nincs elég hely a memóriában, hogy betöltse azokat és mindig újraépül. restartold a php-t, töltsd be a főoldalt, majd nézd meg a /admin/reports/status/php oldalon az opcache OOM restarts, Hash keys restarts, Manual restarts számlálóit. 0 legyen mind, ha nem annyi, emelni kell a kapcsolódó értékeken. memcache-nél a statisztikákat is csekkold, hátha magas az evictions vagy más értéke. ha minden rendben lévőnek tűnik, legyenek persze bekapcsolva.

szintén nézd meg ezek után, hogy a drupal cache be van-e kapcsolva a /admin/config/development/performance részen, vagy éppen az aktuális témádnál nincs-e bekapcsolva a "Rebuild Theme Registry on Page Reload". ha igen, az elég necc tud lenni :)

Hát ez valami botrányos sebesség! 18mp az oldal forrása, aztán indul be a buli, de az már nem sok.

1. Statikus tartalom gyors: https://matrixcbs.com/sites/default/files/logo.png, nem az apache-csak van a gond.

2. Rakj fel egy a.php-t (benne egy phpinfo() fgv elég), amin meg lehet nézni, hogy a php lassú-e. (2/a. lehetne egy echo "XXX" is). De biztos hogy nem ezzel lesz a gond.

3. Szerintem valahol van a drupalban beállítva egy memcached vagy valami, aminek a timeoutja 15mp. Ezt szépen kivárja, nem kap választ és akkor elkezdi az oldalt generálni. A 15mp-et kellene megtalálni. Azért 0% a cpu és a disk is, mert nem dolgozik, hanem vár. Ez lehet egy remote logolás is (bár kétlem). Lehet van benne egy curl() hívás, aminek a def. timeoutja 15mp. Ezt kellene a pluginek kikapcsolgatásával megkeresni.

Az hogy mi a lassú (php (kizárt) vagy a drupal), kiderítheted hogy az a.php a lassú-e.

az lehet, hogy: 

a., az uj PHP verzioval egyutt valamelyik modult nem tetted fel amit a drupal (valamely komponense) hasznal

b., kifogtal egy olyan esetet amikor a drupal valami eldugott kis szir-szarja inkompatibilis lett az uj php verzioval 

c., valami remote service timeoutra varunk 

Nálam akkor volt hasonló gond, mikor valami index hiányzott egy MySQL táblából... mindenesetre az SQL logokra is rá lehet nézni.

Nem emlékszem hol melyik, mert olyan 4-5 éve volt.

A tehén egy bonyolult állat, de én megfejtem.

Vagy kinyúl egy olyan erőforrásért, ami nem érhető el, pl. valami csoda plugin. A frissítés pedig lehet véletlen egybeesés vagy a pluginra negatívan hat.

"csoda plugin" - ezen egy 'fejleszto' tarsam annyira megsertodott amikor "csudi pluginjeid"-nek hivtam a plugineket amik valami f*sz CSS-t generaltak es rusnya lett toluk az oldal, hogy kb ramcsapta a laptopot es nem dolgozik mar velem. 

jot mosolyogtam, amikor itt olvastam. #mmd koszi ;) 

Sajnos tényleg kritikán aluli cuccokra értettem :)

A legkedvesebb, amikor a plugin fejlesztője a saját virtuális szerverére csatlakozott ki, amiről elfogyott a kredit, ezért nem ment a plugint, ezért timeoutra futott az egész oldal....minden oldal a világon, ahol ezt a vackot használták. Fincsi :)

Nálam egy superhero-sticky.js fájlban a következő hívást hajtja végre 16 s-ig folyamatosan, nagyon sokszor:

setInterval(function(){
    $stickywrapper.height($this.outerHeight());
},10);

Esetleg ha ezt kikommenteled, akkor nem lesz gyorsabb?

Vagy az egész fájlt kiszedni próbaképpen.

Dell Latitude 5480, Arch Linux & Xfce

Szerkesztve: 2020. 10. 18., v - 19:17

Köszönöm a sok segítséget. Az oldal cseréjén és a szerver újra telepítésén kezdtem erősen elgondolkodni... Régen jó volt, de úgy nézz ki, hogy a nagyon sok sz*r, valamiért már megfogja....

Végig kell debugolni, hogy mi hol lassul le. Kliens oldalról a gtmetrix.com -on szoktam megnézni, hogy onnan mi látszik, sokszor van külső kérés (pl. facebook vagy valami beépülő csoda), ami látványosan megfogja. Aztán a PHP oldalon megnézném, hogy egy phpinfo() csak bevillan-e, vagy ott is van már valamilyen timeout/várakozás. A PHP és Apache error logjait ekkor érdemes faggatni.

A szerver oldalon kötelező az Opcache és a Drupal oldalon is illik bekapcsolni legalább a publikus cache-elést és a JS+CSS aggregációt. A PHP-nál, ha fpm, tudod naplózni, hogy mi volt ami adott mp-nél lassabb, mint a MySQL slow log. Ami még előfordul, hogy a session tábla megtelik, mert debianon alapból ki van kapcsolva a beépített garbage collector és a Drupal saját session kezelést (saját függvényt, ami adatbázisba ment) használ. A komment és regisztráció spam szintén zenész lehet, nem egyszer daráltam sokszor 100k rekordot ilyenekből.