[ALG] Squid laten cachen van php paginas

[Q]

Hoi,

Momenteel heb ik een testversie van mijn site draaien en tests laten zien dat deze niet meer dan 10 requests per seconde kan afhandelen. Kun je er een php accelerator tegenaan gooien maar bij 15 houdt het dan op.

Hier komt squid in beeld. Dat werkt als een tierelier. Of het klopt of niet, daar ben ik nog niet helemaal uit, maar volgens apachebench kan de machine door caching opeens 600 hits per seconden verwerken.

Toch doe ik iets niet goed. Mijn site bestaat in feite uit 1 enkel bestand: index.php. Door middel van GET requests, zoals index.php?contentwaarde=3 wordt data ingeladen. Cachen van pagina's is daardoor lastig: squid ziet alleen index.php? als bestand en iedere pagina ziet er dus zo uit wat allemaal misses oplevert.

Vraag: hoe zorg ik er voor dat squid iedere pagina als uniek herkent? Kan ik squid de Get request laten herkennen met een handig trucje of moet ik met mod_rewrite aan de slag om van die "nette" urls te maken (zoals GOT heeft)?

[Soultaker]

Ik begrijp je conclusies niet helemaal. Als Squid onterecht pagina's als identiek inschat, dan krijg je toch juist een heleboel (onbedoelde) cache hits? Dat is waarschijnlijk ook de reden dat je resultaten zo goed zijn: je hebt maar 1 pagina die Squid de hele tijd cached. Maar goed, dat terzijde.

Vanuit web accessibility is het zinnig om unieke pagina's ook unieke URL's te geven. Als voor elke 'contentwaarde' in jouw voorbeeld een aparte pagina gegenereerd wordt, maar wel steeds dezelfde, dan is het waarschijnlijk zinnig om URL's te maken van de vorm http://www.Q.nl/content/3. Het voordeel daarvan is dat niet alleen Squid er dan goed mee om gaat, maar ook allerlei andere HTTP agents zoals de Google bot (die geen pagina's met vraagtekens erin indexeert, bijvoorbeeld).

Je kunt dat soort URL's maken met URL rewriting, maar zelf kies ik in niet al te ingewikkelde situaties liever voor Apache's multiviews. Met multiviews wordt voor een request als http://www.Q.nl/content/3 ook content.php uitgevoerd, als die bestaat, of anders index.php (de details van hoe Apache een document bij een URL zoekt zijn wel in de handleiding te vinden). In PHP kun je vervolgens de request URL parsen en aan de hand van de 'argumenten' in de URL je pagina genereren.

Wat ik wel wil benadrukken is dat je er voor moet zorgen dat requests met dezelfde URL ook altijd dezelfde inhoud op moeten leveren. Het WWW is immers gebaseerd op het principe dat een URL een pagina uniek identificeert (en een lokatie aanwijst).

[ Voor 11% gewijzigd door Soultaker op 23-07-2004 18:52 ]

[Q]

Soultaker schreef op 23 juli 2004 @ 18:51:
Ik begrijp je conclusies niet helemaal. Als Squid onterecht pagina's als identiek inschat, dan krijg je toch juist een heleboel (onbedoelde) cache hits? Dat is waarschijnlijk ook de reden dat je resultaten zo goed zijn: je hebt maar 1 pagina die Squid de hele tijd cached. Maar goed, dat terzijde.

Dat klopt, een apachebench resulteert in 1 miss en dan 99 hits. Pak je een andere pagina, precies het zelfde. bezoekers veroorzaken random hits zodat uiteindelijk alleen de plaatjes worden gecached en niet de content. Ik wil dat alles wordt gecached.

Vanuit web accessibility is het zinnig om unieke pagina's ook unieke URL's te geven. Als voor elke 'contentwaarde' in jouw voorbeeld een aparte pagina gegenereerd wordt, maar wel steeds dezelfde, dan is het waarschijnlijk zinnig om URL's te maken van de vorm http://www.Q.nl/content/3. Het voordeel daarvan is dat niet alleen Squid er dan goed mee om gaat, maar ook allerlei andere HTTP agents zoals de Google bot (die geen pagina's met vraagtekens erin indexeert, bijvoorbeeld).

Google lijkt mijn huidige site die met Gets werkt anders prima te indexeren. Volgens mij is dat wat uit het verleden.

Je kunt dat soort URL's maken met URL rewriting, maar zelf kies ik in niet al te ingewikkelde situaties liever voor Apache's multiviews. Met multiviews wordt voor een request als http://www.Q.nl/content/3 ook content.php uitgevoerd, als die bestaat, of anders index.php (de details van hoe Apache een document bij een URL zoekt zijn wel in de handleiding te vinden). In PHP kun je vervolgens de request URL parsen en aan de hand van de 'argumenten' in de URL je pagina genereren.

Ja precies, daar was ik al een beetje mee aan het klooien geweest. Met explode kun je dan die waarden weer gebruiken.

Wat ik wel wil benadrukken is dat je er voor moet zorgen dat requests met dezelfde URL ook altijd dezelfde inhoud op moeten leveren. Het WWW is immers gebaseerd op het principe dat een URL een pagina uniek identificeert (en een lokatie aanwijst).

[/q]

Dat is wel de bedoeling ja. Ik vroeg mij alleen af of dat het soort urls dat jij als voorbeeld geeft ook nodig is voor Squid. Ik begrijp dat als je squid wil laten werken je dus wel moet en niet met get-requests kan werken.

[ Voor 3% gewijzigd door Q op 23-07-2004 19:32 ]

[Soultaker]

Ik weet niet zeker dat het niet mogelijk is om Squid anders te configureren. In een extreem geval zou je je caching headers zo aan kunnen passen dat Squid helemaal niet cached, maar dan ben je ook de mogelijke voordelen kwijt. Ik wilde alleen maar even suggereren dat het misschien sowieso beter was om 'nette' URL's te generen en en passent het probleem met Squid op te lossen. Misschien kan iemand anders nog een andere, directere methode suggereren.

Overigens is dit misschien wat te veel gevraagd:

Q schreef op 23 juli 2004 @ 19:32:
bezoekers veroorzaken random hits zodat uiteindelijk alleen de plaatjes worden gecached en niet de content. Ik wil dat alles wordt gecached.

Hoewel je er in principe best van uit kunt gaan dat Squid redelijk goed kan beslissen welke documenten het beste gecached kunnen worden gegeven de beschikbare ruimte en de frequentie waarmee documenten opgevraagd wordt, kun je dit proces een beetje sturen door alleen de PHP pagina's via Squid te laten lopen en alle statische bestanden buiten de proxy om te laten gaan.

Aangezien je de proxy lokaal draait om de overhead van PHP uit te sparen, is het waarschijnlijk geen enkel probleem om statische documenten direct door de webserver te laten serven (die worden dan net zo efficiënt geladen omdat ze toch niet dynamisch gegenereerd worden). Door alleen de PHP pagina's via de proxy te sturen voorkom je dat de proxy cache volloopt met plaatjes terwijl je juist de PHP pagina's wilde cachen.

[Verwijderd]

Je kan squid toch zo configuren dat ie url's met bv een ? moet negeren (is trouwens de std instelling bij apt-get op debian).

[Soultaker]

Verwijderd schreef op 24 juli 2004 @ 03:01:
Je kan squid toch zo configuren dat ie url's met bv een ? moet negeren (is trouwens de std instelling bij apt-get op debian).

Maar dan cache je dus ook niets. Dan kun je net zo goed geen proxy draaien, lijkt me?

Ik neem trouwens aan dat als je het kan configureren, dat ook wel na de compilatie (dus ergens in een configuratiebestand, hopelijk per (sub)domein) kan.

[Verwijderd]

Soultaker schreef op 24 juli 2004 @ 03:07:
[...]

Maar dan cache je dus ook niets. Dan kun je net zo goed geen proxy draaien, lijkt me?

Ik neem trouwens aan dat als je het kan configureren, dat ook wel na de compilatie (dus ergens in een configuratiebestand, hopelijk per (sub)domein) kan.

niet de content die gegeneerd wordt, maar wel eventuele plaatsjes etc., die staan vaak weer met een directe url in de content.

Ja, je kan dit gewoon in squid.conf instellen.

(oeps, lees je TS nog eens, je wilt squid als serverproxy gebruiken, niet als client proxy, maar het principe blijft hetzelfde, je dynamische pagina's kan en wil je niet cachen, anders weet je nooit wanneer je een update daadwerkelijk naar buiten gooit).

[ Voor 28% gewijzigd door Verwijderd op 24-07-2004 03:15 ]

[Soultaker]

Statische documenten kan de gemiddelde webserver zelf net zo goed serven als de gemiddelde HTTP proxy. Ik neem aan dat het gaat juist om de dynamische gegenereerde pagina's, aangezien je je de overhead van PHP kunt besparen als je ze uit de cache servet in plaats van ze opnieuw te genereren.

[Verwijderd]

Soultaker schreef op 24 juli 2004 @ 03:16:
Statische documenten kan de gemiddelde webserver zelf net zo goed serven als de gemiddelde HTTP proxy. Ik neem aan dat het gaat juist om de dynamische gegenereerde pagina's, aangezien je je de overhead van PHP kunt besparen als je ze uit de cache servet in plaats van ze opnieuw te genereren.

En hoe weet de proxy dan dat er data in bv de database waaruit de content wordt gehaald is veranderd ?? of kijk je alleen naar TTL van pages (bv iedere dag verversen) ?, zoja dan is de website maar semi-dynamisch

[ Voor 13% gewijzigd door Verwijderd op 24-07-2004 03:22 ]

[Coen Rosdorff]

In het kader van probleem aanpakken bij de bron:
Zorg er voor dat je site meer dan 15 requests kan verwerken. Als je wil cachen met squid dan zijn de pagina's schijnbaar niet al te dynamisch. Je kan dan gewoon gedeeltes of hele pagina's cachen op je webserver.

[Soultaker]

Als de bottleneck 10 requests per second is, is die semi-dynamische oplossing al voldoende. Als je dan elke 15 minuten een nieuwe pagina genereert spaar je immers tot aan 9000 requests uit, terwijl pagina's maximaal 15 minuten 'outdated' zijn (wat heel acceptabel is wanneer je pagina's niet vaak bijwerkt).

In de praktijk kan het natuurlijk veel beter: als je Squid vertelt dat documenten altijd gevalideerd moeten worden, dan doet squid voor elke request van de client een request op de server met een If-Modified-Since header ingesteld op de datum van het gecachede document. Je kunt dan PHP code bepalen of de pagina wel of niet is bijgewerkt en als 'ie niet is bijgewerkt hoef je hem ook niet te genereren. Op die manier moet PHP nog wel voor elke request in actie komen, maar kan het werk in veel gevallen erg beperkt blijven terwijl je toch altijd de meest recente documenten servet.

[Q]

Dank voor de reacties.

Ik geef nu een header() mee in mijn index.php die een bepaalde "timetolive" aan het document geeft. Mijn site is daardoor nog wel dynamisch, alleen met een vertraging van x minuten/uren, af hankelijk van de instelling. Nu wordt mijn site weinig bijgewerkt. Hooguit 1x a 2x per week dus caching zal enorm helpen.

Dit is al een aardige hulp:

http://www.theukwebdesign.../articles/php-caching.php

Maar dat squid leek mij zo makkelijk en het lijkt extreem goed te presteren volgens ab.

Ik ga mij verdiepen in nettere urls. Dat is sowieso wel mooi en dan is mijn squid probleem opgelost.