Er det dumt med for mye kode i en fil?

[Mr Vest]

Noen på forumet her har nok fått med seg at jeg for tiden sitter og roter mye med PHP. Jeg føler absolutt at jeg begynner å få taket på mye nå, selv om det enda kommer litt teite spørsål fra meg. Disse skyldes vel i all hovedsak at jeg kanskje er litt for ivrig med å lære meg forkjellige ting på en gang, noe som sørger for at ting går i surr der oppe i topplokket.

Over til spørsmålet:

Er det negativt med for mye phpkode i en og samme phpfil? En litt bedre forklaring på akkurat hva jeg mener følger.

La oss si at jeg lager en fil som heter index.php. I Index.php har jeg kodet inn enormt mye forkjellig nedover og bruker da altså:

if($_GET['do']=="do1")
{
}
else if($_GET['do']=="do2")
{
}
else if($_GET['do']=="do3")
{
}
else {
}

Og slik fortsetter den altså gjerne gjennom 4000 linjer med kode. Er dette negativt dersom det skulle være 2-300 evt flere online samtidig som da bruker denne filen? Jeg ser jo for meg at dersom 2-300 folk skulle komme og trakke på meg samtidig at jeg ville bli litt ødelagt... Kan det være negativt også for en PHPfil at så mange kommer og trakker på den samtidig? Anbefaler du at jeg deler opp denne koden i flere filer?

 

[mkander]

Dette virker ikke som en optimal løsning mtp ytelse. Ideelt bør kun den koden som skal kjøres lastes inn i minnet og koden bør gjøres så optimal og enkel som mulig. En haug med if-sjekker slik du beskriver det bidrar ikke til det Hvis du har 4000 linjer i samme fil vil jeg tro at du også sliter med å holde oversikten etterhvert.

Anbefaler å ta en titt på et rammeverk som f.eks. CodeIgniter, da får du fin struktur på koden og kan dele den opp bedre uten å måtte kode ting om igjen.

Når det er sagt er en haug med if-sjekker slik du skisserer det over ikke veldig tungt for maskinvaren. Tror ikke du vil merke noen store ytelsesproblemer grunnet dette hvis du ikke har tusenvis av besøkende per dag.

 

[Mr Vest]

Mhm, det er det som er greia. Jeg begynner å miste litt oversikten over selve fila hvor jeg har klart å legge inn nærmere 4000 linjer. CodeIgniter søkte jeg opp i Google. Forstod ikke helt hva det var for noe, men skal lese litt mer om det utpå kvelden.

Jeg legger ikke merke til noe problemer med selve farta selv om det er så mange linjer nei. Det går lynkjapt og alt kommer frem på skjermen umiddelbart. Det jeg tenkte var mer om det ville gått like fort dersom 300stk kjører gjennom denne fila samtidig.

Ellers, takk skal du ha. Om CodeIgniter viser seg å gjøre litt jobb for meg slik at jeg kan dele dette opp uten å kode noe på nytt ville jo det være geniale saker.

 

[picxx]

En indexfil ser optimalt slit ut for meg:
include header
include index
include footer

Om en skal style forsiden på forskjellige måter kan dette gjøres både i designets .css fil eller i en egen .css fil, men en trenger strengt tatt ikke noen egen index fil i wordpress.

 

[Mr Vest]

Hmm.. Inkluderer du index.php i index.php, picxx? Og hva med Wordpress?

 

[picxx]

Det jeg tenkte var mer om det ville gått like fort dersom 300stk kjører gjennom denne fila samtidig.

Det bvør , hos de aller fleste webhoster, uten problemer.
Snakker man derimot om kanskje 300.000 hvert minutt vil nok de fleste steile grunnet ressurser (minne) og en må skaffe seg host eller egen boks utifra eget behov.

 

[picxx]

Hmm.. Inkluderer du index.php i index.php, picxx? Og hva med Wordpress?

Jeg gjør alltid om index til home.php i sider som er noe å snakke om, og da inkluderer jeg selvsagt index rett etter header.

 

[Mr Vest]

Det er ikke Wordpress jeg tenker på her. Det er små enkeltstående PHPfiler.

Men hvorfor bruker du home.php i Wordpress? Det er jo det samme som index.php bare det at den blir hentet ut som et førstevalg, dvs at den først sjekker om home.php eksisterer og dersom den ikke gjør det så laster den index.php.

 

[hansvh]

Å dele koden inn i flere filer har ingen hensikt rent ytelsesmessig. Det er selvsagt normal å gjøre for å få struktur og modularitet.

I værste fall kan å dele koden inn i forskjellige filer få negative konsekvenser mtp. ytelse pga. fragmentering på disk. I/O, og da gjerne søketid, er det som tar lengst tid, så lesing fra disk burde minimeres, og i alle fall være sekevnsiell. PHP-fier er jo små, så hvis du har mange små filer spredd over hele disken blir det mye jobb for lesehodet. Hvis du i tillegg har shared hosting så andre brukere også trenger disken kan dette bli flaskehals.

Ang. if() elseif() else så benyttes kun CPU initiellt i if-sjekken. Dersom denne slår til vil ikke elseif eller else bli eksekvert (så klart) så det som ligger i disse skopene vil ikke kreve CPU tid.

 

[mkander]

Det er ikke bra mtp ytelse å laste inn masse kode som ikke er nødvendig. Det gjør at det blir mer data som lastes inn i minne og det blir mer jobb å parse scriptet. Lesing på disk bør også gjøres til et minimum som hansvh sier. Det kan du f.eks. gjøre ved å ha følgende oppsett:
opprett.php
slett.php

istedet for

index.php?page=opprett
index.php?page=slett

 

[Mr Vest]

Men Hansvh skriver jo at dersom jeg har mange If'er nedover slik som dette:

index.php?page=opprett
index.php?page=slett

at det da ikke blir brukt harddisk med prosessorkraft (CPU), og at det ikke overbelaster prosessoren når den går gjennom dem. Hva er det beste med tanke på mest brukere samtidig da? Flere filer i samme mappe eller flere If'er i samme fil?

 

[hansvh]

Koden vil havne i minnet uavhengig av om man skriver all koden i en fil eller bruker include fra en annen.

Det er to faktorer som kan bli flaskehals og det er I/O og CPU tid. CPU tid er ikke en faktor hvis du ikke gjør masse unødvendige beregninger. Å plassere if-sjekker på riktig sted og ha god flyt i koden er måten å optimere på der.

 

[tyr897]

Det er noe som heter "premature optimization". Å flisespikke på disse små tingene er ikke det som gjør den store forskjellen i ytelse, det er det komplekse spørringer og operasjoner, samt mangel på caching, som gjør.

Det er adskillig viktigere å splitte opp koden for å ha oversikt, og ha muligheten til enkelt å videreutvikle, enn å tenke på om du sparer marginalt med cpu og søketid ved å stappe alt i en fil fremfor to. Dersom du har veldig mange filer, slik som i f.eks. Zend Framework, vil dette begynne å ha betydning. Det kan løses ganske greit med å bruke APC, som du uansett bør ha aktivert i produksjonsmiljø, samt eventuelt å begynne å kombinere store filer som inkluderes ofte. Dette er med andre ord aspekter som tenkes på til slutt, ikke når du strukturer koden din.

Altså, tenk struktur og kodeflyt. Bruk APC, caching og gode spørringer (og indekser). Vurder å bytte ut Apache med f.eks. lighttpd eller nginx, eventuelt bruk tid å fininstille Apache. Kontroller at MySQL (e.l.) konfigurasjonen er hensiktsmessig. Sliter du med mye I/O pga. inkludering, kombiner i en stor fil som du cacher i RAM. Dersom du fortsatt har ytelsesproblemer er det nok på tide å utvide serverparken, ikke tenke på om du har en if/else for mye.