Gå til innhold

Caching - tips, tanker o.l?


Anbefalte innlegg

Hei,

 

Driver en relativt stor nettside nå, og det er et par databasespørringer som kjører hver gang. Disse skulle jeg gjerne ha cachet. Noen her som har erfaring med dette?

 

Har vurdert følgende to metoder hittill:

- Cache resultatet av spørringen (så spørringene bare blir gjort hver 30 sekund e.l.)

- Cache hele nettsiden (så den bare genereres hvert 30 sekund e.l.)

 

Ser for meg at metode nr. 1 er mest fleksibel og realistisk, men hvordan burde jeg gjøre dette? Lagre resultatet i rene flatfiler og hente de derfra? I så fall, hvordan? Som array (serialized)?

 

Setter pris på nyttige innspill her :)

Lenke til kommentar
Videoannonse
Annonse

File caching av spørringene er nok mest feksiblet, i hvertfall vist du har eit brukersystem. Den beste måten å gjøre det på blir vel å bruke en ->fetchAll() lignende metode på spørringen din og legge resutatet i ei tekst fil. Da kan du bruke filemtime() for å skjekke kortid du cachet datane.

 

 

Er på ingen måte noe ekspert på caching bare så det er sakt.

Endret av Runar0
Lenke til kommentar

Jeg r overhodet ingen ekspert på dette området, men jeg ser på min egen statistikk at veldig mye av mine spørringer (MySQL) blir cachet (tror jeg). bruker munin, og grafene der sier i alle fall at mesteparten er "cache_hits". Og jeg har ikke gjort noe aktivt for dette, så mulig det finnes en form for "auto-cache" ?

Lenke til kommentar

MySQL cacher selv, ja, så å lage en sekundær MySQL-cache vil nok være rimelig meningsløst. Det mange derimot gjør er å kjøre en ob_start() og lagre all output hvert 15. minutt. Det blir hentet opp ved hver klient-spørring, og dermed unngår man å kjøre samme PHP-kode hver gang oftere enn hvert 15. minutt.

Lenke til kommentar

Verdien av mysql cachen vil selfølgelig fungere flott så lenge apache serveren og mysql serveren kjører på samme server da overheadet blir minimalt. Men i oppsett der dette ligger separert så vil du kunne spare litt tid ved file caching eventuelt memcache

Lenke til kommentar

Når det gjelder query cache i MySQL er det viktig å påpeke at dette må aktivt aktiveres, default er av. I SHOW VARIABLES; kan du se på QUERY_CACHE_TYPE om den er OFF, ON eller DEMAND. Den må være ON eller DEMAND ( Hvor du må legge til SELECT SQL_CACHE a FROM b; for å bruke QC ) og at QUERY_CACHE_SIZE ikke er null.

 

Men selv med QC bør du cache høyere opp fordi QC blir invalidert ved INSERT, UPDATE og DELETE i tabellen.

 

Til spørsmålet om cache av output eller databasequery er mitt svar "jatakk, begge deler", og gjerne med QC i DEMAND i tillegg i bruk på tabeller uten for mye UDI.

 

Om du har mulighet til det hadde jeg absolutt lagt inn Memcached som nevnt av Runar0, da blir det noe som dette om jeg ikke blinkser fælt.

 

$mc = new Memcache;
$mc->connect( 'localhost', 11211 );
if ( ( $value = $mc->get( $something ) ) === false ) {
$value = mysqlwhatever( somethingwhatnot );
$mc->set( $something, $value, 3600 );
}
echo $value, ' motherfuckers!';

Lenke til kommentar
Når det gjelder query cache i MySQL er det viktig å påpeke at dette må aktivt aktiveres, default er av.

Det var rart, jeg har ikke skrudd den på, og den viser at den cacher i munin grafene. Sikker på at dette ikke kommer ann på hvem distro man bruker på serveren?

Lenke til kommentar

Dersom du har mange joins e.l. kan det være veldig mye å hente på caching av databasekall. Bare det å slippe å koble opp mot mysql vil spare deg en del.

 

Ellers er det fordeler og ulemper ved all caching. Dersom du cacher hele siden, er det bare ett cachehit, noe som er überkjapt. Dessverre vil du da ende opp med å "bygge hele siden" på nytt når cachen går ut.

Annen mulighet er å cache hvert element på siden din, og på den måten får du mye større fleksibilitet, men flere cache hit.

 

Det beste (litt avhengig av hvor mye trafikk) er å bruke en blanding, der hele siden caches for en kort periode. (ett minutt?), mens andre elementer blir cachet på andre tidsintervaller litt avhengig av hvor ofte du føler er nødvendig.

 

Dersom du cacher hele siden må du være forsiktig med poller, innlogging osv., da disse som regel skal vise noe annet basert på en test (innlogget ja/nei, stemt i poll ja/nei).

Endret av Peter
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...