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

Linux-kezdő

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

  • 657 megtekintés

( dotnetlinux | 2020. 10. 07., sze – 17:44 )

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? 

( kalmarr | 2020. 10. 07., sze – 18:01 )

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/

( kalmarr | 2020. 10. 07., sze – 18:46 )

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

-

( Pene | 2020. 10. 07., sze – 20:31 )

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 :)

( dotnetlinux | 2020. 10. 07., sze – 20:31 )

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 

( agostonl | 2020. 10. 09., p – 05:45 )

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.

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

( Proci85 v | 2020. 10. 09., p – 10:27 )

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 :)

( CzLaci | 2020. 10. 09., p – 12:34 )

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 Optiplex 3060 Micro, Arch Linux & Sway

( kalmarr | 2020. 10. 18., v – 19:17 )

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.