[ALG] Content buffering/caching

[supakeen]

Inleiding
Ik weet niet precies wat de goede term hiervoor is maar ik zal het eerst even allemaal uitleggen. Ik wil (delen) van een site zo maken dat ze niet constant zodra een bezoeker daarom vraagt uit de database worden getrokken (site is daarvoor niet dynamisch genoeg en ik wil dit ook eens uitproberen). Wat ik dus wil is elke nacht om 4 uur (voorbeeld tijd ) mijn HTML laten opbouwen uit bestanden die dan worden gegenereerd uit de database.

Wat ik zelf heb bedacht
Zelf dacht ik dit te doen door middel van het aanmaken van een XML sheet om 4 uur s'nachts en vervolgens een verwerkingsscript hieroverheen te gooien nadat het bestand is gegenereerd om de bestanden die de site laten zien te genereren.

Maar...
Er is altijd een maar, is het niet slimmer om bijvoorbeeld de XML bestanden te genereren en deze on demand om te vormen naar HTML (hierdoor word de DB-server niet belast maar de webserver meer) of zijn er nog andere manieren?

Als er nog meer info nodig is of als iemand niet snapt waar ik het over heb zal ik graag nog meer uitleg geven! (Weet ook iemand wat de juiste term voor dit gebeuren is?)

[aex351]

uit onderwerp: Ik denk steeds dat [ALG] een programeer taal is

Ik denk dat je je site wil cachen? dat kan je doen door alles wat je nodig hebt uit de database te halen doormiddel van bijvoorbeeld php. En al het inhoud naar een bestandje schrijven.

Doormiddel van een cronjob kan je het steeds om 4 uur laten gebeuren bijvoorbeeld

[ Voor 61% gewijzigd door aex351 op 04-07-2005 13:21 ]

[supakeen]

aex351 schreef op maandag 04 juli 2005 @ 13:19:
uit onderwerp: Ik denk steeds dat [ALG] een programeer taal is

dat dacht ik ook vroegah (of algoritme ofzo)

[ Voor 6% gewijzigd door supakeen op 04-07-2005 13:21 ]

[mulder]

Misschien handig om aan te geven met welke taal/platform je werkt.

[Verwijderd]

zmn schreef op maandag 04 juli 2005 @ 13:20:
[...]


dat dacht ik ook vroegah (of algoritme ofzo)

Algol? Das een programmeertaal...

Maar even ontopic, waarom zou je niet gewoon je HTML in een DB zettene en met php uitlezen? Net als de vorige poster, maar met de toevoeging dat je gewoon php gebruikt om het ook uit te lezen, dus php om de html direct op iemands scherm te pleuren

[mulder]

Verwijderd schreef op maandag 04 juli 2005 @ 13:23:
[...]
Maar even ontopic, waarom zou je niet gewoon je HTML in een DB zettene en met php uitlezen?

Waarom gebruik je dan nog PHP? HTML liever niet in de db, daar is ie niet voor.
Je kunt bijvoorbeeld met PHP gewoon de output niet naar de browser sturen maar afvangen en opslaan.

[sig69]

In .net heb je zoiets als een cachedependancy

[Janoz]

Waarom genereer je niet rechtstreeks HTML? Waarom is de XML tussenstap nodig? Ikzelf zou trouwens het genereren niet om 4u 's nachts doen, maar gewoon wanneer er een aanpassing geweest is, en dan alleen de onderdelen (opnieuw) genereren die afhankelijk zijn van die specefieke verandering.

[supakeen]

Janoz schreef op maandag 04 juli 2005 @ 13:28:
Waarom genereer je niet rechtstreeks HTML? Waarom is de XML tussenstap nodig? Ikzelf zou trouwens het genereren niet om 4u 's nachts doen, maar gewoon wanneer er een aanpassing geweest is, en dan alleen de onderdelen (opnieuw) genereren die afhankelijk zijn van die specefieke verandering.

XML omdat je misschien nog een andere manier zou willen (bijvoorbeeld een clientside applicatie of iets dergelijks). Genereren om 4 uur s'nachts of als er opdracht tot word gegeven.

Verwijderd schreef op maandag 04 juli 2005 @ 13:23:
[...]


Algol? Das een programmeertaal...

Maar even ontopic, waarom zou je niet gewoon je HTML in een DB zettene en met php uitlezen? Net als de vorige poster, maar met de toevoeging dat je gewoon php gebruikt om het ook uit te lezen, dus php om de html direct op iemands scherm te pleuren

Omdat je dan alsnog met een grote hoeveelheid queries zou zitten en dat is nou net wat je wil verminderen met een systeem als dit en het is natuurlijk ook niet erg netjes, gewoon alleen RAW content in de database zetten is zat

aex351 schreef op maandag 04 juli 2005 @ 13:19:
uit onderwerp: Ik denk steeds dat [ALG] een programeer taal is

Ik denk dat je je site wil cachen? dat kan je doen door alles wat je nodig hebt uit de database te halen doormiddel van bijvoorbeeld php. En al het inhoud naar een bestandje schrijven.

Doormiddel van een cronjob kan je het steeds om 4 uur laten gebeuren bijvoorbeeld

Volgens mij zei ik dat al in de inleiding het gaat er meer om of het idee slim is om de XML bestanden te bewaren en of het hele gebeuren zozo nut heeft

Vervolg
Is zoiets als dit echt nuttig of kun je het net zo goed gewoon meteen on demand uit de database laten trekken?

[ Voor 61% gewijzigd door supakeen op 04-07-2005 13:34 ]

[Verwijderd]

Ik zou bovendien niet alles cachen, dat is nogal over the top. Alleen cachen waarvan jij verwacht dat het in de nabije toekomst nog een keer opgevraagd zal gaan worden. Daar zijn verschillende algoritmes voor en je kan zelf ook wel iets bedenken dat redelijk betrouwbaar is.

[Orphix]

zmn schreef op maandag 04 juli 2005 @ 13:31:
Vervolg
Is zoiets als dit echt nuttig of kun je het net zo goed gewoon meteen on demand uit de database laten trekken?

Dat hangt helemaal af van je site. Trek je echt enorm veel bezoekers, zoveel dat je DB het niet aan kan? Dan is het misschien een optie. Houdt er wel rekening mee dat HTML erg statisch is. Een site ala amazon.com of gathering is zo user-specifiek dat het geen zin heeft om vooraf statische pagina's te genereren.
Daarbij maak je het wel extra ingewikkeld als je on-demand en on-schedule html bestanden gaat genereren (moet ook weer code voor worden geschreven). Ik zou het persoonlijk niet doen, tenzij je heel veel statische content hebt en heel veel bezoekers (bijvoorbeeld een songteksten site).

[Janoz]

zmn schreef op maandag 04 juli 2005 @ 13:31:
XML omdat je misschien nog een andere manier zou willen (bijvoorbeeld een clientside applicatie of iets dergelijks).

Je html wordt gegenereerd uit een bepaalde data. Waarom zou die mogelijke client applicatie niet rechtstreeks kunnen verbinden met die data?

Genereren om 4 uur s'nachts of als er opdracht tot word gegeven.

Waarom zou je beide willen doen? Bij aanpassen bij een verandering hoeft er om 4u niks te gebeuren aangezien alle html al up to date is.

[supakeen]

Janoz schreef op maandag 04 juli 2005 @ 13:36:
[...]


Je html wordt gegenereerd uit een bepaalde data. Waarom zou die mogelijke client applicatie niet rechtstreeks kunnen verbinden met die data?

Omdat de server misschien geen SQL toegang geeft behalve aan het interne netwerk en als je dan vanaf extern aan de slag wil gaan leek mij dit een oplossing.

Janoz schreef op maandag 04 juli 2005 @ 13:36:
[...]

Waarom zou je beide willen doen? Bij aanpassen bij een verandering hoeft er om 4u niks te gebeuren aangezien alle html al up to date is.

Het zou kunnen dat niet alle updates belangrijk genoeg zijn om direct verwerkt te worden, maar dat is natuurlijk ook slap gelul van mij, het is inderdaad beter om die 4u generation te schrappen en gewoon te doen als de noodzaak daar is.

Orphix schreef op maandag 04 juli 2005 @ 13:36:
[...]

Dat hangt helemaal af van je site. Trek je echt enorm veel bezoekers, zoveel dat je DB het niet aan kan? Dan is het misschien een optie. Houdt er wel rekening mee dat HTML erg statisch is. Een site ala amazon.com of gathering is zo user-specifiek dat het geen zin heeft om vooraf statische pagina's te genereren.
Daarbij maak je het wel extra ingewikkeld als je on-demand en on-schedule html bestanden gaat genereren (moet ook weer code voor worden geschreven). Ik zou het persoonlijk niet doen, tenzij je heel veel statische content hebt en heel veel bezoekers (bijvoorbeeld een songteksten site).

Dit is puur een case die niet bestaat. Ik heb hem gewoon uit mijn duim gezogen omdat ik me afvroeg hoe jullie het zouden doen (op mijn eigen site trek ik gewoon direct uit de database)

[ Voor 34% gewijzigd door supakeen op 04-07-2005 13:42 ]