Mibe kerül valójában a teljes lib/ betöltése

A szolgáltatás egyetlen belépési fájljának 46. sora:

foreach (glob(__DIR__ . '/lib/*.php') as $f) { require_once $f; }

Ez 65 fájl és 1,5 megabájt, minden kérésnél betöltve. Egy számlálókép, egy statisztikaoldal, egy 404-es hiba — mind ugyanaz. Tegnap ez 20 734 alkalommal történt meg.

A kis szám az, ami számít

Ha az egészet a nulláról töltjük be, kikapcsolt opcode-gyorsítótárral, az körülbelül 132 ezredmásodpercig tart. Ez az a szám, amelytől ez probléma lenne, és nem ezt fizeti a szerver.

Ha az opcode-ok már le vannak fordítva és a megosztott memóriában vannak, csak a könyvtárlistázás marad, valamint fájlonként egy stat() hívás, mert az időbélyeg-ellenőrzés be van kapcsolva: 0,33 ezredmásodperc. A tegnapi forgalom mellett ez az egész napra vetítve kevesebb mint hét másodpercnyi munka.

A kettő között van egy harmadik mérés, 18,2 ezredmásodperc, amelyet úgy vettünk fel, hogy az opcode-gyorsítótár memória helyett lemezről olvasott. Ez felső korlát, nem a valós érték — ez történik, ha van gyorsítótár, de lassabb a valódinál. Azért közöljük, mert ez az egyetlen meleg érték, amely parancssorból mérhető, és ha ennek ellenkezőjét állítanánk, azzal éppen a kézenfekvő hibát követnénk el.

Ez tehát szinte semmibe sem kerül, és ezt teljes egészében valami másnak köszönheti. Ha kikapcsoljuk az opcode-gyorsítótárat, ugyanez a sor négyszázszor többe kerül. Ez valódi függőség, és jobb tudni róla, mint egy frissítés közben rájönni.

Mi van valójában az 1,5 megabájtban

Negyvenhét százaléka — 715 kilobájt 26 fájlban — számlálódizájn-család. Egy számlálókép megrajzolásához pontosan egy kell közülük. A másik 25-öt betölti, deklarálja, és soha nem nyúl hozzájuk.

Ezután: 189 kilobájt zászlóadat, amelyre a földrajzi oldalon van szükség; 158 kilobájt diagramkönyvtár, amelyre akkor, amikor valami diagramot rajzol. Egyik sem vesz részt egy számlálókép kiszolgálásában, pedig a szolgáltatás minden másnál gyakrabban erre a kérésre válaszol.

Ennek látható költsége nem idő, hanem memória. A kérésenkénti csúcsmemória nagyjából négy megabájttal nő, és az opcode-okkal ellentétben — amelyek minden folyamat között megosztottak — ezt a részt kérésenként fizetjük meg, párhuzamosan, minden feldolgozó folyamat egyszerre.

Valaki már észrevette

A glob: lib/*.php. Nem rekurzív, és közvetlenül alatta két könyvtár található: lib/live/ (229 kilobájt) és lib/recht/ (182 kilobájt). Négyszáz kilobájt, amely korábban a betöltési útvonalon volt, most pedig nincs ott.

Azért kerültek át, mert nagyok és ritkán kellenek: a statisztikai szakaszok és a jogi szövegek. Az egész mechanizmus annyi, hogy egy könyvtárral mélyebben vannak. Nincs konfiguráció, nincs lusta betöltő, nincs autoload-térkép — egy fájl vagy benne van a globban, vagy nincs.

Ez valódi javítás, és érdemes ezt kimondani, mert a kézenfekvő következő lépés egy autoloader lenne, egy autoloader pedig itt nagy változtatás volna egy olyan probléma megoldására, amelyet egy mkdir már kétszer megoldott.

Miért marad így

Egyetlen glob a lehető legegyszerűbb megoldás, amely egyáltalán működhet, és a bizonyítékok szerint működik is: egy ezredmásodperc harmada, egy kis szerveren, azon az útvonalon, amelynek gyorsnak kell lennie. Ha fájlonkénti require-ökre cserélnénk, minden új fájlhoz kellene valahol egy sor, és az elfelejtett sor éles környezetben végzetes hibát okoz, nem csupán valamivel nagyobb betöltést.

Amire viszont szüksége van, az az, ami eleve túlélhetővé tette, ezúttal leírva: ha egy fájl a lib/ könyvtárban nagyra nő, alkönyvtárba kerül, és ott töltik be require-rel, ahol használják. Ezt a szabályt követte az a két könyvtár, és mostanáig sehol sem volt leírva.

Az általános tanulság unalmasabb, mint a mérés. A „minden mindent betölt” általában rossz felépítés, és érdemes megmérni, mibe kerül, mielőtt átépítenénk. Itt 0,33 ezredmásodpercbe és négy megabájtba kerül, és a négy megabájtot érdemes figyelni, mert az a párhuzamossággal skálázódik, az ezredmásodpercek viszont nem.