Brug MySQL's indbyggede forespørgselscache i stedet for at prøve at vedligeholde den selv. Det vil automatisk rydde cachelagrede forespørgsler til tabeller, når de skrives til. Derudover fungerer det i hukommelsen, så det burde være meget effektivt...
Du skal heller ikke kun cache forespørgsler. Prøv at cache hele segmenter af applikationen på forskellige stadier i gengivelsescyklussen. Så du kan lade MySQL cache forespørgslerne, derefter cache hver enkelt visning (gengivet), hver enkelt blok og hver side. Derefter kan du vælge, om du vil trække fra cachen eller ej, baseret på anmodningen.
For eksempel kan en ikke-logget bruger få hele siden direkte fra cachen. Men en logget bruger er muligvis ikke i stand til det (på grund af brugernavn osv.). Så for ham kan du muligvis gengive 1/2 af dine visninger på siden fra cache (da de ikke afhænger af brugerobjektet). Du får stadig fordelen ved at cache, men det vil blive opdelt efter behov.
Hvis du virkelig forventer en masse trafik, er det bestemt værd at kigge nærmere på Memcached
. Lad MySQL gemme dine forespørgsler for dig, og gem derefter alle brugerland-cache-elementer i memcache...
Rediger: Sådan besvarer du din redigering:
Filsystemer kan blive langsomme, hvis en enkelt mappe bliver stor. Så længe du "navnemellemrum" efter mappe (så hver mappe kun har en lille del af cache-filer), burde du have det fint fra det synspunkt. Hvad angår den nøjagtige tærskel, vil det virkelig afhænge af dit hardware og filsystem mere end noget andet. Jeg ved, at EXT3 bliver ret langsom, hvis der er en mængde filer i en enkelt mappe (jeg har mapper med bogstaveligt talt hundredtusindvis af filer, og det kan tage op til et halvt sekund at stat() en af filerne, endsige lave enhver form for mappeliste)...
Men indse, at hvis du tilføjer en anden server, vil du enten have duplikering af cache (hvilket ikke er en god ting), eller bliver nødt til at omskrive hele dit cachelag. Er der en grund til ikke at gå med Memcached lige fra starten?
Rediger 2: Sådan besvarer du din seneste redigering:
Det er stadig for svært at ringe. Jeg har en applikation, der har en database med omkring 1,5 milliarder rækker (vokser med omkring 500k pr. dag). Vi bruger overhovedet ingen caching på det, fordi vi ikke har problemer med samtidighed. Og selvom vi gjorde det, ville vi være bedre tjent med at kaste flere MySQL-servere på det i stedet for at tilføje cache, da enhver form for cache ville have så lav en hitrate, at det ikke ville være udviklingstiden værd at tilføje det.
Og det er grunden til, at jeg er så stejlt på ikke at cache for hastighed. Der vil altid være et objekt, der ikke er i cachen. Så hvis du rammer en side med et af disse objekter, skal det stadig være hurtigt. Som en tommelfingerregel forsøger jeg at cache alt, der vil blive tilgået igen i løbet af de næste par minutter (jeg holder en tid til at leve på omkring 5 minutter i produktion på andre applikationer alligevel). Så hvis elementer ikke får mere end et par hits i det tidsrum, eller hitraten er meget lav (mindre end 90%), gider jeg ikke cache det element...