Gå til innhold

PHP·pub - Programming With Attitude - and beer


Anbefalte innlegg

Videoannonse
Annonse

De hopper vel over selve kompilasjonen av scriptet, da du ikke har modifsert selve scriptet ved hver kjøring, og lagrer den kompilerte koden i minne. Resultatet er at koden din ikke må kjøre gjennom lesing, parsing og kompilering hver eneste gang, men kan hentes direkte fra minne, binært. :)

 

eAccelerator stores compiled PHP scripts in shared memory and executes code directly from it. It creates locks only for a short time, while searching for a compiled PHP script in the cache, so one script can be executed simultaneously by several engines. Files that can't fit in shared memory are cached on disk only.

 

En annen ting er at en kan optimalisere rådkoden før den sendes til parsing/kompilering, f.eks. optimalisere enkelte løkker eller if-setninger til mer effektive varianter. :)

Lenke til kommentar
En annen ting er at en kan optimalisere rådkoden før den sendes til parsing/kompilering, f.eks. optimalisere enkelte løkker eller if-setninger til mer effektive varianter. :)

7148266[/snapback]

Hadde vært spennende å se om det gikk.

Ettersom jeg da regner med at det må en del ekstra logikk til for å finne ut hvordan ting kan optimaliseres.

Dette lønner seg antakelig ikke for sider med relativt få brukere og mange oppdateringer. Dog for store sider, med få oppdatering vil nok dette lønne seg.

Men disse to scenarioene er jo litt motstridene.

 

Hadde ihvertfall vært spennende å se.

Lenke til kommentar
En annen ting er at en kan optimalisere rådkoden før den sendes til parsing/kompilering, f.eks. optimalisere enkelte løkker eller if-setninger til mer effektive varianter. :)

7148266[/snapback]

Hadde vært spennende å se om det gikk.

Ettersom jeg da regner med at det må en del ekstra logikk til for å finne ut hvordan ting kan optimaliseres.

Dette lønner seg antakelig ikke for sider med relativt få brukere og mange oppdateringer. Dog for store sider, med få oppdatering vil nok dette lønne seg.

Men disse to scenarioene er jo litt motstridene.

 

Hadde ihvertfall vært spennende å se.

7148367[/snapback]

 

Optimalisering og caching vil jo skape overhead om en ikke har noe særlig trafikk, men for de aller fleste sider vil det lønne seg, da overhead er rimelig liten sammenlignet med fordelene en får av det. :)

Lenke til kommentar
De hopper vel over selve kompilasjonen av scriptet, da du ikke har modifsert selve scriptet ved hver kjøring, og lagrer den kompilerte koden i minne. Resultatet er at koden din ikke må kjøre gjennom lesing, parsing og kompilering hver eneste gang, men kan hentes direkte fra minne, binært. :)

 

eAccelerator stores compiled PHP scripts in shared memory and executes code directly from it. It creates locks only for a short time, while searching for a compiled PHP script in the cache, so one script can be executed simultaneously by several engines. Files that can't fit in shared memory are cached on disk only.

 

En annen ting er at en kan optimalisere rådkoden før den sendes til parsing/kompilering, f.eks. optimalisere enkelte løkker eller if-setninger til mer effektive varianter. :)

7148266[/snapback]

Nå er det begrenset hvor mye man tjener på å optimalisere noen enkeltstående if/elseif da. Der man har mye å tjene er som regel looper, og da type skrive om hele greia. Så må vi heller ikke glemme at man får en stooooor bonus når man bruker ob. Typisk 10-15% bedre ytelse.
Lenke til kommentar

...men ikke putt alt inn i én monsterspørring heller... ;)

 

Om en kan, unngå å røre databasen i det hele tatt; stikk inn her, og se hvordan cachingen kicker inn etter første refresh. For å være en 500MHz-boks, er dette rimelig bra ytelse?

Run time: 0.028 seconds - Queries: 0

 

 

PS: Bare en teknisk demo, resten av siden er stort sett ødelagt. :p

Endret av jorgis
Lenke til kommentar
Det er også en stor fordel å gjøre så mye som mulig i databasen før det overføres til PHP-motoren, og i tillegg bare sende de nødvendige kolonnene istedetfor *.

Også er det selvfølgelig best å kjøre færrest mulig spørringer.

7151236[/snapback]

Det er to veldig gode poenger.

Mange undervurderer databaser, men disse er optimalisert og som regel mye raskere enn noe du klarer å skrive selv.

 

 

Selvfølgelig veldig godt poeng det jorgis sier også om caching, dog et ganske mye vanskeligere tema etter min mening.

Endret av Nazgul
Lenke til kommentar
...men ikke putt alt inn i én monsterspørring heller... ;)

 

Om en kan, unngå å røre databasen i det hele tatt; stikk inn her, og se hvordan cachingen kicker inn etter første refresh. For å være en 500MHz-boks, er dette rimelig bra ytelse?

Run time: 0.028 seconds - Queries: 0

 

 

PS: Bare en teknisk demo, resten av siden er stort sett ødelagt. :p

7151272[/snapback]

Først: 4 querys

Så: 14 querys (!)

Til slutt: 0 querys :)

Lenke til kommentar

Judofyr: Rettelse, et par refresher da, når data lastes inn puttes ting på filcache, samt mindre informasjon i sessions, istedet for å laste det inn konstant.

 

Samme system parser på nedtil 0.007 sekunder hos meg, og til en forumforside å være så er jeg fornøyd. (Det og med OOP kode).

Lenke til kommentar
Gjest Slettet-df17e
stikk inn her, og se hvordan cachingen kicker inn etter første refresh. For å være en 500MHz-boks, er dette rimelig bra ytelse?

7151272[/snapback]

 

Men her er cachingen skriv i PHP, stemmer ikke det ? Isåfall, hvordan fungerer det ? Får meg ikke helt til å skjønne det med en gang jeg :p

Lenke til kommentar

Lemen: Det går i PHP ja, grovt sagt er målet å sørge for at resultatet av flest mulig spørringer lagres som tekstfiler, og så heller bruke disse istedet for å drive på å utføre spørringer hos databasen konstant.

 

Komplisert sagt må man og blande inn fjas rundt alder på filer slik at de oppdaterer seg når de skal og så videre. ;)

Lenke til kommentar
Gjest Slettet-df17e

Det har jeg faktisk alderi tenkt på, men er jo genialt! Gikk opp et lite lys for meg nå :)

Endret av Slettet-df17e
Lenke til kommentar
En del mer effektivt enn PHP filecaching.

 

http://no2.php.net/manual/en/ref.memcache.php

7152185[/snapback]

 

Og hvor portabelt er så dette? Om det krever Zlib, samt at det må installeres som en egen PCEL-extension, så er det greit nok for én enkelt install, hvor du vet hva scriptet skal kjøre på, men det nytter ikke å prøve å lage et portabelt script når du avhenger av slike ting. :)

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...