Gå til innhold

Lagre PHP scripts i cache?


Anbefalte innlegg

Hei,

 

jeg har en side hvor det er endel trafikk. Og trur et cache system kunne vært kjekt for å fått opp hastigheten.

Hva er anbefalt da? Å lagre selve sidene i cache, eller lagre mysql i cache (info man henter ut om brukeren), slik at man slipper å hente ut fra databasen på vær eneste sidevisning.

 

Noen tips til caching?

 

Noen som vet hvordan dette kan gjøres?

Endret av Thomas.
Lenke til kommentar
Videoannonse
Annonse

Å cache selve den genererte HTML-koden gjøres sjeldent, ettersom man ofte alltid vil ha små endringer på siden hele tiden og å rendre HTML er egentlig ikke så krevende. Som regel er det mest å hente ved å redusere antall hits på databasen. Dersom innholdet er lite personalisert - altså at den er lik for alle den vises til - så kan du lagre resultater fra queries og slippe å kjøre disse ved hver sidevisning.

 

Memcached er omtrent de facto standard for denne typen caching. Det er svært lett å implementere i bl.a. MVC-arkitekturer og er utrolig effektivt.

Endret av Jonas
Lenke til kommentar

Dersom innholdet er lite personalisert - altså at den er lik for alle den vises til - så kan du lagre resultater fra queries og slippe å kjøre disse ved hver sidevisning.

 

Memcached er omtrent de facto standard for denne typen caching. Det er svært lett å implementere i bl.a. MVC-arkitekturer og er utrolig effektivt.

 

Ja, noe slikt.

Queries lagres i cache. Men om resultatet endres bør vel cache'n oppdateres?

Gjør memcached det?

Lenke til kommentar

Nei, memcache gjør ikke det - og det er på en måte litt av poenget. Dersom du vil ha live og oppdatert data til en hver tid, så er ikke caching noe for deg. Caching handler nettopp om å mellomlagre dataen og den slettes typisk i intervaller eller on-demand. F.eks. så kan du mellomlagre brukerinformasjon og dersom en bruker oppdaterer informasjonen i kontrollpanelet, så kan du da slette det som er cached.

Lenke til kommentar

Litt avhengig av kode etc. kan en PHP accelerator gi ganske heftig utslag på ytelsen. Kanskje noe å se på? Uansett, har du sett på andre måter enn caching for å få opp ytelsen? Vurdert om det er noen grep i selve koden som kan gjøres for å få opp ytelsen, og har du hensiktsmessige indekser i MySQL?

Lenke til kommentar

Litt avhengig av kode etc. kan en PHP accelerator gi ganske heftig utslag på ytelsen. Kanskje noe å se på? Uansett, har du sett på andre måter enn caching for å få opp ytelsen? Vurdert om det er noen grep i selve koden som kan gjøres for å få opp ytelsen, og har du hensiktsmessige indekser i MySQL?

 

Hvordan bruker man PHP accelerator? Noe man laster ned?

Andre måter en cache? Du mener f.eks innstilling av lighttpd osv?

 

Indekser bør være de som blir brukt mest, sant?

 

 

Og jeg lurer på en anen ting her, jeg skulle hatt en side som oppdateres hvert 20 minutt. Hva er beste måten til dette? Bruke cronjob å lagre resultatet i cache?

Lenke til kommentar

Litt avhengig av kode etc. kan en PHP accelerator gi ganske heftig utslag på ytelsen. Kanskje noe å se på? Uansett, har du sett på andre måter enn caching for å få opp ytelsen? Vurdert om det er noen grep i selve koden som kan gjøres for å få opp ytelsen, og har du hensiktsmessige indekser i MySQL?

 

Hvordan bruker man PHP accelerator? Noe man laster ned?

Jepp, det er noe man laster ned. Finnes flere av de (APC, eaccelerator, xcache, zend et eller annet ...) og fellers for de alle er at de cacher bytecode (mellomlag mellom kildekoden og maskinkode). I praksis betyr det den hverken henter filene fra disk eller kompilerer de til bytecode, noe man sparer endel på. I tillegg optimaliserer en del av de også koden slik at man totaltsett gjerne ender opp med eksekvering som typisk er 2-3x raskere og i ekstremetilfeller kan være så mye som 15x raskere. Har ikke testet ut annet enn APC (eneste som lå/ligger i repo. for Fedora), men forskjellen er uansett ikke allverdens. Dessuten blir APC inkludert i PHP6, og ser ut til å være svært oppdatert i forhold til PHP-versjoner.

 

Andre måter en cache? Du mener f.eks innstilling av lighttpd osv?

Ja, forsåvidt det også, men det var ikke helt det jeg tenkte på. Det jeg er mer ute etter er om du f.eks har noen store, stygge looper som slukter tid. Riktignok er dette mer mat for en profiler (xdebug f.eks).

 

Indekser bør være de som blir brukt mest, sant?

Nja, MySQL velger bare en indeks så SQL-spørringene så indeksene må fort være sammensatte i en spesiell rekkefølge slik at man også for skrevet spørringer som utnytter indeksene. F.eks trenger du ikke en indeks for felt1 hvis du ofte også søker på felt1 og felt2 (merk at spørringen da være utformet med felt1 = 'verdi' AND felt2 = 'verdi2', ikke motsatt). Da holder det med å danne en indeks for begge og plassere felt1 først i indeksen. MySQL vil da benytte indeksen også når det bare søkes på felt1. Samme gjelder hvis du har flere enn 2 felter også.

 

Og jeg lurer på en anen ting her, jeg skulle hatt en side som oppdateres hvert 20 minutt. Hva er beste måten til dette? Bruke cronjob å lagre resultatet i cache?

Ja, og da fortrinnsvis i minnet hvis mulig. Du trenger forsåvidt ikke bruke cron heller. Ut fra manualen ser det ut som både APC og memcached tar imot en ttl for det man lagrer. Da er det bare å hente ut og skulle man få false tilbake veit man at man må cache på nytt.
Lenke til kommentar
jeg har en side hvor det er endel trafikk. Og trur et cache system kunne vært kjekt for å fått opp hastigheten

Hva er anbefalt da? Å lagre selve sidene i cache, eller lagre mysql i cache (info man henter ut om brukeren), slik at man slipper å hente ut fra databasen på vær eneste sidevisning.

Manuell cache introduserer en potensielle problemer og krever mer av utvikleren, jeg anbefaler at du først gjør de endringene som gir deg "gratis" ytelse, så fikse koden din slik at den naturlig blir raskere, så omkonfigurere serverne, så legge til datacaching og til slutt output-caching. Etter at dette er gjort er neste steg å legge til mer maskinvare, men på det punktet skal du normalt servere hundrevis av brukere i sekundet på en normal server, altså langt over det de fleste gjør.

 

Det første gratistrikset jeg hadde gjort er det Ernie anbefaler ved å installere APC:

Litt avhengig av kode etc. kan en PHP accelerator gi ganske heftig utslag på ytelsen.

Neste gratistriks er å tune databasen for bedre ytelse. Dersom MySQL brukes bør du f.eks sjekke at Query Cache er påslått og at du har nok sorterings-cache.

 

Forbedring av koden innebærer som Ernie nevnte ofte en profiler som xdebug hvor du ser hvilke deler av koden som bruker lengst tid. SQL-spørringer er en vanlig synder her. Bruk databasens analyseverktøy for å sørge for at du ikke ender opp med table scans, treffer indexer og at Query Cache brukes og treffes. For MySQL legger du kommandoen explain forran spørringen for å se en analyse. Subselects, un-anchored tekstsøk (LIKE '%noe%'), funksjonskall på venstre siden av likhetstegn og bruk av funksjoner som gjør spørringen unik (bruk av NOW() f.eks) er ting som kan kraftig trege ned en spørring.

 

Etter at det er gjort kan du bruke f.eks Memcached eller APC til å cache datasettet som brukes. Det viktige da er å tenke på purging, warming og eventuelt bruk av stale cache, men med mindre det er viktig at alle endringer blir aktive med en gang hadde jeg bare cachet alt i tredve sekunder og sett hvor mye det hjelper.

 

Indekser bør være de som blir brukt mest, sant?

Optimalt sett bruker du alltid en index i spørringene dine og explain er et godt verktøy for å finne den mest optimale.

 

Og jeg lurer på en anen ting her, jeg skulle hatt en side som oppdateres hvert 20 minutt. Hva er beste måten til dette? Bruke cronjob å lagre resultatet i cache?

Det kan være den beste metoden og det kan være det ikke er den bestes metoden. Med mindre du er veldig redd for ekstrem thread pileup er det beste å sette TTL og la cachen expire av seg selv og bli varmet on demand.

 

Å cache selve den genererte HTML-koden gjøres sjeldent, ettersom man ofte alltid vil ha små endringer på siden hele tiden og å rendre HTML er egentlig ikke så krevende.

Skjeldent på normale systemer, men mer vanlig på høykapasitetssider. Apache med mod_proxy, Lighttpd og Nginx satt opp som proxy, Squid eller Varnish er de mest brukte og ofte essensielle.

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