Onderwerp: Server-side includes: risico van vertraging?

Ik ben de laatste tijd veel met php (en in mindere mate met asp) aan het
werken, eigenlijk vooral omdat je pagina's daar makkelijk in componenten op
kunt bouwen met statements zoals include("header.php") waarin je dan
bijvoorbeeld alles opneemt wat tussen <html>en <body> staat. Interactiviteit
is dus niet de voornaamste reden, meer de onderhoudbaarheid. Daar komt bij
dat ik niet over geavanceerde softwarepakketten beschik waarmee je de html
uit componenten kunt opbouwen en kunt "compileren" (ik meen me te herinneren
dat dreamweaver zoiets doet).
Deze techniek bevalt me op zich prima, alleen de vraag : kan deze werkwijze
enige (merkbare) vertraging opleveren in vergelijking met het hard coderen
van losse html-pagina's? Links waarin deze materie besproken wordt zijn,
zoals altijd, ook van harte welkom.
Bedankt!
Martien van Wanrooij

Martien van Wanrooij:
>Ik ben de laatste tijd veel met php (en in mindere mate met asp) aan het
>werken, eigenlijk vooral omdat je pagina's daar makkelijk in componenten op
>kunt bouwen met statements zoals include("header.php") waarin je dan
>bijvoorbeeld alles opneemt wat tussen <html>en <body> staat. Interactiviteit
>is dus niet de voornaamste reden, meer de onderhoudbaarheid. Daar komt bij
>dat ik niet over geavanceerde softwarepakketten beschik waarmee je de html
>uit componenten kunt opbouwen en kunt "compileren" (ik meen me te herinneren
>dat dreamweaver zoiets doet).

Ik die precies hetzelfde, vanwege de onderhoudbaarheid, en ook omdat ik
niet afhankelijk wil zijn van specifieke client-side pakketten als
Dreamweaver. Linux, Apache en PHP zij al tijden vrij beschikbaar en zullen
dat blijven, met die pakketten weet je nooit wat er gebeurt en moet je
elke 2 jaar op een andere overstappen.

Een nadeeltje vind ik wel dat door de PHP-includes en functie-aanroepen
het WYSIWYG-karakter van Dreamweaver verloren gaat.

>Deze techniek bevalt me op zich prima, alleen de vraag : kan deze werkwijze
>enige (merkbare) vertraging opleveren in vergelijking met het hard coderen
>van losse html-pagina's?

Vertraging ja, praktisch merkbaar nee. Een paar extra file I/O's en een
beetje parsen daar ligt een hedendaagse webserver niet wakker van. Alleen
op een zwaar belaste server en/of met een heel nauwkeurige stopwatch zou
je het verschil kunnen meten. De vertraging door het Internetverkeer is
vele malen groter.

Ik heb het niet gemeten, maar ik vermoed dat PHP wat efficiënter is dan
SSI, omdat de PHP-engine AIGBB (in enige mate) compileert en de
gecompileerde pagina hergebruikt, terwijl de SSI-engine bij elke opvraging
opnieuw parset.

Database-queries is een ander verhaal. Die liggen kwa CPU-cycles in een
andere orde van grootte en moet je mijden als de pest. Dat wil zeggen, per
opvraging. Met intelligente caching van data, gerenderde objecten en
gegenereerde pagina's gaat het natuurlijk wel weer.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

"Rene Pijlman" <reply.in.the.newsgroup@my.address.is.invalid> schreef in
bericht news:g0ak20hgdn1tm458hheg3gu2rf359sbm5s@4ax.com...
> Een nadeeltje vind ik wel dat door de PHP-includes en functie-aanroepen
> het WYSIWYG-karakter van Dreamweaver verloren gaat.
Daar ben ik het wel mee eens, maar juist omdat de pagina's modulair
opgebouwd worden, volstaat het meestal er ééntje in de browser te testen.
Zelf gebruik ik voornamelijk Stone's Webwriter, geen WYSIWYG- editor maar
wel voorzien van een toets waardoor je heel snel tussen preview en html
kunt omschakelen.
Het gedeelte van de pagina (zeg maar het "componentje") kan ik dan toch nog
gewoon even bekijken als ik wil Alleen de opmaak is dan niet helemaal
zichtbaar omdat ik stylesheet-verwijzingen meestal in header.php zet.
> Vertraging ja, praktisch merkbaar nee.
Het ging me inderdaad om de praktische merkbaarheid voor de gemiddelde
gebruiker
Bedankt voor je antwoord René, het is me duidelijk dat ik met mijn methode
in elk geval geen heel rare dingen zit te doen ! :-)

Martien van Wanrooij.

Rene Pijlman wrote:

> Vertraging ja, praktisch merkbaar nee. Een paar extra file I/O's en een
> beetje parsen daar ligt een hedendaagse webserver niet wakker van. Alleen
> op een zwaar belaste server en/of met een heel nauwkeurige stopwatch zou
> je het verschil kunnen meten. De vertraging door het Internetverkeer is
> vele malen groter.
>

Met dat verschil dat php gegenereerde pagina's gewoonlijk niet gecached
worden door de browser. Als je dus een pagina binnen korte tijd voor de
tweede keer bezoekt kan het verschil zeker merkbaar zijn. Of dat een
probleem is is een ander verhaal.

Overigens doe ik zelf precies hetzelfde. Eén keer een menu maken en dat
elke keer includen is toch wel erg praktisch, ook al is de site verder
statisch van aard.

Michiel.

"Martien van Wanrooij" <info@martienvanwanrooij.nl> schreef in bericht
news:ScpWb.3786$O41.96298@amstwist00...
> Ik ben de laatste tijd veel met php (en in mindere mate met asp) aan het
> werken, eigenlijk vooral omdat je pagina's daar makkelijk in componenten
op
> kunt bouwen met statements zoals include("header.php") waarin je dan
> bijvoorbeeld alles opneemt wat tussen <html>en <body> staat.
Interactiviteit
> is dus niet de voornaamste reden, meer de onderhoudbaarheid. Daar komt bij
> dat ik niet over geavanceerde softwarepakketten beschik waarmee je de html
> uit componenten kunt opbouwen en kunt "compileren" (ik meen me te
herinneren
> dat dreamweaver zoiets doet).
> Deze techniek bevalt me op zich prima, alleen de vraag : kan deze
werkwijze
> enige (merkbare) vertraging opleveren in vergelijking met het hard coderen
> van losse html-pagina's? Links waarin deze materie besproken wordt zijn,
> zoals altijd, ook van harte welkom.
> Bedankt!
> Martien van Wanrooij
>


Download Template-Toolkit.org. Dit is een perl templating systeem, maar er
zit een mooi tooltje bij, dat iedereen kan gebruiken, ook al werk je verder
niet met perl.
Het is de command line tool ttpage, dat compileert pagina's op de manier die
jij wilt, van een source directory naar en target directory. Er is een
aparte syntax dat wel, maar je hebt maar een paar statements nodig. [%
INCLUDE %] en [% PROCESS %] zijn wel duidelijk. Maar kijk vooral naar [%
WRAPPER %]. Hiermee kan je in 1 keer niet alleen header en footer includen,
maar ook linker en rechter rand (zoals XML maar dan eenvoudiger).
De pagina's in de target directory ga je dan met asp of php tot leven
wekken.

~henq

Michiel de Roo <michiel@mderoopuntnl> wrote:
>> Vertraging ja, praktisch merkbaar nee. Een paar extra file I/O's en een
>> beetje parsen daar ligt een hedendaagse webserver niet wakker van. Alleen
>> op een zwaar belaste server en/of met een heel nauwkeurige stopwatch zou
>> je het verschil kunnen meten. De vertraging door het Internetverkeer is
>> vele malen groter.
>>
>
> Met dat verschil dat php gegenereerde pagina's gewoonlijk niet gecached
> worden door de browser. Als je dus een pagina binnen korte tijd voor de
> tweede keer bezoekt kan het verschil zeker merkbaar zijn. Of dat een
> probleem is is een ander verhaal.

Daar zijn dan ook goede template engines voor gemaakt. In het geval van
php is smarty een voorbeeld hiervan. Je kan beslissen dat:
-de template elke keer opnieuw wordt "samengesteld" (ala include())
-de template compilen (resulteerd in een monolitische variant inclusief
de "includes"
-cachen per:
-tijdseenheid (soort expires dus)
-per user (bv op sessionniveua)
-on-modify (last-modified op de tijd van de laatst gewijzigde "include")

--

Daniel Tryba

"henq >" <henq _ replace 0 by o <hvtijen@h0tmail.c0m> schreef in bericht
news:402def06$0$70741$4a441750@news.euronet.nl...
> Download Template-Toolkit.org. Dit is een perl templating systeem, maar er
> zit een mooi tooltje bij, dat iedereen kan gebruiken, ook al werk je
verder
> niet met perl.
Dank je, daar zal ik beslist eens naar kijken!

> > Vertraging ja, praktisch merkbaar nee. Een paar extra file I/O's en een
> > beetje parsen daar ligt een hedendaagse webserver niet wakker van.
Alleen
> > op een zwaar belaste server en/of met een heel nauwkeurige stopwatch zou
> > je het verschil kunnen meten. De vertraging door het Internetverkeer is
> > vele malen groter.
>
> Met dat verschil dat php gegenereerde pagina's gewoonlijk niet gecached
> worden door de browser. Als je dus een pagina binnen korte tijd voor de
> tweede keer bezoekt kan het verschil zeker merkbaar zijn. Of dat een
> probleem is is een ander verhaal.

Ook PHP pagina's kunnen op de 'normale' manier gecahed worden.
Voorbeelden daarvan kan je hier vinden:
http://ontosys.com/php/cache.html

Om te testen of caching goed werkt is dit een handige site:
http://www.web-caching.com/cacheability.html

Suc6,
André

Daniel Tryba wrote:
> Michiel de Roo <michiel@mderoopuntnl> wrote:
>
>>>Vertraging ja, praktisch merkbaar nee. Een paar extra file I/O's en een
>>>beetje parsen daar ligt een hedendaagse webserver niet wakker van. Alleen
>>>op een zwaar belaste server en/of met een heel nauwkeurige stopwatch zou
>>>je het verschil kunnen meten. De vertraging door het Internetverkeer is
>>>vele malen groter.
>>>
>>
>>Met dat verschil dat php gegenereerde pagina's gewoonlijk niet gecached
>>worden door de browser. Als je dus een pagina binnen korte tijd voor de
>>tweede keer bezoekt kan het verschil zeker merkbaar zijn. Of dat een
>>probleem is is een ander verhaal.
>
>
> Daar zijn dan ook goede template engines voor gemaakt. In het geval van
> php is smarty een voorbeeld hiervan. Je kan beslissen dat:
> -de template elke keer opnieuw wordt "samengesteld" (ala include())
> -de template compilen (resulteerd in een monolitische variant inclusief
> de "includes"
> -cachen per:
> -tijdseenheid (soort expires dus)
> -per user (bv op sessionniveua)
> -on-modify (last-modified op de tijd van de laatst gewijzigde "include")
>

Kan Smarty tegenwoordig ook al cachen aan de client kant ? Als je een
vrijwel statische pagina hebt waar je alleen een statisch menu in include,
dan heeft een server-side cache geen enkele zin.

De pagina zal dan nog steeds over de verbinding worden gedownload, dit
levert de vertraging op die ik bedoelde. De browser en server weten immers
niet anders dan dat de pagina dynamisch is. Een werkelijk statische pagina
zoals een normale html pagina zal in principe uit de cache van de browser
zelf gehaald worden en dat is veel sneller.

Michiel.

Iceman wrote:
>>>Vertraging ja, praktisch merkbaar nee. Een paar extra file I/O's en een
>>>beetje parsen daar ligt een hedendaagse webserver niet wakker van.
>
> Alleen
>
>>>op een zwaar belaste server en/of met een heel nauwkeurige stopwatch zou
>>>je het verschil kunnen meten. De vertraging door het Internetverkeer is
>>>vele malen groter.
>>
>>Met dat verschil dat php gegenereerde pagina's gewoonlijk niet gecached
>>worden door de browser. Als je dus een pagina binnen korte tijd voor de
>>tweede keer bezoekt kan het verschil zeker merkbaar zijn. Of dat een
>>probleem is is een ander verhaal.
>
>
> Ook PHP pagina's kunnen op de 'normale' manier gecahed worden.
> Voorbeelden daarvan kan je hier vinden:
> http://ontosys.com/php/cache.html

Inderdaad een handige truuk.

Michiel de Roo <michiel@mderoopuntnl> wrote:
>> -cachen per:
>> -tijdseenheid (soort expires dus)
>> -per user (bv op sessionniveua)
>> -on-modify (last-modified op de tijd van de laatst gewijzigde "include")
>>
>
> Kan Smarty tegenwoordig ook al cachen aan de client kant ? Als je een
> vrijwel statische pagina hebt waar je alleen een statisch menu in include,
> dan heeft een server-side cache geen enkele zin.

Je kunt ervoor zorgen dat de correcte headers tbv clientside caching
worden meegestuurd, zodat bv in het door jou beschreven geval de
last-modified op de jongste tijd van of de pagina of het menu komt te
staan. Ik heb niet gecontroleerd of smarty ook de head requests met
if-modified-since correct afhandeld in dat geval (ik hoop dat dat het
geval is).

--

Daniel Tryba

Michiel de Roo wrote:

>>
>> Daar zijn dan ook goede template engines voor gemaakt. In het geval van
>> php is smarty een voorbeeld hiervan. Je kan beslissen dat:
>> -de template elke keer opnieuw wordt "samengesteld" (ala include())
>> -de template compilen (resulteerd in een monolitische variant inclusief
>> de "includes"
>> -cachen per:
>> -tijdseenheid (soort expires dus)
>> -per user (bv op sessionniveua)
>> -on-modify (last-modified op de tijd van de laatst gewijzigde "include")
>>
>
> Kan Smarty tegenwoordig ook al cachen aan de client kant ? Als je een
> vrijwel statische pagina hebt waar je alleen een statisch menu in
> include, dan heeft een server-side cache geen enkele zin.
>
> De pagina zal dan nog steeds over de verbinding worden gedownload, dit
> levert de vertraging op die ik bedoelde. De browser en server weten
> immers niet anders dan dat de pagina dynamisch is. Een werkelijk
> statische pagina zoals een normale html pagina zal in principe uit de
> cache van de browser zelf gehaald worden en dat is veel sneller.
>

Oeps, te snel gebruld. Na nader onderzoek blijkt ook Smarty de truuk die
Iceman aangeeft te gebruiken. Dat maakt het verhaal anders, aangezien er
allen een header over de verbinding hoeft.

Michiel.

Daniel Tryba wrote:
> Michiel de Roo <michiel@mderoopuntnl> wrote:
>
>>>-cachen per:
>>> -tijdseenheid (soort expires dus)
>>> -per user (bv op sessionniveua)
>>> -on-modify (last-modified op de tijd van de laatst gewijzigde "include")
>>>
>>
>>Kan Smarty tegenwoordig ook al cachen aan de client kant ? Als je een
>>vrijwel statische pagina hebt waar je alleen een statisch menu in include,
>>dan heeft een server-side cache geen enkele zin.
>
>
> Je kunt ervoor zorgen dat de correcte headers tbv clientside caching
> worden meegestuurd, zodat bv in het door jou beschreven geval de
> last-modified op de jongste tijd van of de pagina of het menu komt te
> staan. Ik heb niet gecontroleerd of smarty ook de head requests met
> if-modified-since correct afhandeld in dat geval (ik hoop dat dat het
> geval is).
>

ja dus...

Michiel.