[PHP] Cachen van je website, simpel of "complex" ?

[Verwijderd]

Ik ben een applicatie aan het ontwikkelen welke wel eens enige load zou kunnen bezorgen, ik wil dus voor bereid zijn op de toekomst.

Uiteraard wil je bezig zijn met zaken hoe je je site kunt schalen en balancen, echter is dit wel bekend bij mij, ook op applicatie niveau in je code, php en MySQL.

Waar ik me echter wel enige vragen over stel is de cache welke je op je website kunt toepassen. Er zijn verschillende manieren om dit te doen. Gebruik maken van een framework welke dit ondersteunt, memcache, etc.

Aangezien ik mijn eigen framework heb ontwikkeld welke echt zeker de moeite waard is om te gebruiken, zeker omdat je je eigen code kent wil ik eigenlijk ook een decent maar simpele manier van cache gebruiken. Memcache is zeker een optie, zo zijn er wellicht meerdere hoewel je dan snel op een door anderen ontwikkeld framework komt wat ik dus niet wil.

Ik ben bijvoorbeeld het volgende tegen gekomen: http://zedomax.com/blog/2...d-caching-to-any-website/ wat erg simpel en ook logisch lijkt maar de vraag is hoe decent het is.

Zijn er hier ontwikkelaars welke een eigen manier van cachen gebruiken op redelijke schaal ?

Wat ik voornamelijk wil cachen zijn queries welke dan niet meer uitgevoerd hoeven te worden bij iedere pagerequest. Plaatjes kan ook, echter lijkt me een extra domeinnaam voor de max-connecties een betere optie.

[RobIII]

Verwijderd schreef op woensdag 17 november 2010 @ 18:36:
Wat ik voornamelijk wil cachen zijn queries welke dan niet meer uitgevoerd hoeven te worden bij iedere pagerequest. Plaatjes kan ook, echter lijkt me een extra domeinnaam voor de max-connecties een betere optie.

Dat zijn twee heel verschillende dingen en heel verschillende vormen van caching (waarbij de tweede eigenlijk niet eens caching is maar een CDN; met de juiste HTTP headers zou je echter ook een bepaalde mate van caching hebben; ook zonder extra domein). Ik zou me eerst eens verdiepen in wélke vormen van caching je nodig denkt te hebben (als je niet al te vroeg bezig bent met die zaken in the first place). Een memcache is zo opgezet en voor simpele caching is dit in no-time ingebouwd. Ik heb het onlangs nog in een eigen PHP projectje gebruikt en hoewel PHP niet echt mijn ding is had ik er in een handomdraai een laagje voor geschreven dat heel mijn DAL van caching kon voorzien waar ik dat nodig acht.

Ook zou je eens kunnen kijken naar een reverse proxy.

[ Voor 11% gewijzigd door RobIII op 17-11-2010 18:51 ]

[Verwijderd]

Wat ik voornamelijk wil cachen zijn queries welke dan niet meer uitgevoerd hoeven te worden bij iedere pagerequest.

Afhankelijk van welke SQL server en versie je precies gebruikt hoef je je doorgaans daar geen zorgen om te maken. MySQL, als voorbeeld, is met iedere nieuwe versie steeds beter in staat zelf te bepalen hoe en wat te cachen.

Waar je je eerder mee bezig zou moeten houden aan die zijde is het optimaliseren van je queries. Dus, niet achteraf efficient zijn (dmv cache) maar vooraf efficient zijn (snellere, duidelijkere queries, intelligente, robuuste en snelle database opzet).

[GlowMouse]

Verwijderd schreef op woensdag 17 november 2010 @ 18:47:
[...]
Afhankelijk van welke SQL server en versie je precies gebruikt hoef je je doorgaans daar geen zorgen om te maken. MySQL, als voorbeeld, is met iedere nieuwe versie steeds beter in staat zelf te bepalen hoe en wat te cachen.

Wat een onzin, MySQL is bij recente versies niet anders gaan cachen. Query cache is nog steeds even bagger, en overige caches zijn allemaal óf door het OS, óf werken met een LRU-strategie.

Waar je je eerder mee bezig zou moeten houden aan die zijde is het optimaliseren van je queries. Dus, niet achteraf efficient zijn (dmv cache) maar vooraf efficient zijn (snellere, duidelijkere queries, intelligente, robuuste en snelle database opzet).

Dit is wel belangrijk, een cache-miss moet goedkoop zijn. Want de kans is groot dat als net een belangrijk cache-element verouderd is, al je clients opeens dezelfde query uit laten voeren. Je server kan dan alsnog onderuit gaan.

[Verwijderd]

Zelfs gebruik ik, in mij eigen framework, een aantal verschillende lagen van cache voor verschillende onderdelen van het systeem:

1) browser cache; door de juiste headers mee te geven hoeft niet alles bij elke pageview worden opgehaald van de server.
2) SQL short cache; elke keer wanneer er een query wordt uitgevoerd wordt deze tijdelijk opgeslagen in het object, zodat deze maar 1 keer wordt uitgevoerd wanneer deze vaker tijdens een pageview moet worden gedaan.
3) SQL long cache; grote queries zonder snelle verversingstijd (zoals een blog lijst) worden fysiek opgeslagen opgeslagen op de server in json formaat.
4) HTML cache; alle "statische" pagina's worden fysiek opgeslagen op de server en alleen ge-update wanneer er een wijziging wordt gedaan.

Het eerste punt is een kwestie van headers (.htaccess) en is vrij simpel te doen. De overige punten zijn in mijn geval geïntegreerd in mijn framework en daar is vanaf de eerste letter code al rekening mee gehouden. Het bouwen van zo'n cache systeem is niet ingewikkeld, maar moet wel vanaf het begin goed werken.

[Joolee]

Verwijderd schreef op maandag 06 december 2010 @ 16:37:
Zelfs gebruik ik, in mij eigen framework, een aantal verschillende lagen van cache voor verschillende onderdelen van het systeem:

1) browser cache; door de juiste headers mee te geven hoeft niet alles bij elke pageview worden opgehaald van de server.
2) SQL short cache; elke keer wanneer er een query wordt uitgevoerd wordt deze tijdelijk opgeslagen in het object, zodat deze maar 1 keer wordt uitgevoerd wanneer deze vaker tijdens een pageview moet worden gedaan.
3) SQL long cache; grote queries zonder snelle verversingstijd (zoals een blog lijst) worden fysiek opgeslagen opgeslagen op de server in json formaat.
4) HTML cache; alle "statische" pagina's worden fysiek opgeslagen op de server en alleen ge-update wanneer er een wijziging wordt gedaan.

Het eerste punt is een kwestie van headers (.htaccess) en is vrij simpel te doen. De overige punten zijn in mijn geval geïntegreerd in mijn framework en daar is vanaf de eerste letter code al rekening mee gehouden. Het bouwen van zo'n cache systeem is niet ingewikkeld, maar moet wel vanaf het begin goed werken.

Verder kun je nog een extra server met lighthttpd opzetten voor alle statische content (JS, CSS, Afbeeldingen, Flash, Downloads)

[jhu]

Query caching is niet bagger, de wijze waarop de meeste mensen queries schrijven is bagger.

Ik bouw mee aan 40 grote Nederlandse websites en wij krijgen ongeveer 90% terug uit de MySQL memory cache. Daarnaast gebruiken we APC voor dingen die echt zelden veranderen (zoals tablestructuur)

Je moet je queries zo schrijven dat ze langer 'nuttig' blijven, dus niet: "where timestamp > NOW()" want dat verandert iedere seconde. In je script een define opnemen genaamd STR_CUR_MIN die eens per minuut verandert zorgt ervoor dat je dezelfde query 60 keer langer kan cachen.

Ik herschrijf regelmatig queries op basis van onze logging en soms kan het aanpassen van 1 regel code een onwijs complexe query van 350 ms terugbrengen tot 20 ms.

Daarnaast realiseren veel mensen zich niet dat MySQL resultaten alleen in het geheugen verwerkt als er geen BLOB en TEXT (in alle varianten) in zitten. Mensen die "select *" doen wanneer ze het TEXT of BLOB resultaat niet nodig hebben forceren MySQL om dan een zinloze (en trage) disk write operatie te doen met een temporary table.

Als je je bottleneck verwacht in je MySQL dan heeft dat zeker zin om aan te pakken.

Daarnaast zijn er natuurlijk van die simpele dingen als betere caching voor plaatjes, plaatjes serveren van een andere machine (met uitsluitend statische content zonder cookies) en een snellere webserver zoals Nginx ipv Apache.

[Raymond P]

Het cachen van statische content kan prima onder een subdomein.
Koppel het subdomein wel aan een andere box of aan een ander ip op dezelfde box als dat mogelijk is.

Al aangegeven: gebruik de juiste headers voor statische files. Het cachen van css en javascript files kan een pagina veel sneller doen laden.
Als je Apache als webserver gebruikt, gebruik dan geen .htaccess files maar zet je headers in httpd.conf.

Wat betreft MySQL caching: wat jhu zegt.
Kijk eerst naar je queries zelf en gebruik tools zoals MySQL Workbench om je cache hitrate te analyseren en phpmyadmin om de opbouw van je queries zelf te analyseren.

Mocht je niet tevreden zijn met het resultaat, wat zeer waarschijnlijk is:
Je kan MySQL Memory (HEAP) tables gebruiken waar je steken laat vallen of er gewoon niet uit komt.

Memcache is een leuke tool maar wordt helaas vaak gebruikt om slechte queries te verbloemen.

De url die je geeft demonstreert caching op file basis.
Reads en writes van en naar je disks wil je juist vermijden.

[Kalentum]

Probeer zo vroeg mogelijk in het request te cachen. Als je het resultaat van een databasequery cacht, kijk dan ook of je misschien de HTML die daaruit voorkomt kunt cachen. Desnoods cache je slechts wat html snippets van een pagina. Dat scheelt weer een request naar de database. De database cache blijft dan beschikbaar voor meer dynamische onderdelen.

En kies voor cache in memory. Voor PHP is APC een goede keuze. Die kan waarden opslaan en cacht ook PHP code, zodat het niet bij elk request opnieuw gecompileerd hoeft te worden.

[GlowMouse]

Raymond P schreef op donderdag 09 december 2010 @ 18:39:
Mocht je niet tevreden zijn met het resultaat, wat zeer waarschijnlijk is:
Je kan MySQL Memory (HEAP) tables gebruiken waar je steken laat vallen of er gewoon niet uit komt.

Nee, je in MySQL verdiepen helpt dan. Een HEAP tabel helpt niets behalve dat je zeker weet dat de data weg is nadat je de server herstart.

Memcache is een leuke tool maar wordt helaas vaak gebruikt om slechte queries te verbloemen.

[Raymond P]

Nee, je in MySQL verdiepen helpt dan. Een HEAP tabel helpt niets behalve dat je zeker weet dat de data weg is nadat je de server herstart.

Ik bedoel dus een andere manier om queries te cachen.
Als je complexe queries niet goed gecached krijgt helpt het zeker wel om je resultaten weg te schrijven naar een MEMORY table. Dat de data weg is nadat je de server restart is vrij typisch voor elke vorm van memory based caching.
Ook kan je zo op een later moment makkelijk terug komen op je queries en ze eventueel verbeteren totdat je geen MEMORY tables meer nodig hebt, terwijl je ondertussen toch je MYSQL server ontlast.

En ja, memcache wordt heel snel gebruikt om betere performance te halen in plaats van queries zelf te analyseren.
Ik ben het met je eens dat je verdiepen in MySQL the way to go is, maar niet iedereen begint als guru.

[GlowMouse]

Tussen memcached en waar jij een HEAP-tabel voor voorstelt, zitten geen levensgrote verschillen. Trage queries moet je gewoon wegwerken, anders is je db-server bij een cache-miss alsnog de pisang.

[Raymond P]

Relatief aan hoe je data eruit ziet kan er een flink verschil tussen de twee zitten.
Een enkel memcache object kan maximaal 1MB aan data opslaan, kan je geen filters aan meegeven en cross-language uitlezen kan problemen met zich meebrengen.
Met een MEMORY tabel hou je alle MySQL functies beschikbaar en kan je native nog queries op los laten.

Nogmaals, ik zeg dus niet dat het de heilige graal is.
De topic starter vraagt om alternatieve manieren om data te cachen binnen zijn/haar eigen framework.
Ik ben het helemaal met je eens dat alle trage queries weggewerkt moeten worden, mijn punt is dat een query cache hitrate van 90% niet makkelijk te halen is. Zeer zeker niet voor een beginner.
In zo een geval kan het voordelen opleveren om MEMORY tables te gebruiken om MySQL query cache te simuleren, wat in mijn begrippen prima zou passen in zijn/haar bestaande framework.

[styxit]

En dan kan je ook nog naar dingen als Varnish kijken. Die belast je webserver en database helemaal niet.

[Verwijderd]

Zoals t2c hier boven ook zegt, Varnish is echt een geweldig product voor caching.
Beroepsmatig heb ik hier dagelijks mee te maken.

Het mooie in mijn optiek is de schaalbaarheid, je kunt het toepassen voor een simpele wordpress site, maar indien nodig kun je er zonder problemen 1000'en sites achter hangen.

Het is ook niet voor niets dat Facebook, Twitter en eBay gebruik maken van dit prachtige stuk opensource software.

[ Voor 51% gewijzigd door Verwijderd op 18-12-2010 01:21 ]

[ERIKvanPAASSEN]

Misschien zou je eens kunnen kijken hoe zoiets aangepakt wordt door, bijvoorbeeld, Zend_Cache van het Zend Framework. Je kan er vrij simpel van alles mee cachen (o.a. pagina's, functies, objecten) naar bijvoorbeeld files of memcache.

[ Voor 3% gewijzigd door ERIKvanPAASSEN op 18-12-2010 01:29 ]