caching

Hallo,

Ik wil in mijn framework / cms een caching functie inbouwen, maar ik wil graag een paar dingen weten. Ik ken zelf 2 manieren van caching, namelijk het cachen van databasegegevens en het cachen van complete pagina's (html). Nu vraag ik me af (vanuit performance oogpunt) of ik beide manieren in mijn cms moet gaan implementeren.

Stel je hebt een homepage waarin je 4 includes uitvoert (bijv. header, menu, content, footer) en waar je op 3 verschillende locaties databasegegevens nodig hebt. Nu lijkt het mij heel erg zinvol om die databasegegevens te cachen (denk bijv. aan de menuitems, de content (tekst) en een paar linkjes in de footer). Door deze in 1 bestandje te cachen hoeven er niet 3x databasegegevens te worden opgehaald. Dat lijkt me een goede performance winst! Maar nu vraag ik me dus af... zou het zin hebben om die COMPLETE pagina te cachen? Zodat er dus uiteindelijk slechts 1 (html) bestand wordt geinclude (in plaats van 4 includes)? Dit lijkt misschien handig, maar volgens mij betekent het dan wel dat ik van ieder bestand dat normaal gesproken geinclude zou moeten worden, telkens zou moeten controleren (aan de hand van de "laatst gewijzigd" tijd) of het bestand nog actueel is, of opnieuw gecached moet worden. Mijn vraag is dan ook of het cachen van complete pagina's een meerwaarde heeft. Van het cachen van databasegegevens zie ik zeker de meerwaarde in, maar over het cachen van complete pagina's twijfel ik. Kan iemand daar iets meer over vertellen?

Oh ja, stel dat je een webshop hebt met vele duizenden artikelen waarvan de prijs dagelijks verandert. Ga je dan ook de databasegegevens cachen? Dat lijkt me heel lastig. Stel je hebt een productoverzichtspagina waarop 30 artikelen worden getoond met 20 pagina's. Ga je dan automatisch de databasegegevens cachen zodra iemand zo'n pagina bezoekt? Is dat zinvol? De dag erna veranderen alle gegevens namelijk weer. En stel dat de gebruiker het aantal artikelen op 10 per pagina kan zetten (in plaats van 30) dan krijg je dus 60 pagina's. Moet je die dan allemaal gaan cachen?

Ik ben benieuwd of iemand mij wat algmene info kan geven, wanneer je caching toepast, en of caching van complete pagina's daadwerkelijk voordeel oplevert. Graag jullie reacties!

Ik heb geen ervaring met webshop maar ik zou zeggen helemaal niets cachen. Er moet altijd disk i/o gedaan worden om gegevens op te halen, of je nu een html bestand ophaalt of wat uit de database ophaalt, wat is het verschil. Bouw een benchmark systeem en ga je i/o's meten. Hoeveel disk i/o's voor het een en hoeveel disk i/o's voor het andere? Ik werk met webapplicaties en (Oracle) databaseses en er wordt helemaal niets gecached, nooit. Aantal gebruikers +500 continue, betreft onder andere drie landelijke callcentra.

Nog nooit gebruikt.

@SanThe: dus stel jij hebt een homepage en je hebt op 3 plekken gegevens uit de database nodig, dan voer jij dus 3x een query uit?

@Aad: het cachen van databasegegevens is niet verkeerd. Stel je hebt op 3 plekken op je pagina databasegegevens nodig dan haal je die gegevens uit de database en schrijft ze weg in een bestandje. Volgende keer kijk je of dat bestandje bestaat. Ja, dan het bestandje inlezen en zo bespaar je 3 database queries.

Het cachen van een complete pagina zou dan op eenzelfde manier werken. Is er een gecachte versie, dan die inladen. Zo niet, pagina laden en een cahce bestand van maken. Echter, je zult dan wel telkens moeten controleren of de pagina wel actueel is. Want anders zou het kunnen zijn dat jij in een van de pagina's iets verandert, maar dat dat niet zichtbaar wordt omdat de gecachete versie getoond wordt. Je zal dus voor iedere pagina een controle moeten doen of dat ie gewijzigd is, en de vraag is of deze controles dan nog wel opwegen tegen de beoogde performance winst.

@Ozzie, vergeef me dat ik kritisch ben maar alleen als je deze bewering kan onderbouwen: "het cachen van databasegegevens is niet verkeerd" dan overtuig je me pas. I/o per functie ??

Caching is op zich wel leuk, maar vaak overbodig. Het betekent dat je een template engine nodig hebt, een lexter en een parser moet gebruiken en dat kost ook veel cpu. Het resultaat is vaak een .html bestand en ja, zodra een pagina gecached is scheelt het enkele roundtrips van server <-> database <->server <-> client. Het enige wat je dan hoeft te doen is checken of de pagina up to date is en een .html bestand terug geven.

het nadeel is echter dat je vaak dynamische pagina`s wil houden. M.a.w. ingelogde gebruikers moeten wel hun "eigen" naam te zien krijgen, z`n meest recente topics etc. Dus je zult hoe dan ook roundtrips moeten maken.

Caching is leuk voor statische websites, waar het meer om informatie voorziening gaat. Of je moet specifiek templates cachen voor bijvoorbeeld menu`s, sidebars, footers etc. De rest hou je dan dynamisch. Dat scheelt ook weer. Maar je zult vaak hoe dan ook je database moeten aanroepen.

Ja dat is een strakke manier om te cachen. Dat is sowieso raadzaam als je wilt gaan cachen. Als je op runtime gaat cachen zodra er iets verandert scheelt dat enorm in checks. Op die manier kun je ook .html bestanden gaan cachen. Als je een menu structuur aan gaat passen kun je direct een nieuwe cache bestand aanmaken voor je menu.html, dat scheelt uiteindelijk, dan hoef je runtime niet continu je query naar je menu te doen, alleen een include van menu.html. Dan hoef je ook niet op timestamp te controleren of er een nieuwe versie is.

Het enige grote nadeel is dat je geen echte cache controllers hanteert. Je cached alles runtime dus je hebt weinig controle over je cache voorraad en dat kan een probleem opleveren als je een rollback wilt doen of iets dergelijks. Maar goed, dat heb je weinig nodig gelukkig :)

Database queries die vaak gebruikt worden kun je inderdaad wel gewoon cachen, als er weinig verandert, dan kun je daar met een simpele check controleren of er een nieuwe versie is.

Al met al hoeft caching niet, het _kan_ theoretisch een verschil opleveren. Praktijk echter is dat de verschillen vaak marginaal zijn, het wordt pas interessant met enorme hoeveelheden requests omdat je dan de server(s) kunt ontzien qua load. Als je alleen maar een paar .html bestanden hoeft te includen kan dat vanaf je root / cache folders, dat scheelt, hoeft PHP het bijvoorbeeld niet runtime en on-the-fly allemaal te controleren.

Maar dan hebben we het al gauw over enkele duizenden requests per uur.

Ik kom toch weer even met mijn kritische opmerking: Niemand heeft enig bewijs, het zijn vooral onderbuik gevoelens en gedachten van queries duren te lang. "van horen zeggen en geleerd" is geen sluitend bewijs en leeft een eigen leven. MySQL en query processing/roundtrips wordt te zwaar gewogen zonder enig bewijs. Voorlopig zeg ik, niks cachen want mede gezien de controles genereer je ook veel i/o dus het paard achter de wagen spannen. Iemand een mening onderbouwd met aantallen i/o's en cpu/sec??
@Marijn: wat zijn echte cache controllers??

Ik denk dat je dan toch vooral eens Google moet raadplegen om te kijken of het enkel "onderbuik" gevoelens zijn. Je hebt het veel over IO maar databases zijn net zo hard IO operaties + daar komt bij dat je ook nog index sleutels mee moet nemen. Een SQL algoritme dat ongelofelijk snel is, is nog altijd langzamer dan een simpel bestandje ophalen vanaf een vaste locatie. Dat is geen onderbuik gevoel. Dat is puur en simpel logica in z`n meest voor de hand liggende vorm. IO operaties zijn traag, het is het traagst van alle operaties die je kunt hebben in een computer. Als je cache controllers gebruikt skip je de hele IO en haal je dingen op uit je registers of uit het geheugen. Dat scheelt ontzettend veel. Zelfs de snelste SSD schijf zal moeite hebben om in de buurt te komen van een memory call. Waarom? Omdat memory daar nou eenmaal voor gebouwd is! Registers op je CPU of de cache op je CPU zijn daar juist voor gemaakt. Als je daar raadzaam mee om weet te gaan kun je een request tot 90% sneller verwerken zonder dat je meer resources nodig hebt.

Echte cache controllers zijn de "engines" die je als PEAR packages kunt gebruiken in je applicatie. APC of Zend Cache. Daar zijn mooie interfaces voor gebouwd die je kunt raadplegen voor cache. Cache controls zitten vaak in template engines mits je caching toe laat. Maar hier geldt dat ze vooral ook static files inladen, als je je echte hardware cache gebruikt, weet je hier zoveel meer uit te halen dan statische files includen. Al scheelt het alsnog meer dan wanner je voor elke request opnieuw dezelfde queries continu moet uitvoeren.

Heren, de discussie gaat een beetje de verkeerde kant op.

Mijn vraag is / was wat je "moet" cachen. Zijn er nog andere mensen die hier een mening over hebben? Zelf zie ik dus het nut van het cachen van databasegegevens in, omdat je dan minder queries hoeft uit te voeren. Echter, het cachen van complete pagina's daar zet ik m'n vraagtekens bij, omdat je dan telkens zou moeten controleren of iedere (ingesloten) pagina die geinclude moet worden wel of niet up to date is. Dat controleren kost ook tijd, en dus kun je, denk ik, net zo goed die pagina's niet cachen. Maar ik zie dus wel het voordeel in van het cachen van databasegegens.

Iemand hier nog iets aan toe te voegen?

Hoi Aaron,

Dankjewel voor het testen! Het scheelt in ieder geval dus wel iets. Ik denk dat ik in ieder geval het compleet cachen van pagina's maar moet vergeten en dat ik alleen de database acties dan ga cachen... mits deze voor langere tijd onveranderlijk zijn, want net zoals jij zegt... op een forum waar de (re)acties elkaar zeer snel opvolgen heeft het weinig zin. Maar stel je hebt een bedrijfswebsite, dan kun je bijv. de laatste 5 nieuwsberichten op de homepage tonen en die zou je dan uit de cache kunnen halen ipv uit de database aangezien die berichten toch niet heel vaak zullen veranderen.