[PHP/MySQL]Cache sql-output wel of niet

[Verwijderd]

Een aantal jaren geleden (bijna 4 jaar) toen ik net begonnen was met PHP en MySQL heb ik een website gemaakt die inmiddels zo'n 2000 tot 2500 pageviews per dag heeft.
Omdat tijdens het ontwikkelen al rekening mee gehouden werd dat de site goed bezocht zou worden heb ik een soort cache-systeempje ontwikkeld.
In het kort komt het hierop neer:
Alle content zit in tabellen, de beheerders werken rechtstreeks in de tabellen en als ze klaar zijn genereren ze een tekstbestand waarin de output van de tabellen instaat.
Deze tekstbestanden worden via een include aan de bezoekers getoond.

Nu gaan we de site opnieuw ontwikkelen. De lay-out wordt aangepakt en ook de structuur.
Nu vraag ik me af of het zin heeft om het cache-systeem te laten bestaan of dat het net zo goed rechtstreeks uit de database kan worden gehaald.
Met rechtstreeks bedoel ik dan dat voor elke pageview de SQL naar de database wordt gestuurd en de content wordt opgehaald.

Mijn vraag is dan ook:
Wat is de kritische grens in aantal pageviews waarbij het zinvoller (sneller) is om met een cache-systeem te werken dan om steeds de content uit de database te halen.

Alvast bedankt voor het meedenken.

Paul

[Michali]

Hoe werkt dat cache systeem dan? Wordt voor iedere pagina zo'n tekstbestand gegenereerd of is dat 1 grote file waar de complete db in staat? In het laatste geval lijkt me dat niet echt sneller werken dan gewoon de juiste data selecteren en ophalen. Je zou ook de db als cache mechanisme kunnen gebruiken. Alle gerenderde HTML sla je daar dan in op en in het geval van gewijzigde content kun je dat dan invalideren zodat het opnieuw gevuld wordt bij de eerst volgende request. Echter kun je dan bij het renderen bepaalde dynamiek niet meenemen, zoals het verwerken van de huidige datum/tijd oid. Dat moet je dan op een andere manier oplossen.

[Verwijderd]

Voor elke pagina wordt zo'n tekstbestandje gegenereerd en daar staat eigenlijk alleen maar HTML in en bestaat vaak uit enkele records uit een tabel.
Als ik de db als cache mechanisme gebruik dan doe ik dan toch hetzelfde als dat ik rechtstreeks de tabellen bevraag? Het verbinden met de db is toch het duurst (in termen van geheugengebruik, bandbreedte ed.)?
Om te verduidelijken dat het maar om eenvoudige queries gaat, hier een voorbeeld query:

code:

select content 
from tableX 
where menuID=3 and zichtbaar=true 
order by volgorde

Zoals je ziet is het allemaal erg basic.
In mijn nieuwe sites haal ik elke pagina steeds uit de database, maar daar komen maar 10 tot 20 bezoekers per dag.
Het gaat mij dus vooral om de performance. Heeft het zin om de tekstbestanden te genereren of is dat pas zinvol bij meer dan 100.000 pageviews per dag?

[huiz]

Termen als duur ivm geheugengebruik en bandbreedte lijken me aardig irrelevant. Een beetje server is er wel op ingericht om een paar queries aan te kunnen en bandbreedte is alleen maar wat je vanaf de server naar de browser stuurt, niet wat de server intussen allemaal in zijn geheugen plempt of aan tijdelijke bestanden maakt.

Een dag telt 86400 seconden, stel dat in een redelijk omvangrijke website een pagina wordt samengesteld binnen 0.1 seconde incl het ophalen van de data uit de database, dan kun je (verdeeld over de hele dag dan) 864000 pagina's per dag genereren als de server als alles achter elkaar moet afhandelen en geen meerdere database connecties of http requests aankan (in theorie).

2000 tot 2500 pageviews per dag is echt geen probleem.

[megamuch]

ik draai op een pIII 1200 met 512 mb ram een site met 2000 / 2500 unique (13000 impressions p dag) en ik trek alles nog gewoon zonder cache uit de db.

Belasting is vaak niet hoger dan 20/30%

Ook misbruik ik die machine nog als adserver voor andere sites en voor hele vieze dingen als imgconverter. Dus cache heeft weinig zin bij dergelijke aantallen aanbezoek.

[kmf]

huiz schreef op zaterdag 11 maart 2006 @ 00:04:
Termen als duur ivm geheugengebruik en bandbreedte lijken me aardig irrelevant. Een beetje server is er wel op ingericht om een paar queries aan te kunnen en bandbreedte is alleen maar wat je vanaf de server naar de browser stuurt, niet wat de server intussen allemaal in zijn geheugen plempt of aan tijdelijke bestanden maakt.

Een dag telt 86400 seconden, stel dat in een redelijk omvangrijke website een pagina wordt samengesteld binnen 0.1 seconde incl het ophalen van de data uit de database, dan kun je (verdeeld over de hele dag dan) 864000 pagina's per dag genereren als de server als alles achter elkaar moet afhandelen en geen meerdere database connecties of http requests aankan (in theorie).

2000 tot 2500 pageviews per dag is echt geen probleem.

En wat als die 2500 pageviews een half jaar later 5000 wordt, en een jaar later 10000? Gewoon een nieuwe server aanschaffen?

En wat als je met een cachesysteem in plaats van 0,1 seconde parsen 0,001 seconde nodig hebt om een cachebestand op te vragen?

Dan kies ik nog steeds liever voor het investeren in een cachesysteem.

Ik had een jaar geleden een cachesysteem voor de portal van mijn website gemaakt. Dit betekende een pagina op het scherm binnen 1 seconde in plaats van 5. Voor de gebruiker is deze snelheid heel prettig en zeker ook voor de server, die zo'n 20% minder werk hoeft te verrichten.
Ik heb dan wel 1,5 miljoen pageviews per dag.
Helaas heb ik door een upgrade in hardware en software de cachesysteem niet meer in gebruik, maar ik ben wel van plan deze opnieuw op te zetten

Toen ik die cachesysteem bouwde ging ik van de verhouding 1 update: 60 selects/ minuut. Oftewel, als ik meer dan 60 selects heb, en slechts 1 update in 1 minuut, dan vind ik het waard om de cache te maken.

[pietje63]

Ik heb een beetje een gerelateerde vraag (die misschien toch ook weer heel anders is.. dan moet je deze reply maar gewoon even negeren).

Ik ben momenteel bezig met een nieuwe versie van een online smoelenboek. Daarvoor staat verschillende data in totaal iets van 15 tabellen (er zijn zoveel tabellen nodig doordat het orgineel in access staat). Als snelheids-optie raadde de persoon die de access tabellen heeft gemaakt mij aan om views te gebruiken.

Ik had hier nooit eeder van gehoord en ging dus even op zoek en kwam hier op uit: http://dev.mysql.com/doc/refman/5.0/en/views.html. Weet iemand of dit qua snelheid ook echt kan schelen, of heb je dit niet nodig als de php goed geschreven is?

[Peter]

Of je een cachesysteem nodig hebt of niet, dat heeft puur te maken met de codingstijl en optimalisatie. Een van mijn sites heeft circa 35,000 hits per dag, parsetimes blijven onder de 0,1 seconde ondanks dat het vrij MySQL-intensief is. Als je site langzaam wordt, zoek dan eerst iemand die je code eventueel kan optimaliseren

[Gomez12]

Voor wel / niet caching van sites hanteer ik altijd een aantal basisprincipes.
0 : Trekt de pagina veel gebruikers ( en dan bedoel ik niet 2000 maar maar iets in de trant van 20.000 per dag )
1 : Is het een gedeelte wat vaak geupdate wordt ( minder dan 1x per 5 minuten dan cachen, anders is je server meer bezig met het bijhouden van de cache dan als je het rechtstreeks naar de db liet lopen )
2 : Cache nooit in html, alleen maar data ( want dan kan je diezelfde cache weer ergens anders voor gebruiken, bijv je cached de laatste 50 topics, nu wil je ergens alleen de laatste 5 topics tonen, dan kan je gewoon de 1e 5 regels uit je cache lezen )
3 : Bedenk goed of je simpele select querys als hierboven wel wilt cachen, ga alleen de moeilijkere querys cachen.

[Johnny]

Sinds Mysql 4 worden queries toch al automatisch gecached?

[Verwijderd]

Allemaal erg bedankt.

Ik had al een beetje het vermoeden dat het cachen voor mijn (toch wel kleine) site niet echt nodig is.
Ik zal dan nu geen cachesysteem inbouwen, goed naar mijn code kijken en die zo geoptimaliseerd mogelijk te houden.
Wel ga ik er rekening mee proberen te houden dat als mijn site ineens heel erg goed bezocht gaat worden (je weet maar nooit ) een cachesysteem relatief eenvoudig toegevoegt kan worden.

--
Paul