Server Side Include: virtual niet altijd virtual?

[Hipska]

Dus:

Ik ben bezig met een website, en daar gebruik ik SSI om bepaalde extra dingen op een pagina te plaatsen en om het hoofdscript enkel zijn hoofdtaak te laten doen.

Ik doe nu op alle pagina's hetzelfde namelijk:

code:

<!--#include virtual="/kalender/mini.html" -->

Virtual omdat het dan via mod_rewrite ofwel bij een gecachte file uitkomt ofwel bij een php script die de uitvoer verzorgt.

Dit doet ie op alle pagina's perfect, behalve op de gastenboek pagina's, waar hij blijkbaar de bootstrap.php als php include, want ik krijg de foutmelding dat bepaalde zaken al eerder gedefiniëerd zijn..

Hoe kan dit nou?

Een speurtocht op het net heeft me niet veel opgeleverd omdat daar vaak de discussie gevoerd word of al dan niet SSI kan samen werken met php..

Ik heb nog net 1 mogelijkheid om te proberen die me net is opgekomen tijdens het typen van deze post, en dat is de template engine uitsluiten..
EDIT: Net getest met puur de html met die include te echo-en, dit geeft hetzelfde resultaat.

[ Voor 4% gewijzigd door Hipska op 11-06-2010 21:53 . Reden: aanvulling ]

[Hipska]

Even verder onderzocht waarom hij het niet deed en kwam tot volgende conclusie:
Vanaf het moment dat het hoofddocument (dus het gene dat aangeroepen wordt in de browser en de <!--#include bevat) meer dan 8000 karakters en/of bytes is, dan werkt het niet meer..

Het is dus een memory probleem.

Maar nu, wat kan ik er aan doen?
Ik gebruik volgende software:
Zend Server 5.0 CE
Apache/2.2.14 (Unix)
mod_include (versie?)

[Verwijderd]

Waarom gebruik je in vredesnaam SSI?

[Hipska]

Om pagina's volledig statisch te kunnen cachen als .html en die dan toch nog enkele dynamische gegevens te kunnen laten tonen. Bijvoorbeeld kalender of recente posts in een zijbalk als bijvoorbeeld hier op Tweakers.

Is dit een oplossing op mijn probleem?

[RobIII]

Hipska schreef op zaterdag 12 juni 2010 @ 22:35:
Om pagina's volledig statisch te kunnen cachen als .html en die dan toch nog enkele dynamische gegevens te kunnen laten tonen.

Dan is er dus niets statisch aan. Wat is het verschil met:

PHP:

<p>Lorem ipsum dolor...</p>
<?php
include('foo.php');
?>
<p>Lorem ipsum dolor...</p>

...of het equivalent ervan in ASP/Coldfusion/You_name_it

Wat je probleem betreft; ik ben er niet heel erg bekend mee, maar ik kan me voorstellen dat er ergens een limiet op 8k staat in een config oid. Heb je al eens door de configs heen gekeken om te zien of je iets zag staan dat er mee te maken heeft of kan hebben?

[ Voor 23% gewijzigd door RobIII op 12-06-2010 22:47 ]

[Hipska]

nou, het lijkt me niet dat dat stukje code op te slaan is als .html
en $foo zou niet in het huidige php script te vinden zijn.
Eerder te vergelijken met include('anders.php'); maar dan kan je de uitvoer daarvan nog steeds niet volledig cachen want er zitten dynamische onderdelen in die na x seconden alweer out of date kunnen zijn. En een cache file enkele seconden maar laten leven is de moeite van extra programmeerwerk niet.

En is dat nou de oplossing van mijn probleem meneer de moderator? Nu is er plotseling wel toegevoegde waarde.

[ Voor 4% gewijzigd door Hipska op 12-06-2010 22:52 ]

[Verwijderd]

Je creëert een probleem omdat je niet weet hoe de server requests verwerkt en een response produceert. Wat dat betreft ga ik dus niet in op het probleem dat je er zelf van maakt wegens gebrek aan kennis. SSI heeft geen enkele meerwaarde als je PHP kunt gebruiken, en als je al PHP gebruikt zou ik zelfs zeggen dat je niet eens moet overwegen om SSI erbij te gaan gebruiken.

[RobIII]

Hipska schreef op zaterdag 12 juni 2010 @ 22:44:
nou, het lijkt me niet dat dat stukje code op te slaan is als .html

Wat boeit de bestandsextensie nou? Dus: of maak duidelijk wat je nou bedoeld, of laat het idee varen dat een bestandsextensie iets boeit. Al sla je het op als .hipska ....

Hipska schreef op zaterdag 12 juni 2010 @ 22:44:
en $foo zou niet in het huidige php script te vinden zijn.

Het ging om het principe; iets met pseudo-code enzo...

Hipska schreef op zaterdag 12 juni 2010 @ 22:44:
Eerder te vergelijken met include('anders.php'); maar dan kan je de uitvoer daarvan nog steeds niet volledig cachen want er zitten dynamische onderdelen in die na x seconden alweer out of date kunnen zijn.

Hangt er maar net van af hoe je cached he?
En dan nogmaals: wat is het verschil? Het dynamische deel zal toch uitgevoerd moeten worden; de rest is in mijn voorbeeld net zo statisch... Hoe je de "dynamische uitvoer" cached moet je zelf weten.

Hipska schreef op zaterdag 12 juni 2010 @ 22:44:
En is dat nou de oplossing van mijn probleem meneer de moderator?

En heb jij mijn edit gelezen, meneer de user? Het zou je sieren als je even probeert mee te denken als mensen je proberen te helpen in plaats van bijdehand gaan lopen doen...

[ Voor 20% gewijzigd door RobIII op 12-06-2010 22:52 ]

[Hipska]

RobIII schreef op zaterdag 12 juni 2010 @ 22:46:
Wat boeit de bestandsextensie nou? Dus: of maak duidelijk wat je nou bedoeld, of laat het idee varen dat een bestandsextensie iets boeit. Al sla je het op als .hipska ....

Mijn opzet is dus om cache files te hebben die direct door apache aan de gebruiker geserved kunnen worden zonder dat php hiervoor moet tussenkomen.

En heb jij mijn edit gelezen, meneer de user? Het zou je sieren als je even probeert mee te denken als mensen je proberen te helpen in plaats van bijdehand gaan lopen doen...

En heb jij mijn edit gelezen? Ik ben ondertussen alle apache config files aan het overlopen. In de manual van Apache over mod_include staat alvast niets over een max memory of een instelling daarvoor. dus ik kijk ook voor algemene settings die op 8000 of iets dergelijks staan.
Ik probeer zeker mee te denken, en heb dus ook al kunnen vinden wanneer het probleem hem precies voor doet. Dus hoezo bijdehand?
En daarbij, was uw edit 3 minuten geplaatst na mijn reactie, dus kon ik dat al onmogelijk in mijn reactie verwerkt hebben.

Verwijderd schreef op zaterdag 12 juni 2010 @ 22:44:
Je creëert een probleem omdat je niet weet hoe de server requests verwerkt en een response produceert. Wat dat betreft ga ik dus niet in op het probleem dat je er zelf van maakt wegens gebrek aan kennis. SSI heeft geen enkele meerwaarde als je PHP kunt gebruiken, en als je al PHP gebruikt zou ik zelfs zeggen dat je niet eens moet overwegen om SSI erbij te gaan gebruiken.

Ik creëer niet een probleem, er is blijkbaar een probleem van zodra de pagina meer dan 8000 bytes is en je SSI gebruikt. Dat probleem heb ik echt niet zelf gecreëerd.
Hoe kan ik bewijzen dat ik de opbouw van requests e.d. wel degelijk snap? (Request -> php bouwt pagina op -> door xbit voegt/past mod_include hier en daar wat toe/aan -> bytes worden naar client verstuurd)
Ik gebruik net SSI omdat mijn gecachte files dan die tussenstap van php niet meer nodig hebben bij het laden van de pagina.

[ Voor 32% gewijzigd door Hipska op 12-06-2010 23:15 ]

[kaesve]

Hipska schreef op zaterdag 12 juni 2010 @ 22:59:
[...]

Mijn opzet is dus om cache files te hebben die direct door apache aan de gebruiker geserved kunnen worden zonder dat php hiervoor moet tussenkomen.

met welke voordelen? als ik zo rond kijk lijkt een php include zelfs sneller te zijn dan een SSI. sterker nog, in deze test lijkt SSI zelfs significant langzamer..

[ Voor 36% gewijzigd door kaesve op 12-06-2010 23:15 ]

[Verwijderd]

Ik creëer niet een probleem, er is blijkbaar een probleem van zodra de pagina meer dan 8000 bytes is en je SSI gebruikt. Dat probleem heb ik echt niet zelf gecreëerd.
Hoe kan ik bewijzen dat ik de opbouw van requests e.d. wel degelijk snap?

Niet. Het feit dat je een verkeerde keuze hebt gemaakt zegt alles al.

Ik gebruik net SSI omdat mijn gecachte files dan die tussenstap van php niet meer nodig hebben bij het laden van de pagina.

Welke gecachete files? Wat wordt er volgens jou gecachet, waar wordt die cache bijgehouden, en waarom is dat dus beter dan SSI laten voor wat het is en alleen PHP gebruiken?

[Hipska]

@Cheatah: Wil je nou eens aub stoppen met zeggen dat iets niet gebruikt zou mogen worden zonder een deftig tegenargument. Ik meen dat ik iets dergelijks nog niet van jou gehoord heb. Enkel nog maar de vraag waarom ik het uberhaut gebruik en dat ik het alvast niet meer moet gebruiken maar in de plaats php gebruiken, en dit zonder argumenten.

Verwijderd schreef op zaterdag 12 juni 2010 @ 23:19:
Welke gecachete files? Wat wordt er volgens jou gecachet, waar wordt die cache bijgehouden, en waarom is dat dus beter dan SSI laten voor wat het is en alleen PHP gebruiken?

De hoofduitvoer van het script wordt gecached. Stel je even voor op een nieuwspagina. Daar wordt het artikel en de bijhorende html gecached, en de zijbalk met trackers ivm recente posts en comments worden dan door die virtual include gedaan. Waar? gewoon ergens in htdocs directory, het zijn gewone (s)html files. Waarom? Eenvoud in de template's. <!--#include virtual="/blabla.html"--> in plaats van php code genereren die iets doet als <? echo file_get_contents('http://www.jesitezondernaam.tld/blabla.html'); ?>. Doel is toch altijd om zo eenvoudig mogelijk code te schrijven dacht ik?

kaesve schreef op zaterdag 12 juni 2010 @ 23:15:
met welke voordelen? als ik zo rond kijk lijkt een php include zelfs sneller te zijn dan een SSI. sterker nog, in deze test lijkt SSI zelfs significant langzamer..

Eindelijk een deftiger argument waarom SSI niet gebruikt zou moeten worden..
Maar dit lost uiteindelijk het 8k probleem niet op.

In de apache config files nergens iets gevonden met betrekking op buffer groote's en ook niets van grootte rond 8000. Iemand een idee waar ik verder kan zoeken?
Of kan iemand in zijn systeem eens testen of het wel werkt die virtual include met 8000 bytes. Misschien is dit wel een bug ofzo?

[Verwijderd]

Hipska schreef op zondag 13 juni 2010 @ 00:30:
@Cheatah: Wil je nou eens aub stoppen met zeggen dat iets niet gebruikt zou mogen worden zonder een deftig tegenargument. Ik meen dat ik iets dergelijks nog niet van jou gehoord heb. Enkel nog maar de vraag waarom ik het uberhaut gebruik en dat ik het alvast niet meer moet gebruiken maar in de plaats php gebruiken, en dit zonder argumenten.

PHP kan alles wat met SSI ook kan. Je gebruikt al PHP, dus waarom nóg een techniek gebruiken? Als je dat geen argument vindt, dan snap ik je al helemaal niet meer.

De hoofduitvoer van het script wordt gecached. Stel je even voor op een nieuwspagina. Daar wordt het artikel en de bijhorende html gecached, en de zijbalk met trackers ivm recente posts en comments worden dan door die virtual include gedaan. Waar? gewoon ergens in htdocs directory, het zijn gewone (s)html files. Waarom? Eenvoud in de template's. <!--#include virtual="/blabla.html"--> in plaats van php code genereren die iets doet als <? echo file_get_contents('http://www.jesitezondernaam.tld/blabla.html'); ?>.

Als het precies hetzelfde doet, maar alleen de syntax anders is (volgens jou dan), is dat volgens jou genoeg reden om voor de techniek met de mooiste syntax te gaan?

Ik zou het een stuk handiger vinden om alleen het stukje HTML van het nieuwsartikel te cachen in een los bestand, en dat in het PHP script te laten includen (of eigenlijk gewoon in te lezen zonder te parsen). Dat scheelt je een techniek en dus afhankelijkheid.

Overigens hoop ik dat het deel wat je wilt cachen iets ingewikkelder is dan nieuwsberichten, want meestal kost het opbouwen van de rest van pagina's (onderhoudbare menu's etc.) meer tijd dan het ophalen van een stukje content uit een database (aanname).

Doel is toch altijd om zo eenvoudig mogelijk code te schrijven dacht ik?

Ik denk dat het doel is een werkende website/applicatie te maken. Dat je dat het liefst een beetje onderhoudbaar wilt maken is mooi meegenomen, maar is vooral om tijd en/of kosten te besparen.

Cachen is overigens iets wat je pas moet doen als er een goede reden is iets te optimaliseren. Alle algoritmen moeten dan natuurlijk al goed zijn uitgedacht en geoptimaliseerd. Als je het doet omdat je een drukke website hebt, zou ik vooral eens kijken naar een reverse caching proxy, zoals squid of varnish. Dan kun je gewoon je scripts zo schrijven als je zonder cache zou doen, het enige wat dan nog belangrijk is, is om de juiste headers mee te geven. Maar aangezien het nog weer een andere techniek is, geldt hetzelfde: keep it simple. Als je het ingewikkelder maakt, moet je er gewoon goede redenen voor hebben. In het geval van gebruik maken van PHP is er gewoon geen reden die daarbij het gebruik maken van SSI zou verantwoorden.

[CyBeR]

Een andere optie die je zou kunnen proberen (die er, in tegenstelling tot SSI, wel voor bedoeld is), is een Varnish voor je Apache hangen en dan met ESI werken. Dat is een beetje hetzelfde idee maar dan lichter en sneller.

[Wolfboy]

CyBeR schreef op zondag 13 juni 2010 @ 01:52:
Een andere optie die je zou kunnen proberen (die er, in tegenstelling tot SSI, wel voor bedoeld is), is een Varnish voor je Apache hangen en dan met ESI werken. Dat is een beetje hetzelfde idee maar dan lichter en sneller.

Met ^^

Varnish of Nginx ervoor hangen en het werkt veel sneller/beter.

Toevallig heb ik net een paar weken geleden een dergelijk caching systeem i.c.m. memcached geimplementeerd. Resultaat... pageloads bij volledig statische content zo'n 0.00036 seconde.
Zie hier de presentatie: http://www.slideshare.net...enbach/just-a-millisecond

Het nut hiervan is natuurlijk afhankelijk van de rest van je systeem en als je toch in alle gevallen nog een PHP request moet doen waarschijnlijk niet heel erg nuttig. Maar het kan nog steeds wel positieve resultaten geven.

[Hipska]

Heb even verder onderzocht, en het probleem doet hem enkel voor wanneer de html code met de ssi code uitgespuwd wordt door php. Wanneer een 8k+ bestand met ssi include als html bestand fysiek op de server staat doet het probleem zich niet voor.

Het is dus een zeer specifiek randgeval, die inderdaad heel zelden zal voorkomen omdat niemand de combinatie van php en SSI doet.

Mijn idee van cachen was eigenlijk primair bedoeld als test en om te kijken als het mogelijk is om php buiten het caching mechanisme te laten vallen.. Waarschijnlijk zijn Varnish of Nginx dan inderdaad betere opties dan SSI.

Moet ik nu voor dat probleem (of bug?) verder gaan zoeken in php.ini?

[WouZz]

Even je 'probleem' in perspectief zetten:

• Hoe lang ben je al bezig met dit probleem? (Lees wat kost het: reken uit aantal uren * tarief)
• Wat is daadwerkelijk je performancewinst met deze benadering? Meer dan 100ms?
• Is deze benadering daadwerkelijk sneller dan een eenvoudige include of php based file cache? (output wegschrijven naar cachefile / cachefile serveren)?
• Hoeveel verkeer heb je op je servers? Staan ze al te roken of heb je eigenlijk helemaal geen probleem?
• Als je echt veel traffic hebt, waarom niet een caching proxy oplossing kiezen (Squid / varnish etc)?
• Is dit een stabiele oplossing? (gezien topic, nee)

[Wizz15]

Hipska schreef op zondag 13 juni 2010 @ 11:18:
Heb even verder onderzocht, en het probleem doet hem enkel voor wanneer de html code met de ssi code uitgespuwd wordt door php. Wanneer een 8k+ bestand met ssi include als html bestand fysiek op de server staat doet het probleem zich niet voor.

Het is dus een zeer specifiek randgeval, die inderdaad heel zelden zal voorkomen omdat niemand de combinatie van php en SSI doet.

Mijn idee van cachen was eigenlijk primair bedoeld als test en om te kijken als het mogelijk is om php buiten het caching mechanisme te laten vallen.. Waarschijnlijk zijn Varnish of Nginx dan inderdaad betere opties dan SSI.

Moet ik nu voor dat probleem (of bug?) verder gaan zoeken in php.ini?

Aangezien het als test bedoelt was zou ik eerder kijken naar Varnish. Het is vrij simpel op te zetten en cached alles wat opgevraagd wordt aan je webserver. Het ondersteund ESI (het idee is hetzelfde als SSI), waardoor je dynamische scripts kunt laden in bestanden uit de cache. Verder is het retesnel en je zorgt ervoor dat je webserver nauwelijks belast wordt. Ik heb het inmiddels ook op mijn eigen server draaien en op een paar productiesites en je hebt 't echt binnen een paar minuten werkend.

Ik vraag me daarom af of de moeite die je wilt steken in het oplossen van een bug opweegt tegen het opzetten en configureren van Varnish, wat gewoon meteen werkt met caching en al .

Verwijderd schreef op zondag 13 juni 2010 @ 01:44:
PHP kan alles wat met SSI ook kan. Je gebruikt al PHP, dus waarom nóg een techniek gebruiken? Als je dat geen argument vindt, dan snap ik je al helemaal niet meer.

@Cheatah: De TS beschrijft duidelijk een situatie die opgelost wordt door een reverse-proxy... Het is zeker niet zo dat PHP dit allemaal prima kan, want reverse-proxies zijn er juist voor om de webserver zo min mogelijk werk te laten doen, en het runnen van PHP (wat veel resources vreet) tot een minimum te beperken.

Ook een webserver als Apache vreet resources, dus als je alle statische files (javascripts/css/afbeeldingen) cached via de reverse-proxy dan scheelt dat een hele hoop CPU time die anders onnodig door Apache opgeslokt zou worden. Als je bijvoorbeeld op een nieuwssite voor elk request een PHP script wil laten runnen dan wens ik je veel succes, maar je server wordt na een paar bezoekers zo traag als dikke str*nt door een trechter

[ Voor 25% gewijzigd door Wizz15 op 13-06-2010 22:38 ]

[Verwijderd]

Wizz15 schreef op zondag 13 juni 2010 @ 22:26:
@Cheatah: De TS beschrijft duidelijk een situatie die opgelost wordt door een reverse-proxy... Het is zeker niet zo dat PHP dit allemaal prima kan, want reverse-proxies zijn er juist voor om de webserver zo min mogelijk werk te laten doen, en het runnen van PHP (wat veel resources vreet) tot een minimum te beperken.

Joh, bedankt dat je dat even uitlegt, maar ik denk dat ik met 8 jaar professionele ervaring op het gebied van webdevelopment en serverbeheer dat prima kan bepalen. En nee, je gaat niet direct kijken naar een reverse caching proxy (wat ik overigens al duidelijk had genoemd, als eerste persoon in dit topic, herhaald door 4 anderen). Je zet pas zo'n oplossing in als er een performanceprobleem is. Geloof me, elke vorm van caching kan nieuwe problemen geven, situaties waaraan je even niet hebt gedacht, of die het debuggen lastig maken. PHP hoeft helemaal niet veel resources te vreten, dat doet het alleen als je niet efficiënt werkt.

Ook een webserver als Apache vreet resources, dus als je alle statische files (javascripts/css/afbeeldingen) cached via de reverse-proxy dan scheelt dat een hele hoop CPU time die anders onnodig door Apache opgeslokt zou worden. Als je bijvoorbeeld op een nieuwssite voor elk request een PHP script wil laten runnen dan wens ik je veel succes, maar je server wordt na een paar bezoekers zo traag als dikke str*nt door een trechter

Dat ligt er maar aan of je een goede developer en/of serverbeheerder bent. Apache hoeft helemaal geen resources te vreten. Maar het ligt aan het type site om te zien of je iets anders dan Apache nodig hebt. In principe is Apache de standaard webserver voor Linux en Unix-like systemen omdat het zo breed inzetbaar is. Maar als je echt grote volumes moet gaan verwerken kun je inderdaad kijken naar alternatieven. Als. Ook hier geldt: premature optimization is the mother of all fuckups.

Developers zijn gek op technieken om te kunnen gebruiken, maar een goede professionele developer denkt toch ook echt aan zijn eigen portemonnee. Wat verwacht de klant? Wat verwacht de bezoeker? Moet je ze meer geven dan ze verwachten?

Ik waarschuw niet voor niets om niet onnodig moeilijk te gaan doen. De meeste problemen worden onnodig gecreëerd. Dit is er typisch zo'n probleem.

[Gomez12]

Kan er iemand mij eens uitleggen hoe een reverse proxy het volgende stuk afhandelt?

Hipska schreef op zaterdag 12 juni 2010 @ 22:35:
Om pagina's volledig statisch te kunnen cachen als .html en die dan toch nog enkele dynamische gegevens te kunnen laten tonen.

Afaik cached een reverse proxy gewoon de complete request / pagina. Hoe krijg je dan de dynamische gegevens erin? ( zonder ranzige JS/AJAX/extra requests dus )

Zover ik het zie wil de TS helemaal geen requests gaan cachen, maar blokken. En dat ondersteund een reverse proxy niet afaik, gewoon standaard php kan je dit wel in doen.

[Verwijderd]

Gomez12 schreef op maandag 14 juni 2010 @ 00:21:
Kan er iemand mij eens uitleggen hoe een reverse proxy het volgende stuk afhandelt?

Zie bijvoorbeeld http://varnish-cache.org/wiki/ESIfeatures

Varnish is een high performance proxy, waarin je met VCL nog enige logica kan inbouwen. Niet te ingewikkeld, want het moet niet traag worden.

...gewoon standaard php kan je dit wel in doen.

Overigens bedoelde ik inderdaad in eerste instantie dat het prima mogelijk is in PHP hele blokken output te cachen. Dat kan een website ook behoorlijk snel maken. Zo snel dat verdere optimalisaties waarschijnlijk al totaal onnodig zijn. En het is vrij simpel te programmeren, dus geen verdere afhankelijkheden. En je site blijft dan gewoon genoeg om op een shared hosting omgeving te kunnen hosten, dus niet direct een dedicated (virtual) server nodig. Ook iets om even bij stil te staan.

[Gomez12]

Verwijderd schreef op maandag 14 juni 2010 @ 00:28:
[...]

Zie bijvoorbeeld http://varnish-cache.org/wiki/ESIfeatures

Varnish is een high performance proxy, waarin je met VCL nog enige logica kan inbouwen. Niet te ingewikkeld, want het moet niet traag worden.

Heb je dan niet gewoon een andere vorm van SSI te pakken?

Kijk, opzich vind ik het nut van SSI afvragen wel leuk, maar als dan iedereen met een alternatief komt wat imho zo ongeveer hetzelfde is...

[Wizz15]

Verwijderd schreef op maandag 14 juni 2010 @ 00:02:
Joh, bedankt dat je dat even uitlegt, maar ik denk dat ik met 8 jaar professionele ervaring op het gebied van webdevelopment en serverbeheer dat prima kan bepalen.

Prima, maar ik kan natuurlijk niet weten hoeveel ervaring iemand al heeft Ik deel net als jou 8 jaar professionele ervaring, ik ga alleen puur af op wat de TS post:

Mijn opzet is dus om cache files te hebben die direct door apache aan de gebruiker geserved kunnen worden zonder dat php hiervoor moet tussenkomen.

Dit was voor mij de aanleiding om Varnish aan te halen, aangezien dat precies doet wat hij wil (namelijk zonder tussenkomst van PHP en zelfs Apache).

Verwijderd schreef op maandag 14 juni 2010 @ 00:02:
En nee, je gaat niet direct kijken naar een reverse caching proxy (wat ik overigens al duidelijk had genoemd, als eerste persoon in dit topic, herhaald door 4 anderen). Je zet pas zo'n oplossing in als er een performanceprobleem is. Geloof me, elke vorm van caching kan nieuwe problemen geven, situaties waaraan je even niet hebt gedacht, of die het debuggen lastig maken. PHP hoeft helemaal niet veel resources te vreten, dat doet het alleen als je niet efficiënt werkt.

Dit ben ik helemaal met je eens, behalve het performanceprobleem. Waarom zou je je webserver niet wat ademruimte mogen geven voordat hij uberhaupt tegen zijn limiet aanzit? Debuggen moet je sowieso niet doen op een live site, daar kun je hooguit goed loggen wat er fout gaat, zorgen voor een goede afhandeling en lokaal debuggen. Maar dit gaat al redelijk offtopic.

Ik wil alleen maar aangeven dat ik Varnish aandraag omdat de TS blijkbaar voor zichzelf heel duidelijk heeft dat hij geen PHP wil gebruiken om wat voor reden dan ook, ondanks adviezen van andere Tweakers .

Verwijderd schreef op maandag 14 juni 2010 @ 00:02:
Dat ligt er maar aan of je een goede developer en/of serverbeheerder bent. Apache hoeft helemaal geen resources te vreten. Maar het ligt aan het type site om te zien of je iets anders dan Apache nodig hebt. In principe is Apache de standaard webserver voor Linux en Unix-like systemen omdat het zo breed inzetbaar is. Maar als je echt grote volumes moet gaan verwerken kun je inderdaad kijken naar alternatieven. Als. Ook hier geldt: premature optimization is the mother of all fuckups.

Ook dit ben ik met je eens, maar er is niks mis mee om je webserver te ontzien voor statische files. Dit geldt niet alleen voor sites met een miljoenenpubliek (hoewel ik er niet vanuit ga dat ze daar Apache hebben draaien ), maar ook zeker voor bijvoorbeeld een kleine virtual server met beperkte resources. Dit kan onder andere door het gebruik van een reverse-caching proxy, danwel een CDN. Dit scheelt requests naar Apache/PHP waardoor je server meer tijd over heeft voor andere zaken. Wat is daar precies slecht aan?

En natuurlijk moet alles goed geconfigureerd zijn, maar daar zijn genoeg artikelen over te vinden op internet die ook voor beginners nog te snappen zijn (o.a. op IBM developer network).

[Wolfboy]

Verwijderd schreef op maandag 14 juni 2010 @ 00:02:
[...]

Joh, bedankt dat je dat even uitlegt, maar ik denk dat ik met 8 jaar professionele ervaring op het gebied van webdevelopment en serverbeheer dat prima kan bepalen. En nee, je gaat niet direct kijken naar een reverse caching proxy (wat ik overigens al duidelijk had genoemd, als eerste persoon in dit topic, herhaald door 4 anderen). Je zet pas zo'n oplossing in als er een performanceprobleem is. Geloof me, elke vorm van caching kan nieuwe problemen geven, situaties waaraan je even niet hebt gedacht, of die het debuggen lastig maken. PHP hoeft helemaal niet veel resources te vreten, dat doet het alleen als je niet efficiënt werkt.

Al ben ik het volledig eens met je uitleg vraag ik me toch af of je serieus denkt dat PHP geen resources vreet. Het scheelt al snel een orde van grootte of meer.
Zoja, lees dit artikel eens: http://www.pankaj-k.net/w...ow_that_each_integer.html

Al ben ik het overigens wel met je eens dat het in de meeste gevallen je laatste zorg zal zijn. Prima betoog m.i.

Gomez12 schreef op maandag 14 juni 2010 @ 00:37:
[...]

Heb je dan niet gewoon een andere vorm van SSI te pakken?

Kijk, opzich vind ik het nut van SSI afvragen wel leuk, maar als dan iedereen met een alternatief komt wat imho zo ongeveer hetzelfde is...

Ja, ESI, SSI, etc... Ze hebben allemaal wel een "virtual include" achtig iets. Maar het komt allemaal redelijk op hetzelfde neer.