Windows + Apache + MySQL + PHP + Drupal 7 sebesség javítása

Drupal 7 too slow (túl lassú) - Javítsunk rajta

Az alap szituáció: A Drupal 7-re épült Windows 7-es fejlesztői gép 10 sec-es válaszidőket produkál, tehát kibírhatatlanul lassú.

A konfiguráció:

Hardver: Intel I5 3,1 GHz, 16 GB RAM, Gyors HDD, SSD az operációs rendszer meghajtóján.
Windows 7 64 bit
Apache 2.4.10 (win32)
MySQL 5.7.16 (Win64)
PHP 5.6.21
Drupal 7

Az interneten rengeteg válasz van arra a kérdésre, hogy "Drupal 7 too slow". Először ezen próbáltam javítani az alábbi módokon

Drupal 7 gyorsítása

Bekapcsoltam a Drupal 7 cache rendszerét:Administer » Configuration » Development » Performance.
Kikapcsoltam sok olyan modult, amit nem használtam.
Kikapcsoltam a Statistics modult, mert fejlesztői oldalként csak én nézem az oldalt.
Kikapcsoltam az Update Manager modult, mert nem kell minden híváskor megnézni, hogy van-e frissítés
Entity Cache modult telepítettem.
Display cache: A view módot gyorsítja - ha be lenne kapcsolva a View modul
Ha van View, akkor kapcsoljuk be a Views Content cache modult
Nem használom a Views modult, ezért kikapcsoltam.
Aggregate cache - összeszerkeszti a CSS és JS fájlokat egybe, ezáltal kevesebb kérés megy a szerverhez. A szerver oldalon kiküszöböli a file_exists() PHP kéréseket, amelyek az operációs rendszertől sok időt vesznek el.
Ha használjuk a Panel modult, akkor telepítsük és kapcsoljuk be a Panels Content Cache modult.
File cache modul az adatbázis helyett a cache tartalmát fájlrendszerbe menti a szerveren, ami kiiktatja az adatbáziskéréseket, de egy kis PHP futtatást eredményez. Ha használunk memcache vagy más optimizáló programot a szerveren a PHP-hoz, akkor a memóriában lévő fájlrendszerben is lehet tárolni a fájlokat.
Alternative Database Cache - lecseréli a Drupal saját cache modulját. A file cache modullal együtt nem illik használni - ezt nem is használom
Advanced CSS/JS aggregation modul a CSS és JS fájlokat letömöríti. A fejlesztő gépen nem biztos, hogy szabad ezt használni, mert a JS fájlok eredeti állapotának megőrzése fontos.
A page-not-found hibák esetén a Fast 404 modul gyorsítja. Itt én belefutottam egy problémába, amikor egy általam fejlesztett modul összeakadt ezzel a modullal.
HTTPRL modul a szerverhez irányuló kéréseket gyorsítja.
Image Lazyloader - a képek betöltését gyorsítja
A letörölt vagy nem létező modulok kezelésére a Missing Module segítségével gyorsítottam a futást
A PHP filter modult kikapcsoltam. Ez jelentősen lassítja a futtatást, ugyanis minden filter modul kódja lefut még akkor is, ha nincsen megfelelő filter az oldalon. Ha PHP kódot akarunk használni, akkor inkább írjunk egy megfelelő modult.

Sajnos a fenti praktikák nem sok változást hoztak a fejlesztői gépen.

PHP választás és gyorsítás

Feltettem a e legújabb PHP 5.x.x verziót, illetve a PHP 7.1.x verziót is. Az újabb verziók gyorsabbak.
Beállítottam a PHP 5.6.x-től hivatalos Opcode cache programot. ez a PHP 7-nél már a PHP része. A cache modulnak legyen annyi memóriája, amibe befér a futtatott kód (pl. 128 MB). Az opcode cache programok a PHP alkalmazások kódját lefordítják és memóriában tárolják. Ezzel a futtatáskor a PHP fájlok betöltését és a szintaktika ellenőrzését is megspóroljuk.
Kikapcsoltam az xdebug modult, illetve a böngészőből bekapcsolhatóvá tettem minden részét. Három funkció van: debug - hibakeresés, trace - lépésenkénti végrehajtás, profiler - sebességmérés. A profile funkció a megadott területen létrehoz egy futtatási statisztikai fájt, amit a WinCacherind programmal olvashatunk és elemezhetünk. Ettől a lépéstől az addigi 6-8 sec válaszidők leestek 3-4 sec-re

Webszerver választás

Használjunk NGINX szervert Apache helyett. Legalább 20 évvel fiatalabb koncepció. Ha Apache-ot használok mégis (mert azt ismerem és rengeteg ember használja), akkor optimalizáljuk azt is.
Lehetőség szerint minden felesleges modult kapcsoljunk ki.
Az Apache is csak IPv4-en szolgáltasson

Apache teljesítményének javítása

Bekapcsoltam az Apache mod_expires modulját és a .htaccess megfelelő konfigurálásával gyorsítottam a css, js és egyéb fájlok böngészőoldali cache-elését.
A kimenő tartalom tömörítésével szerver oldalon az Apache mod_deflate használatával. gyorsítottam. Azt persze tudni kell, hogy ha az apache tömöríti a kimenetet, akkor a válaszul kapott HTML kód nem feltétlenül lesz ugyanaz, mint amit a fejlesztő eszközzel létrehozunk!
A Drupal 7 InnoDB adattáblákat használ, ami írásnál biztonságos, mivel tranzakciós. Sajnos az írásnál és az adatok lekérdezésénél lassabb, mint a MyIsam típusú táblák, ezért a cache és a variable nevű táblákat átállítottam MyIsam táblákra, amelyek nem tranzakciósak, de azért elég biztonságos.
Elvileg az adatbáziskezelőt módosíthatnám NoSQL típusúra, mint éldául a MongoDB. Ennek használatához szükséges a Mongo DB Drupal modul, amely a cache tartalmát teszi MongoDB adatbázisba. A MongoDB az adatbázist memóriában tartja, ezzel gyorsítja a kiszolgálást. Nem ajánlatos együtt használni a File cache vagy az Alternative Database Cache modullal. Fejlesztői gépen csak bonyolítja a dolgokat, ezért nem is használtam.

Tűzfal kiiktatása + víruskereső

A Windowsokon muszály tűzfalat és víruskeresőt futtatni, de mind a két szoftver lassítja a kiszolgáló rész működését.
A tűzfal szabály hatálya alól kivettem az apache-ot és a víruskeresés hatálya alól kivettem az apache könyvtárát, a PHP könyvtárát és a website könyvtárát is.

Operációs rendszer gyorsítása

A Windowsokon az IPV6 be van állítva, de nemigen használjuk, mert a magyar hálózatokon nincsenek IPv6 eszközök. Kikapcsoltam az IPv6-ot, amit itt lehet elolvasni, hogyan kell. Igaz a leírás windows 8-ra vonatkozik, de Windows 7- Windows 10 között ugyanígy kell beállítani.
Apache-ot is beállítottam, hogy csak IPv4-en fogadjon kéréseket: Listen 0.0.0.0:80

Ez valamicskét változtatott a helyzeten

Mint említettem az operációs rendszer SSD meghajtóra van telepítve. Az SSD gyakorlatilag egy lassabb memória. Az ott tárolt fájlok olvasássa sokkal gyorsabb, mint HDD-ről. Az Apache + PHP dolgokat oda telepítettem.
Létrehoztam a memóriában egy RAMDISK-et és a webszerver rendszer minden elemének log fájljait oda írom. A RAMDISK sebessége a memória sebességével egyenlő. Az oda való írás tehát 1000x gyorsabb, mint a HDD-re. Az Apache + PHP + MySQL log fájljait ide írom. Korábban a rendszer TEMP változója is ide került, de az induláskor bizonyos okokból nem működött tökéletesen, ezért ezt áttettem egy HDD-re.
A localhost probléma Windowson! A localhost-ot a windows nehezen dolgozza fel, ezért az alábbiakat érdemes tenni:
- Mindenhol a localhost helyett 127.0.0.1-et kell írni (Apache config, MySQL config, PHP config, Drupal config)
- A Windows rendszerkönyvtárban az alábbi helyen: \Windows\System32\driver\etc\hosts a megfelelő helyre beírni az alábbi bejegyzést: 127.0.0.1 localhost
- Mivel az IPv6-ot kikapcsoltuk, ezért a localhost IPv6 bejegyzését át kell írni.
- Ha használunk virtuális szervereket, akkor azokat is át kell írni a fentieknek megfelelően.

Eredmény és összefoglalás

A korábbi 10 sec körüli válaszidők 1,5 - 3 sec körülire csökkentek. Ez már elég jó eredmény, különösen, ha figyelembe vesszk, hogy a fejlesztői géphez képest az éles rendszer (amely Linuxon fut) szintén ilyen válaszidőket produkál.

Külső szolgáltatások használata - fejlesztői gépen nem illik használni

CDN - a tartalom egy felhőben található
Pantheon - ajánlott felület, ahol teljes Drupal stack található

Az oldal sebességét tesztelő eszközök

Performance Logging and Monitoring modul
A Performance and Scalability Checklist modul segítségével a rendszer optimalizálását ellenőrizhetjük
A Devel modul segítségével elemezhetjük a lassú lekérdezéseket
Akár a Zend Studio profiler, akár az XHProf PHP Profiler vagy az XDebug profilere WinCacheGrind segítségével használható az oldal lefutásának elemzésére
YSlow használata a Firefoxban és/vagy Chromeban. Javaslatokat fogalmaz meg az oldal sebességének javítására és teszteli az oldal sebességét.

Az oldal stressztesztje

A Webstress Tool freeware program segítségével a rendszerünket tesztelhetjük, akár a fejlesztői gépen, akár külső szerveren. Figyelem! A tűzfal programok használatakor elárasztásos támadást érzékelhetnek! Segítségével szimulálhatunk egy időben több száz felhasználót, akik össze-vissza kattintgatnak az oldalunkon. Menet közben a memórafelhasználást lehet ellenőrizni, illetve a válaszidőket lehet nézni.

A weboldal kódjának javítása

A jpg, png képek méretének csökkentése akkorára, hogy a böngészőnek ne kelljen átméretezni
Kevesebb külső js kódot - meghívni, pl Google Analytics kódot a szerverre telepíteni
Kevesebb iframe-et használni
A javascript kódokat az oldal végére téve a felhasználó számára megjelenik az oldal a böngészőben, amikor a js kódok még csak töltődnek.
A css fájlok pedig a HTML oldal elején legyenek