Toon posts:

[PHP] Serverside caching

Pagina: 1
Acties:

Onderwerpen


  • Maxman1850
  • Registratie: Augustus 2009
  • Niet online
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
  • Registratie: December 2004
  • Laatst online: 06-06 21:05

Patriot

Fulltime #whatpulsert

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
  • Registratie: Oktober 2000
  • Laatst online: 02-08-2021
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?

This message was sent on 100% recyclable electrons.


  • DexterDee
  • Registratie: November 2004
  • Laatst online: 23:20

DexterDee

I doubt, therefore I might be

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.

Klik hier om mij een DM te sturen • 3245 WP op ZW


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 23-07-2021
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
  • Registratie: Augustus 2009
  • Niet online
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
  • Registratie: November 2002
  • Niet online

Bee.nl

zoemt

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
  • Registratie: December 2001
  • Laatst online: 02:24

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

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

code:
1
2
3
4
5
6
7
8
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]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 23-07-2021
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
  • Registratie: November 2006
  • Laatst online: 17-01-2020
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 :)

Crisis? Koop slim op Dagoffer - Op zoek naar een tof cadeau?


  • FragFrog
  • Registratie: September 2001
  • Laatst online: 23:10
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.

[ Site ] [ twitch ] [ jijbuis ]


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 23-07-2021
^ 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.

Acties:
  • 0Henk 'm!

  • Maxman1850
  • Registratie: Augustus 2009
  • Niet online
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]


Acties:
  • 0Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Laatst online: 02:24

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

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.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


Acties:
  • 0Henk 'm!

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.

Acties:
  • 0Henk 'm!

  • Cartman!
  • Registratie: April 2000
  • Niet online
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 :)

Acties:
  • 0Henk 'm!

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 23-07-2021
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.

Acties:
  • 0Henk 'm!

  • Voutloos
  • Registratie: Januari 2002
  • Niet online
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. :+

{signature}


Acties:
  • 0Henk 'm!

  • Cartman!
  • Registratie: April 2000
  • Niet online
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
  • Registratie: April 2006
  • Laatst online: 21:15
Anders gezegd: Het is ronduit belachelijk dat het niet standaard is
Sterker nog, met php5.4 wordt het gebruik van APC standaard.

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.


  • FragFrog
  • Registratie: September 2001
  • Laatst online: 23:10
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]

[ Site ] [ twitch ] [ jijbuis ]


  • Cartman!
  • Registratie: April 2000
  • Niet online
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
  • Registratie: September 2001
  • Laatst online: 23:10
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 :)

[ Site ] [ twitch ] [ jijbuis ]


  • Cartman!
  • Registratie: April 2000
  • Niet online
Dat was het re-playen van echte userinput incl. calls naar databases ja.

Acties:
  • 0Henk 'm!

  • Slurpie
  • Registratie: Oktober 2004
  • Laatst online: 22:28
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.

Acties:
  • 0Henk 'm!

  • Cartman!
  • Registratie: April 2000
  • Niet online
3.1.3 - 5.3 support + test-cases (Gopal)
http://pecl.php.net/package-changelog.php?package=APC
Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee