PHP·pub - Programming With Attitude - and beer

[Gjest Slettet-df17e]

Sitter og fundere litt over en ting her..

Hvordan fungere php caching på webservere, sånn teknisk sett ?

 

F.eks eAccelerator

[jorgis]

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.

[Peter]

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.

[jorgis]

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.

[Peter]

Caching skaper vel minimalt, ettersom det må kjøres minst én gang uansett.

Uansett bare interessert i å se poc, ettersom jeg ikke har gjort noe slikt før.

[Ernie]

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.

[9001]

Noen gode artikler om php-optimalisering der ute?

[endrebjo]

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.

[jorgis]

...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.

Endret 25. oktober 2006 av jorgis

[Peter]

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 25. oktober 2006 av Nazgul

[Magnus Holm]

...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.

7151272[/snapback]

Først: 4 querys

Så: 14 querys (!)

Til slutt: 0 querys

[Ueland]

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).

[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

[Ueland]

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.

[Gjest Slettet-df17e]

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

Endret 25. oktober 2006 av Slettet-df17e

[Ueland]

Litt mer debug fra Jorgis sin side:

http://jorgis.dyndns.org/forum/?debug=1

 

Se nederst

[jorgis]

Lemen: Signaturen din skrives mye mer elegant som en regexp:

 

/(bb|[^b]{2})/

[genstian]

En del mer effektivt enn PHP filecaching.

 

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

[jorgis]

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.

[Peter]

zlib er vel rimelig standard på omtrent alle installasjoner. PECL derimot :/