ugrás a tartalomhoz

Include hasznosság

engineer · 2010. Már. 11. (Cs), 17.44
Üdv.

Az include függvény hasznosságát, praktikusságát kérdőjelezném meg.

Olyan PHP és MYSQL alapú weboldalt fejlesztek, aminek a működése nagyon összetett.
A kód átláthatósága, könnyebb módosítása és az egész rendszer fejlesztése/továbbfejlesztése érdekében az egyes különálló kódrészletek külön fájlban vannak elmentve, és szükség esetén include függvénnyel vannak meghívva.

Mivel már most vagy 100 php fájlom van, felmerült bennem a kérdés, hogy nem lassítja-e ez a szerver működését, illetve a honlapom használatát.

Az egyik CSS-el foglalkozó cikkben szó volt arról miért hasznos ha a háttérkép inkább egy nagyobb fájlban van, mint ha több kicsiben.
Ugyanez nem érvényes a php fájlokra is?

Ha a program bizonyos részei csak feltétel teljesülése esetén futnak le, az azt jelenti hogy a szerver a kérdéses teljes részt átugorja, vagy akkor is végig kell néznie az egészet hogy rájöjjön hol a vége?
Ha ez mondjuk plusz 300 sort jelent a kódban, én már inkább külön fájlba szoktam tenni, így a feltételen belül csak egy include sor van, és azt gondolom ezt könnyebben átugorja mint ha a teljes kód ott lenne.

Jól gondolom vagy rosszul gondolom?
Vannak érvek és ellenérvek, vagy egyértelmű melyik módszer a jobb?

Én a magam részéről szívesebben maradok az include-os megoldásnál, mert sokkal könnyebb így dolgoznom, és lehet hogy később mások is besegítenek, nekik meg egyértelműen könnyebb dolguk lesz.

Remélem a kérdés egyértelmű, ha mégsem akkor szívesen kifejtem részletesebben, ill. mutatok példát is.

Előre is kösz.
 
1

que?

Emul · 2010. Már. 11. (Cs), 19.47
Eloszor is megjegyeznem hogy az include nem fuggveny. A PHP hulyesege hogy hasznalhatod akkent is.

Masodjara meg kodolas es atlathatosagh szempontjabol mindenkeppen hasznos.
Egy nagy project tobb ezer filebol all. Kepzeld el ezt mind egy fileban, atlathatalan lenne, raadasul nincs az a fejleszto kornyezet ami elbirna.

Eles kornyezetben nehany esetben hasznalhato az hogy az ugymond egyseget kepezo osztalyokat tartalmazo php fileokat egybe masolod, es csak egy include tortenik az adott egyseg hasznalatakor.
De hogy oszinte legyek, nagyon ritka hogy a Portalod lenne a szuk keresztmettszet ergo nem sokat nyersz vele.
2

Memória használat

Poetro · 2010. Már. 11. (Cs), 20.25
Képzeld el, hogy a 100 include fájlod ha be lenne töltve egyszerre memóriába, mondjuk 100Mb-ot foglalna. Mondjuk a szerveredben van 1Gb memória. Azaz ebben az esetben egyszerre csak 10 felhasználót tudnál kiszolgálni. Ugyanakkor ha egy oldalhoz csak mondjuk 20 fájlt kell betöltened a 100-ból, akkor máris spóroltál több Mb memóriát.
3

azért ne túlozunk

solkprog · 2010. Már. 11. (Cs), 21.48
azért a 100MB kicsit túlzás nem? Például az egész drupal csak kb 3.5 MB. (és ugye egy oldalbetöltésnél nincs betöltve az egész.)

De erről inkább egy rendszergazdát kéne megkérdezni hogy mit tart optimálisnak hogy a memóriát terheljük plus néhány MB-tal vagy a winchestert kínozzuk 20 soros fájlok olvasásával? Valaki illetékes: melyik szokott inkább a szűk keresztmetszet lenni memória vagy a wichester?
5

Sarkított példa volt

Poetro · 2010. Már. 12. (P), 00.14
A fenti egy sarkított példa volt, de azért 30-40Mb elő tud fordulni, ha rengeteg modul van betöltve.
9

Mint rendszergazda

janoszen · 2010. Már. 13. (Szo), 00.49
Tegnap írtam erre a mobilomról egy hosszú választ, de jól elveszett az éterben. Szóval. Mint rendszergazda azt mondom, hogy a memóriafogyasztás könnyebben orvosolható, mint a disk IO. Ez utóbbit ugyanis elég nehéz bővíteni. Persze nagyban függ attól, hogy egyedül laksz-e a szerveren vagy többed magaddal, de már 8 fájl esetén gyorsabb egy fájlba összemásolva parzolni mint külön-külön. És ha gyorsabban lefut a lekérdezés, hamarabb takarodik ki a memóriából a program, ami nem utolsó szempont. Tehát ha mérsz, ne csak azt nézd, mennyit foglal, hanem azt is, hogy mennyi ideig.

Természetesen nem lehet gátlás nélkül memóriát zabálni, erre nincs mentség, de a PHP-s tömbök pl sokkal több memóriát zabálnak az össze-vissza indexelés miatt, mint amennyi adat van bennük, tehát lehet, hogy ott kell optimalizálni.

Ökölszabályként azt mondanám, hogy az alkalmazás telepítésekor a core fájlokat másoljátok össze egyben, a többit hagyjátok külön. És kérjétek meg a rendszergazdát, hogy kapcsoljon be valamilyen opcode cachet.
4

Néhány észrevétel

erenon · 2010. Már. 11. (Cs), 22.21
CSS fájlok egyberakása vs. PHP fájlok:
A CSS/JS/kép fájlokat azért szokás egybe rakni, hogy csak egy kérés induljon a szerver felé. A PHP fájlok include-ja egy HTTP kérés alatt történik.

Ezzel szemben minden beolvasott fájlt le kell fordítani minden használat előtt; ha minden egyben lenne, sokkal több időt venne igénybe. Ezen segíthetsz opcode cache-el.

A winchester elérése "lassú" lehet, ezen lehet segíteni tmpfs-el, vagy hasonló technikákkal.

Vakon követés: Nézz meg egy nagyobb frameworkot. A Zend nem átall egy "class Zend_Exception extends Exception {}" teljesen üres osztályt új fájlba rakni. Reméljük, hogy ők gondolkoztak : )

Konklúzió:
Sokkal fontosabb, hogy karban tudd tartani a projectedet, és szükség esetén a megfelelő részeket újra fel tudd használni. Az így megspórolt munkaórák árát fektetheted vasba.
Az include/require hívása valószínűleg nem szűk keresztmetszet. Először profileold az alkalmazásodat, és a problémás részeken javíts. (adatbázis hívások, regex, stb).
Még ha szűk keresztmetszet is lenne, inkább használj cachet, minthogy egybeömlesztenéd a kódodat, megsemmisítve ezzel egy jó tulajdonságát: a tagoltságot.
6

Ne úgy fejlessz, hogy mindent

Protezis · 2010. Már. 12. (P), 08.56
Ne úgy fejlessz, hogy mindent egybe raksz. Max a végén fésülj össze bizonyos fájlokat, de ennek az értelme is kérdéses. A Doctrine-ban van erre megoldás, opcode cache (APC) mellett semmi javulást nem tapasztaltam.
7

Ha tényleg érdekel

deejayy · 2010. Már. 12. (P), 09.32
Ha tényleg érdekel, akkor használj valamilyen php debugger / tracer / profiler stuffot, az megmondja, hogy milyen utasítással mennyi időt tölt a php-d. Nekem az egyik verzió pl. az idő 50%-át töltötte a define utasítás futtatásával (nyelvi fájlok), remélem azóta ezt javították, de akkoriban ennek alapján átszerveztem a kódot.

Az APC tényleg jó (saját blogomon 30%-ra csökkent a render idő). Sőt, memcached-t és nosql adatbáziskezelőt is használhatsz még a rendszer gyorsítására. Csinálhatsz "build"-eket vagy snapshotokat (amiről @Protezis is beszél), nyilván tesztelni kell, hogy megéri-e a befektetett munkát. Itt van még a HiPHop is, a facebook legújabb találmánya, szóval lehet válogatni.

Hopp, kicsit átcsaptam php-optimalizációba :) De akinek van kedve, még lehet tippeket adni, szenvedélyem az optimalizálás ;]
8

Netbeans + xdebug

Kérésre törölve 12. · 2010. Már. 12. (P), 15.19
Szerintem netbeans-be állítsd be az xdebug módot,
aztán végig látni fogod hogy miken megy végig.

Minden egyes oldal betöltésénél.