[PHP] Serverside caching

[Maxman1850]

Vaak zie ik website die serverside caching toepassen. Nu vraag ik mij echter af hoe zij dit doen wanneer een gebruiker is ingelogd, wordt er dan voor iedere gebruiker een aparte pagina opgeslagen? Of zijn het slechts tijdelijke bestanden die door PHP gegenereerd worden?

Ik heb op Google meerdere malen gezocht, maar ik heb niets over persoonsgebonden pagina's gezien/kunnen vinden.
edit: en op GoT

Ik hoopte dat jullie mij duidelijk kunnen maken hoe dit in zijn werk gaat?

[Patriot]

Over het algemeen worden serverside alleen paginas gecached die voor alle gebruikers hetzelfde zijn. Als in principe alle pagina's als geheel niet hetzelfde zijn voor iedereen passen ze nog wel eens caching toe op elementen (dus de dingen die wél hetzelfde zijn).

Er zijn verder meerdere niveau's van caching. Je kunt de output letterlijk opslaan, maar je kunt bijv. ook de uitkomst van een relatief zware query tijdelijk opslaan in het geheugen. Wat er toepasselijk is voor jouw situatie hangt allemaal af van wat je precies doet en wat je precies op wilt slaan. Kunnen we wel alle mogelijke vormen van caching gaan benoemen (hint: Dat zijn er héél erg veel), maar daar heb je niet zoveel aan.

[BasieP]

zie ook:
Wikipedia: Web cache

A reverse cache sits in front of one or more Web servers and web applications, accelerating requests from the Internet.

^^ die bedoel jij toch?

[DexterDee]

Er zijn vele soorten serverside caching. Een complete (dynamische en persoonlijke) webpagina cachen is niet haalbaar. Maar zo'n pagina bestaat vrijwel altijd uit gedeelten. Zo heb je misschien in een kolom het weerbericht staan van een bepaalde locatie. Deze verandert niet realtime, dus deze HTML kun je cachen. Bij het opbouwen van de webpagina pak je dan de waarde uit de cache in plaats van elke keer de aanroep te doen naar een backend waar het actuele weer berekend wordt.

Op lager niveau kun je ook cachen. Het renderen van een dynamische website is qua performance vaak vrijwel geheel afhankelijk van een database backend. Een veel toegepast caching mechanisme is het cachen van database queries. In plaats van elke keer terug naar de database te gaan, sla je voor een bepaalde query het resultaat op (in het geheugen) van die query. Als diezelfde query binnen X minuten nog eens uitgevoerd wordt, dan pak je de waarde in het geheugen in plaats van opnieuw de query uit te voeren. De geldigheidsduur kan varieren van 1 seconde tot enkele uren, afhankelijk van hoe vaak de waarden veranderen in de database. In PHP is Memcache vrij populair om data tijdelijk op te slaan. Met memcache als daemon en de PHP extensie kun je een willekeurige blok gegevens opslaan in het geheugen met een voorgedefinieerde geldigheidsduur. Deze gegevens kun je vervolgens terughalen tussen verschillende pagina aanroepen. Op deze manier ontlast je de database server en win je heel veel performance als de website drukbezocht is.

[Gomez12]

Je kan gewoon meerdere lagen van caching hebben.

Van complete pagina's tot per item.

Heb jij een menu wat met 3 query's opgebouwd wordt maar per gebruikersgroep voor 99% gelijk is dan kan het bijv lonen om het menu te cachen terwijl er toch nog een paar variabele inzitten die je ergens anders al nodig had (zie t.net wat bijv het hele menu kan cachen behalve de myreact links etc maar die zijn weer afhankelijk van een userid die toch al opgehaald wordt)

Als je bijv naar de t.net linker(/rechter) tracker kijkt, deze is perfect in blokjes te cachen. Dan kan je alsnog per blokje een afweging maken of je groot wilt cachen (bijv 500 items in cache en je server side taal doet de definitieve filtering) of dat je klein wilt cachen (met 100.000 gebruikers heb je misschien 100 verschillende cache-bestanden, geen 100.000, zo giga-veel combo's tussen bijv fora etc zijn er niet).

Je kan per blokje ook weer andere invalidatie manieren hanteren (je kan bijv de tracker invalidaten per 5 sec, terwijl je bijv active topics invalidate als er een nieuwe post komt)

Let er wel op dat je zo simpel mogelijk cached, caching veroorzaakt extra complexiteit en je schiet er ook niet echt iets mee op als je 3 query's vervangt met 50 cache-checks

[Maxman1850]

Bedankt mannen! Erg informatief!
Maar als er dan een bepaald blok gecached wordt, en die moet ergens in een template geplaatst worden, hoe wordt deze er dan ingeplaatst? Wordt dit mbv javascript gedaan of zijn er ook andere methoden? Het lijkt mij dat er dan nog steeds een stukje PHP te pas komt.. Of is het niet mogelijk om PHP direct volledig achterwege te laten bij een site met gebruikers?

[Bee.nl]

Maxman1850 schreef op donderdag 26 mei 2011 @ 20:47:
Bedankt mannen! Erg informatief!
Maar als er dan een bepaald blok gecached wordt, en die moet ergens in een template geplaatst worden, hoe wordt deze er dan ingeplaatst? Wordt dit mbv javascript gedaan of zijn er ook andere methoden? Het lijkt mij dat er dan nog steeds een stukje PHP te pas komt.. Of is het niet mogelijk om PHP direct volledig achterwege te laten bij een site met gebruikers?

Dat wordt gewoon in de serverside code (PHP) gedaan. De template bevat verschillende placeholders die achteraf ingevuld kunnen worden. Je checkt eerst of het item gecached is. Indien dat zo is dan kun je dit doorgeven aan de placeholder (of template als je wilt). Als het cache-item nog niet bestaat, dan genereer je het item opnieuw in je code.

Javascript zou sowieso geen bruikbare oplossing zijn, omdat je dan (1) mensen zonder javascript buitensluit en (2) meerdere requests naar de server zal moet sturen om alle blokken op te halen, wat juist meer overhead geeft.

[RobIII]

Als je (bijv.!) kijkt op http://memcached.org/ zie je:

code:

function get_foo(foo_id)
    foo = memcached_get("foo:" . foo_id)
    return foo if defined foo

    foo = fetch_foo_from_database(foo_id)
    memcached_set("foo:" . foo_id, foo)
    return foo
end

Dit is (pseudo) code die, in dit geval, memcached gebruikt om cached zaken op te halen; als je door hebt hoe zoiets werkt (en bovenstaande pseudo-code zou je daarbij moeten helpen) is caching niet eens heel moeilijk. Natuurlijk is het niet zo simpel als dit; je zult bijvoorbeeld te maken krijgen met cache-invalidatie (wanneer iemand een "foo" wijzigt bijvoorbeeld en je dus de cached versie ervan wil verwijderen om zo te zorgen dat de volgende keer als iemand de betreffende "foo" ophaalt ook de laatste gegevens krijgt), Cache coherency kan belangrijk zijn bij meerdere caches en zo nog veel meer zaken; ook zul je je per "ding" moeten afvragen of je alleen het object wil cachen of ook (een deel van) de gegenereerde HTML of misschien wel iets heel anders etc. etc. En dan heb je nog keuze uit Disk caches, memory caches, DB caches en whathaveyou en ga zo maar door.


Het is al vaker gezegd; maar het is niet zo simpel als (ik denk dat) je gehoopt had

Let wel; ik haal hier nu "zo even" memcached er bij, maar er zijn 1.001 andere mogelijkheden.

[ Voor 12% gewijzigd door RobIII op 26-05-2011 21:19 ]

[Gomez12]

Hangt er wederom vanaf, wil je tijdens een view de content veranderen (bijv de tracker die zich om de 5 sec ververst) dan is het makkelijk om met JS een nieuw stukje content in te laden.
Wil je het tijdens de view gelijk houden dan kan je het beste via je server-side taal de content inladen (scheelt je een page-request)

Je moet het (in basis) ook niet spannender maken dan het is, meeste caching is gewoon een if-statement die kijkt of er een cache-bestand bestand zoja continue, zonee voer query op dbase uit en sla die op memory/disk op. En net na de if gebruik je de cache om je template te vullen.

En tja, of het mogelijk is om zonder server-side progs een cache bij te houden, dat is mogelijk alleen moet je je afvragen wat het nut is. Server-side caching is bedoeld voor als de server-side progs te vertragend zijn.

Oftewel de basis-theorie achter caching is heel simpel, de praktijk kan je zo gek maken als je zelf wilt.

[Precision]

Zoals eerder al gezegd, je hebt keuze zat hoe je het aanpakt. Je kunt zelfs, maar dit is niet van toepassing voor jou, je php result cachen en laten weergeven zonder dat php er aan te pas kwam op de server waardoor het nog sneller gaat, de server kijkt of bestand blabla.html bestaat en geeft het door. Dit is vooral handig bij blogs, waar de inhoud dezelfde blijft en je de cache laat herbouwen bij een comment. De server laadt een bestand zoals een afbeelding, supersnel

[FragFrog]

Maxman1850 schreef op donderdag 26 mei 2011 @ 20:47:
Wordt dit mbv javascript gedaan of zijn er ook andere methoden?

Kan. Google heeft een tijdje Google Gears ondersteund waarmee je op de PC van de gebruiker data kan opslaan (tegenwoordig kan je hetzelfde met HTML5) en dan kun je inderdaad met JS een deel van de pagina vullen zonder extra request naar de server. Dat is overigens niet Serverside caching maar, je raadt het al, clientside caching

Overigens: als je echt zo weinig van caching afweet kun je er misschien maar beter vanaf blijven. Door de punten die oa RobIII al aanhaalt is het in de praktijk vaak een stuk ingewikkelder dan "even" een variabele in memcache gooien. Het is daarnaast maar zelden nodig - als een webapplicatie traag is kun je in mijn ervaring bijna altijd de boel genoeg versnellen door domweg de applicatie te optimaliseren (overbodige calls weglaten, trage queries herschrijven, dubbele requests voorkomen, trage algoritmes vervangen, etc). Caching is een redmiddel wat je gebruikt wanneer de data echt erg kostbaar is om te genereren of wanneer je niet meer de applicatie zelf kan optimaliseren. Daar zijn wat uitzonderingen op (bepaalde soorten data zijn erg goed cachebaar en kunnen een significante winst opleveren) maar dan moet je ze wel herkennen.

[Gomez12]

^ vergeet daarbij ook niet dat je al een heleboel caching gratis en voor niets krijgt.

Je FS heeft al ingebouwde caching, je DB kan je veelal query's laten cachen als je maar genoeg geheugen toewijst etc. etc. etc.

[Maxman1850]

Bedankt allemaal! Ik ga even alles nog eens rustig doorlezen en de links die gestuurd zijn even bekijken.

Mijn vraag was niet omdat ik het zelf wil gaan toepassen, het was gewoon dat ik me afvroeg hoe het in elkaar stak, door dit te weten snap ik toch weer een stukje beter hoe de 'grote' websites in elkaar zitten.

Toch kan ik heel stiekem wel wat gebruiken wat hier is vernoemd, ik ga meteen mijn javascripts aanpassen!

Edit: @Gomez12 Maar die 'gratis' cache helpen toch niet heel veel om de server minder te belasten? Meer om de gebruiker de pagina sneller weer te geven?

[ Voor 15% gewijzigd door Maxman1850 op 27-05-2011 00:05 ]

[RobIII]

Natuurlijk helpen die caches; en dan heb ik het over L1/2/3 caches op je CPU tot aan Filesystem caches, DNS caches, browser caches en alles er tussenin. Ze verminderen allemaal de belasting op de betreffende systemen; en als resultaat staat je pagina er vlugger, kan je CPU sneller bij z'n gegevens, hoeven de koppen op je HDD's minder meters te maken, zijn er minder netwerkconnecties nodig en ga zo maar door.

[Anoniem: 167624]

Maxman1850 schreef op vrijdag 27 mei 2011 @ 00:03:
Edit: @Gomez12 Maar die 'gratis' cache helpen toch niet heel veel om de server minder te belasten? Meer om de gebruiker de pagina sneller weer te geven?

En hoe denk je dat die gebruiker zijn pagina sneller krijgt? Gebruiker heeft zijn pagina sneller binnen -> de server was eerder klaar met processen van die pagina -> server heeft minder resources gebruikt -> server is minder belast. Hierbij ben ik er voor het gemak maar even vanuit gegaan dat dezelfde resource de bottleneck blijft.

[Cartman!]

Mocht je met PHP bezig zijn, installeer dan APC (opcode cacher), je hoeft verder eigenlijk niks te doen en je hebt direct een enorme winst in performance omdat de opcodes van je code in het geheugen bewaard worden. Goedkope winst

[Gomez12]

Cartman! schreef op vrijdag 27 mei 2011 @ 15:46:
Mocht je met PHP bezig zijn, installeer dan APC (opcode cacher), je hoeft verder eigenlijk niks te doen en je hebt direct een enorme winst in performance omdat de opcodes van je code in het geheugen bewaard worden. Goedkope winst

Onderzoek aub wel eerst even waar de bottlenecks zitten.
Meten is weten...

En als je query's de boel vertragen gaat een APC niets uithalen.

[Voutloos]

Meten is weten is de belangrijkste regel. Pas dan weet je wat het probleem is, en wat de verbetering is.

Opcode cache is wel een beetje de uitzondering, voor alles behalve de meest triviale code is het een hele leuke winst, waar je bovendien slechts een minimale inspanning voor hoeft te doen. Anders gezegd: Het is ronduit belachelijk dat het niet standaard is. Misschien is dat wel om iedereen een lekker gevoel te geven voor zijn eerste serieuze performance verbetering.

[Cartman!]

Met Voutloos, mocht je ergens enigszins te hoeven nadenken over performance dan is APC de meest makkelijke oplossing ervoor. Gratis boost zonder enig onderzoek.

[Freeaqingme]

Anders gezegd: Het is ronduit belachelijk dat het niet standaard is

Sterker nog, met php5.4 wordt het gebruik van APC standaard.

[FragFrog]

Niet helemaal gratis. Ik heb hier een windows 2003 bak staan waarvan Apache 2.2.19 icm PHP 5.3.6 vastloopt na enkele dagen als APC aanstaat. Lijkt een probleem met een threading / locking te zijn ergens. Nu is het een ontwikkelserver dus wellicht niet de meest stabiele omgeving (en ook nog niet de moeite genomen om bijvoorbeeld de threadsafe varianten te proberen), maar mijn vertrouwen in APC is erdoor wel minder. De winst van enkel opcode caching is daarnaast ook relatief weinig - al is de APC datastore dan wel weer nuttig.

[ Voor 9% gewijzigd door FragFrog op 28-05-2011 01:39 ]

[Cartman!]

FragFrog, exacte getallen weet ik niet maar met enkele load tests voor wat projecten die ik gedaan hebt zorgde het installeren van APC voor een boost van 80%. Vastlopers heb ik nooit gehad ermee maar wij hosten ook nooit op Windows, meestal op FreeBSD.

[FragFrog]

Cartman! schreef op zaterdag 28 mei 2011 @ 11:03:
FragFrog, exacte getallen weet ik niet maar met enkele load tests voor wat projecten die ik gedaan hebt zorgde het installeren van APC voor een boost van 80%. Vastlopers heb ik nooit gehad ermee maar wij hosten ook nooit op Windows, meestal op FreeBSD.

Dat zijn realistische usage tests inclusief externe datasources? De meeste webapplicaties die ik heb lopen profilen zijn tussen de 70% en 90% van hun tijd kwijt aan wachten op databases / services etc. Dan helpt het parsen van de PHP source erg weinig, ookal wordt dat vele malen sneller. Dat parsen 80% sneller gaat wil ik dan wel weer geloven

[Cartman!]

Dat was het re-playen van echte userinput incl. calls naar databases ja.

[Slurpie]

Cartman! schreef op zaterdag 28 mei 2011 @ 11:03:
FragFrog, exacte getallen weet ik niet maar met enkele load tests voor wat projecten die ik gedaan hebt zorgde het installeren van APC voor een boost van 80%. Vastlopers heb ik nooit gehad ermee maar wij hosten ook nooit op Windows, meestal op FreeBSD.

Jammer alleen dat APC niet werkt op PHP > 5.2

Maar verder idd een fijne tool om te cachen.

[Cartman!]

3.1.3 - 5.3 support + test-cases (Gopal)

http://pecl.php.net/package-changelog.php?package=APC