[Topix] Waarom zo'n zware serverbelasting. terwijl

[Verwijderd]

Oke, voor Topix maakt het niet meer uit, maar een algemene vraag dan over dynamische sites:

Waarom wordt er nergens gebruik gemaakt van cached Templates en de '304 Not Modified' header? Dit bespaard in het eerste geval een hoop db-server load en in het tweeede geval ook een hoop webserver load.

In het geval van cached Templates worden de gegenereerde PHP-pagina's opgeslagen als static html op de harddisk van de server. Deze statische pagina wordt geserveerd aan de clients. Als er een pagina veranderd wordt, wordt de opgeslagen variant gerefreshed.

Tegenwoordige webservers en browsers (Apache/1.3, Netscape Navigator 4.x and above, Internet Explorer) hebben allemaal support voor de 304 header. Ze sturen bij elk request een If-MODIFIED-SINCE mee, je kunt hier gebruik van maken in je code zodat als de data ook daadwerkelijk niet is veranderd (dat kun je zien bij forums aan bijvoorbeeld de lastposttime) je ipv data een 304 header terug stuurt.

Wordt hier gewoon niet over nagedacht bij het bouwen van een (heavy-load) forum, of heeft het toch te grote nadelen.

[D2k]

mayb niet algemeen bekend?

bij mij niet iig maar caching in het algemeen lijkt mij een bijzonder goed id. Dus niet alleen voor forums maar vooral ook voor "gewone" sites met veel load en content die dynamisch is maar niet al te frequent wordt gewijzigd


* D2k gaat er iig een over nadenken

<edit>
waarom verwacht ik hier een "preek" van onze XML-guru mbravenboer
</edit>

[Verwijderd]

Op woensdag 05 december 2001 09:33 schreef D2k het volgende:
mayb niet algemeen bekend?

bij mij niet iig maar caching in het algemeen lijkt mij een bijzonder goed id. Dus niet alleen voor forums maar vooral ook voor "gewone" sites met veel load en content die dynamisch is maar niet al te frequent wordt gewijzigd


* D2k gaat er iig een over nadenken

HappyFun zou er idd baat bij hebben als ze wat groter worden. (was er tzt al mee bezig )
Enige nadeel wat ik me kan bedenken zijn de banners, die veranderen nl. steeds...
Dus dan krijg je een inkomstendaling tegenover een lagere load.

[Janoz]

Op woensdag 05 december 2001 09:58 schreef trebel het volgende:

[..]

HappyFun zou er idd baat bij hebben als ze wat groter worden. (was er tzt al mee bezig )
Enige nadeel wat ik me kan bedenken zijn de banners, die veranderen nl. steeds...
Dus dan krijg je een inkomstendaling tegenover een lagere load.

mwah.. Als je alles behalve de banners cached ben je ook al een heel eind hoor

[ACM]

Op woensdag 05 december 2001 09:30 schreef trebel het volgende:
Wordt hier gewoon niet over nagedacht bij het bouwen van een (heavy-load) forum, of heeft het toch te grote nadelen.

Ik gok op het eerste, maar de grootste bottleneck is niet het "aantal" bezoekers, maar wat die bezoekers bekijken...

Vooral de searchengine is erg zwaar, voor de DB.

De webserver zelf heeft vrij weinig te doen eigenlijk.

[ACM]

Op woensdag 05 december 2001 09:59 schreef Janoz het volgende:
mwah.. Als je alles behalve de banners cached ben je ook al een heel eind hoor

De gegenereerde HTML voor de banners is wel op elke page onveranderlijk (misschien niet op elke page hetzelfde, maar wel per page hetzelfde), tenminste dat is hier op GoT zo.

[Verwijderd]

Op woensdag 05 december 2001 10:00 schreef ACM het volgende:
Vooral de searchengine is erg zwaar, voor de DB.

Dat zal zeker, dat is ook bijna niet te cachen...
Maar de rest zou misschien voor een dusdanige verlaging kunnen zorgen dat een zware searchengine wel haalbaar is.

[ACM]

Op woensdag 05 december 2001 10:03 schreef trebel het volgende:
Dat zal zeker, dat is ook bijna niet te cachen...
Maar de rest zou misschien voor een dusdanige verlaging kunnen zorgen dat een zware searchengine wel haalbaar is.

Dat zou kunnen, maar kan ik helaas niet testen, een nadeel wat je wellicht vergeet is dat alsnog elke page-request een stel lookup's in de DB moet doen (ook de authenticatie etc etc) dus dat je vooral op het gebied van de webserver de boel verlicht.

[Verwijderd]

Op woensdag 05 december 2001 10:01 schreef ACM het volgende:

[..]

De gegenereerde HTML voor de banners is wel op elke page onveranderlijk (misschien niet op elke page hetzelfde, maar wel per page hetzelfde), tenminste dat is hier op GoT zo.

Dat zou ook niet uitmaken:
Als je bij een 304 header NOT-MODIFIED teruggeeft, heb je dus geen banner-view en automatisch ook geen banner-click, want je verstuurd geen nieuwe data, de site wordt uit de cache van de browser/proxy gehaald.
Bij cached templates zou het wel kunnen, als de html idd hetzelfde blijft, maar alleen de image er anders uitziet

[HGM]

Dit is wel een aardige link: http://jpcache.com/

[D2k]

Op woensdag 05 december 2001 09:58 schreef trebel het volgende:

[..]

HappyFun zou er idd baat bij hebben als ze wat groter worden. (was er tzt al mee bezig )
Enige nadeel wat ik me kan bedenken zijn de banners, die veranderen nl. steeds...
Dus dan krijg je een inkomstendaling tegenover een lagere load.

HF zou eigenlijk alweer herschreven moeten worden
(ut was mijn eerste echt "grote" site)

maar idd als ie herschreven wordt zal ik zeker wel naar caching kijken

[Funcracker]

Op woensdag 05 december 2001 10:07 schreef D2k het volgende:

[..]

HF zou eigenlijk alweer herschreven moeten worden
(ut was mijn eerste echt "grote" site)

maar idd als ie herschreven wordt zal ik zeker wel naar caching kijken

Goh.. dat heb ik eerder gehoord..


Maar ik denk dat het aan de onbekendheid ermee ligt Trebel.
Mensen kijken niet veel verder dan hun neus lang is in de meeste gevallen..

[raptorix]

Op woensdag 05 december 2001 10:04 schreef ACM het volgende:

[..]

Dat zou kunnen, maar kan ik helaas niet testen, een nadeel wat je wellicht vergeet is dat alsnog elke page-request een stel lookup's in de DB moet doen (ook de authenticatie etc etc) dus dat je vooral op het gebied van de webserver de boel verlicht.

Niet mee eens, je kan een sessie zetten die buiten de db om werkt, vervolgens kan je een gecachede pagina gewoon aanroepen, dit betekent 0,0 database werk, voor de sites die wij maken cachen we 95% van de pagina's .

Als je goede caching componenten gebruikt kan je zelfs vrijwel je hele site uit het geheugen serveren, en dat is natuurlijk wat je echt wilt, ok met een forum is dat onhaalbaar maar je kan zeker een site als tweakers.net heel goed cachen.

[Crazy D]

Maar moet je dan niet per pagina (t.net even als voorbeeld nemend) 4 of 5 html pagina's opslaan? "View vanaf -1, vanaf 0, etc). En op GoT is dat helemaal lastig, zit je weer met het aantal per pagina...
(xml comes to mind? )

[Verwijderd]

Op woensdag 05 december 2001 10:25 schreef Crazy_D het volgende:
Maar moet je dan niet per pagina (t.net even als voorbeeld nemend) 4 of 5 html pagina's opslaan? "View vanaf -1, vanaf 0, etc). En op GoT is dat helemaal lastig, zit je weer met het aantal per pagina...
(xml comes to mind? )

yup, daar zit je mee...

[jvdmeer]

Op woensdag 05 december 2001 10:18 schreef raptorix het volgende:
maar je kan zeker een site als tweakers.net heel goed cachen.

Alleen met de frontpage lukt dat, alle artikelen worden geserved met eigen instellingen van de gebruiker. Met wel/geen nesting, wel/geen moderatie, nveau 0/1/2, enz. Dus er is te veel varatie voor caching.

* jvdmeer praat nu waarschijnlijk voor zijn beurt en had Femme of Arjan dit moeten laten typen.

[Verwijderd]

Op woensdag 05 december 2001 10:38 schreef jvdmeer het volgende:

[..]

Alleen met de frontpage lukt dat, alle artikelen worden geserved met eigen instellingen van de gebruiker. Met wel/geen nesting, wel/geen moderatie, nveau 0/1/2, enz. Dus er is te veel varatie voor caching.

Maar zelfs dan kan een 304 header aardig wat load weghalen.

Ik heb dit topic bijvoorbeeld al tich keer gereload om te kijken of er nieuwe reactie was. Met een 304 header had dat dus ook al tich keer een webserver en database opvraag gescheeld.

[Rense Klinkenberg]

Op woensdag 05 december 2001 10:38 schreef jvdmeer het volgende:

[..]

Alleen met de frontpage lukt dat, alle artikelen worden geserved met eigen instellingen van de gebruiker. Met wel/geen nesting, wel/geen moderatie, nveau 0/1/2, enz. Dus er is te veel varatie voor caching.

* jvdmeer praat nu waarschijnlijk voor zijn beurt en had Femme of Arjan dit moeten laten typen.

XML komt nu zeker in mijn hoofd naar boven borrelen. Ik heb laatst al probeersel al eens nested reactions gemaakt met een xml input die direct uit de database kan worden gehaald en die werkte perfect.

Maar over het oorspronkelijke idee: Naar wat ik weet werkt UBB ook op zo'n manier, maar dat bleek niet stabiel genoeg voor GoT.

[Verwijderd]

Op woensdag 05 december 2001 11:10 schreef freak007 het volgende:
Maar over het oorspronkelijke idee: Naar wat ik weet werkt UBB ook op zo'n manier, maar dat bleek niet stabiel genoeg voor GoT.

met headers of cached templates?
m.a.w. server of client side caching

[edit] domme typo

[jvdmeer]

Op woensdag 05 december 2001 10:42 schreef trebel het volgende:
Ik heb dit topic bijvoorbeeld al tich keer gereload om te kijken of er nieuwe reactie was. Met een 304 header had dat dus ook al tich keer een webserver en database opvraag gescheeld.

Daarvoor kan de hoster toch ook een reversed proxy neerzetten? Zelfde resultaat. Dedicated, en geen aanpassingen aan de applicatie nodig. nog makkelijker.

[Verwijderd]

Op woensdag 05 december 2001 13:45 schreef jvdmeer het volgende:

[..]

Daarvoor kan de hoster toch ook een reversed proxy neerzetten? Zelfde resultaat. Dedicated, en geen aanpassingen aan de applicatie nodig. nog makkelijker.

Je zou inderdaad een soort proxy wrapper voor je webservertje kunnen hangen die nagaat of er dingen veranderen (timestamps, etc) en als er dingen veranderen een request doet naar de server om zijn cache te vernieuwen, en anders de statische HTML in zijn cache uitserveren. Voor banners moet je dan denken aan CGI scripts die niet onder deze proxy vallen...

Dat zou een klein verschil kunnen uitmaken in de load die je genereerd dmv van de dynamiek. Des al niet te min denk ik dat je in het geval van een aantal 'concurrent' users dit soort oplossingen niet moet proberen, omdat je dan moet gaan denken aan een threading proxy, die aan alle kanten moet checken wie wat doet, wat de load weer kunstmatig hoog houd... Dan kan je beter vertrouwen op je webserver ...

[brammetje]

Op woensdag 05 december 2001 10:38 schreef jvdmeer het volgende:
Alleen met de frontpage lukt dat, alle artikelen worden geserved met eigen instellingen van de gebruiker. Met wel/geen nesting, wel/geen moderatie, nveau 0/1/2, enz. Dus er is te veel varatie voor caching.

* jvdmeer praat nu waarschijnlijk voor zijn beurt en had Femme of Arjan dit moeten laten typen.

Dan zou je dus leuk XML-documenten kunnen cachen. Je hoeft de database niet meer aan te spreken, je transformeert alleen elke keer de xml. Dat is veel minder zwaar voor zo'n servertje..

[Verwijderd]

kwam zojuist op phpBuilder.com een article hierover tegen.

Making PHP Applications Cache-Friendly

[LuCarD]

Voor de bannerviews moet het niet uit maken aangezien de banners in een IFRAME staan, waardoor er een nwe request wordt gedaan bij de server van WEBADS. En die kan gewoon andere headers terug sturen ....

IMHO

[kvdveer]

Op woensdag 05 december 2001 14:42 schreef LuCarD het volgende:
Voor de bannerviews moet het niet uit maken aangezien de banners in een IFRAME staan, waardoor er een nwe request wordt gedaan bij de server van WEBADS. En die kan gewoon andere headers terug sturen ....

IMHO

my thoughts exactly...

En caching is op een forum al helemaal eenvoudig: je vraagt de laatste datum op in een zeer eenvoudige query:

SELECT max(edit_datum) FROM postings WHERE topic="/341274" GROUP BY forumId;

edit:
group by clause vergeten

[Verwijderd]

Op woensdag 05 december 2001 15:57 schreef kvdveer het volgende:
En caching is op een forum al helemaal eenvoudig: je vraagt de laatste datum op in een zeer eenvoudige query:

SELECT max(edit_datum) FROM postings WHERE topic="/341274" GROUP BY forumId;

Op goed bezochtte forums slaat men meestal de lasposttime op in de database zodat je ipv een select max() gewoon select lastposttime kunt doen.

Een select kost nl. minder recources dan telkens een count.

oftwel, nog makkelijker om een header te sturen, is een select en een if..

PHP:

<?
$lastposttime = $sql->QueryItem("SELECT lastposttime FROM forums WHERE forum_id = $id");
if ($HTTP_IF_MODIFIED_SINCE >= $lastposttime) {
    header("HTTP/1.1 304 Not Modified");
    exit;
}
else {
    header("Last-Modified: ".$lasposttime);
}
?>

[edit] voorbeeldje toegevoegd

[Verwijderd]

In het geval van cached Templates worden de gegenereerde PHP-pagina's opgeslagen als static html op de harddisk van de server. Deze statische pagina wordt geserveerd aan de clients. Als er een pagina veranderd wordt, wordt de opgeslagen variant gerefreshed.

Als je nu bv een lekker goed lopend forumpje hebt, over de 1 miljoen threads, over de 25 x 1 miljoen posts ofzo ... Bouw daar maar eens allemaal een cached versie van (excl design ofzo) en include deze tekst.. Das al genoeg html shit, dan nog de db er bij, dan nog je mysql + besturings systeem + porst + appies... vreet je space man...

[brammetje]

Op woensdag 05 december 2001 17:01 schreef GDOG het volgende:

[..]

Als je nu bv een lekker goed lopend forumpje hebt, over de 1 miljoen threads, over de 25 x 1 miljoen posts ofzo ... Bouw daar maar eens allemaal een cached versie van (excl design ofzo) en include deze tekst.. Das al genoeg html shit, dan nog de db er bij, dan nog je mysql + besturings systeem + porst + appies... vreet je space man...

och, er hangen best wel wat leuke schijfjes in de servers van t.net, die trekken dat wel..

[raptorix]

Op woensdag 05 december 2001 10:38 schreef jvdmeer het volgende:

[..]

Alleen met de frontpage lukt dat, alle artikelen worden geserved met eigen instellingen van de gebruiker. Met wel/geen nesting, wel/geen moderatie, nveau 0/1/2, enz. Dus er is te veel varatie voor caching.

* jvdmeer praat nu waarschijnlijk voor zijn beurt en had Femme of Arjan dit moeten laten typen.

Dan zou je daar misschien concessies moeten doen.

[Verwijderd]

Op woensdag 05 december 2001 17:12 schreef PlayR het volgende:

[..]

och, er hangen best wel wat leuke schijfjes in de servers van t.net, die trekken dat wel..

idd, hd-space is makkelijker in te voorzien dan in de continu groeiende load op de db-servers.
De search moet nu af en toe uit omdat het niet getrokken wordt.

[Verwijderd]

maar wat vinden de T.net-dev's eigenlijk van caching?

[Verwijderd]

Op woensdag 05 december 2001 17:51 schreef trebel het volgende:
maar wat vinden de T.net-dev's eigenlijk van caching?

Ze cachen een aantal dingen (active topics, dat overzicht links op elke pagina van T.net geloof ik) verder schijnen de pagina's (met name op het forum) zo dynamisch te zijn dat cachen niks oplevert (zoek maar eens in LA daar staan hier wel topics over).

[ACM]

Op woensdag 05 december 2001 10:18 schreef raptorix het volgende:
Niet mee eens, je kan een sessie zetten die buiten de db om werkt, vervolgens kan je een gecachede pagina gewoon aanroepen, dit betekent 0,0 database werk, voor de sites die wij maken cachen we 95% van de pagina's .

En hoe wilde je dat met loadbalancing doen? (ok, er zijn application servers die dat kunnen loadbalancen via een eigen netwerksharing van dat soort data, maar daar doet apache niet aan).

Als je goede caching componenten gebruikt kan je zelfs vrijwel je hele site uit het geheugen serveren, en dat is natuurlijk wat je echt wilt, ok met een forum is dat onhaalbaar maar je kan zeker een site als tweakers.net heel goed cachen.

Klopt, maar dan wordt een deel van t.net FP ook al gecached...

[ACM]

Op woensdag 05 december 2001 17:54 schreef Zef het volgende:
Ze cachen een aantal dingen (active topics, dat overzicht links op elke pagina van T.net geloof ik)

De frontpage zelf wordt ook elke minuut opnieuw gegenereerd.