Gjest Slettet-df17e Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 Sitter og fundere litt over en ting her.. Hvordan fungere php caching på webservere, sånn teknisk sett ? F.eks eAccelerator Lenke til kommentar
jorgis Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 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
Peter Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 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
jorgis Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 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
Peter Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 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. Lenke til kommentar
Ernie Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 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
9001 Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 Noen gode artikler om php-optimalisering der ute? Lenke til kommentar
endrebjo Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 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. Lenke til kommentar
jorgis Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 (endret) ...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 Lenke til kommentar
Peter Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 (endret) 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 Lenke til kommentar
Magnus Holm Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 ...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 Lenke til kommentar
Ueland Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 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 Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 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 Lenke til kommentar
Ueland Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 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 Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 (endret) 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 Lenke til kommentar
Ueland Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 Litt mer debug fra Jorgis sin side: http://jorgis.dyndns.org/forum/?debug=1 Se nederst Lenke til kommentar
jorgis Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 Lemen: Signaturen din skrives mye mer elegant som en regexp: /(bb|[^b]{2})/ Lenke til kommentar
genstian Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 En del mer effektivt enn PHP filecaching. http://no2.php.net/manual/en/ref.memcache.php Lenke til kommentar
jorgis Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 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
Peter Skrevet 25. oktober 2006 Del Skrevet 25. oktober 2006 zlib er vel rimelig standard på omtrent alle installasjoner. PECL derimot :/ Lenke til kommentar
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå