Nut van cookie-free domain (tweakimg.net)

[LauPro]

ACM schreef op zaterdag 24 april 2010 @ 09:03:
Maar aangezien er tegenwoordig meestal maar een request voor tweakers.net zelf is en de rest via tweakimg.net en ic.tweakimg.net, is het natuurlijk goed mogelijk dat je de daardoor veroorzaakte vertraging alleen op die laatste twee domeinen merkt.

Wat is eigenlijk de reden van deze scheiding? Dat er geen sessie-info wordt meegestuurd om plaatjes op te halen wat weer een paar bytes scheelt?

Persoonlijk beschouw ik een website liever als 1 applicatie en heb ik liever alle resources in 1 webdir/domein. Dan kunnen er ook nooit dit soort continuïteitsproblemen ontstaan.

[Kees]

LauPro schreef op zaterdag 24 april 2010 @ 17:46:
[...]
Wat is eigenlijk de reden van deze scheiding? Dat er geen sessie-info wordt meegestuurd om plaatjes op te halen wat weer een paar bytes scheelt?

Persoonlijk beschouw ik een website liever als 1 applicatie en heb ik liever alle resources in 1 webdir/domein. Dan kunnen er ook nooit dit soort continuïteitsproblemen ontstaan.

en dat we geen relatief zware software in hoeven te zetten voor iets simpels als een statische file, en dat webbrowsers doordat het aparte domeinen zijn, meerdere requests tegelijk kunnen doen, en dat er geen cookies meegestuurd hoeven worden, en dat we wat aggresievere caching headers eenvoudig kunnen toevoegen, en dat we betere videostreaming support hebben.

Een website als 1 applicatie beschouwen, met 1 webdir/domein is allemaal leuk en aardig, en het kan ook wel, alleen is het performance technisch gewoon niet zo goed.

[LauPro]

We gaan nu waarschijnlijk een technische discussie in. Maar hetzelfde is toch te bereiken met een goede reserve proxy? Op de meerdere requests na dan, maar is dit serieus een issue? Op deze pagina zie ik nog steeds een client parse time van 1,2 seconden (!).

[Kees]

LauPro schreef op zaterdag 24 april 2010 @ 18:08:
We gaan nu waarschijnlijk een technische discussie in. Maar hetzelfde is toch te bereiken met een goede reserve proxy? Op de meerdere requests na dan, maar is dit serieus een issue? Op deze pagina zie ik nog steeds een client parse time van 1,2 seconden (!).

Client parsetime hebben wij weinig invloed op, behalve dan snelle scripts schrijven.

Maar nee, in onze situatie is een reverse proxy redelijk ingewikkeld en is het veel eenvoudiger om een deel van de statische content te verplaatsen naar een ander domein / (software) server. Maar ik denk ook niet dat het probleem daar ligt. Maar waar het wel ligt moet ik nog even goed uitzoeken.

[LauPro]

Kees schreef op zaterdag 24 april 2010 @ 18:13:
Client parsetime hebben wij weinig invloed op, behalve dan snelle scripts schrijven.

Maar nee, in onze situatie is een reverse proxy redelijk ingewikkeld en is het veel eenvoudiger om een deel van de statische content te verplaatsen naar een ander domein / (software) server. Maar ik denk ook niet dat het probleem daar ligt. Maar waar het wel ligt moet ik nog even goed uitzoeken.

Als je geen invloed hebt op client parsetime, waarom dan moeite doen om die paar ms die je wint met requests naar andere domeinen?

Waarom is een reverse proxy ingewikkeld? Pseudo code:

code:

/ -> web.tweakers.net
/img -> img.tweakers.net
/video -> video.tweakers.net

[moto-moi]

LauPro schreef op zaterdag 24 april 2010 @ 18:21:
[...]
Als je geen invloed hebt op client parsetime, waarom dan moeite doen om die paar ms die je wint met requests naar andere domeinen?

Waarom zou je bewust grotere requests gaan verplichten als je daar tijd en bandbreedte kunt afschaven? We hebben geen invloed op de machines die mensen thuis hebben, maar de snelheid dat onze site in ongeparsede vorm heeft, daar hebben we wel invloed op.

Verder denk ik dat je de verkeerde kant op zit te denken met die reversed proxy, de reden dat we tweakimg.net hebben is omdat we dan 100% zeker weten dat we de cookies niet meekrijgen bij elke request, dat zal een reversed proxy niet voorkomen.
Onze site is gewoon niet simpel in 1 techniek te vatten, daarvoor is hij te groot en stellen we te hoge eisen aan onze software.

[ACM]

LauPro schreef op zaterdag 24 april 2010 @ 18:21:

code:

/ -> web.tweakers.net
/img -> img.tweakers.net
/video -> video.tweakers.net

Euh... maar dat is toch precies wat we nu al hebben? Met dien verstande dat we er een aparte domeinnaam aan gekoppeld hebben zodat we ook nog eens cookie-free domains erbij krijgen en het gros van de requests die een gebruiker doet een stuk kleiner zijn geworden.
Vergeet niet dat als je 400 bytes aan cookies verstuurd en dat voor 50 requests moet doen, dat je toch alweer 20KB aan data verzend. En met 1Mbit upload is dat al minimaal 0.2 seconde die dan domweg verspild wordt aan het versturen van cookies die voor de betreffende requests overbodig zijn... Ik geloof dat de cookies die wij ondertussen (zeker icm google analytics enzo) verzameld hebben boven de 400 bytes uitkomen en als je een first-time visitor bent of een refresh doet krijg je ook meer dan 50 requests. Dus het zijn geen enorm merkbare winsten, maar alle beetjes helpen.
Als we dan toch een nieuw domein moeten maken, is een compleet nieuw domein net zo simpel beheren en heeft dus nog een beetje extra voordeel ivm kleinere requests die daarnaast voor proxies beter centraal te cachen zijn.

Ik wil je overigens verwijzen naar deze twee .plans:
plan: Afbeeldingen voortaan geserveerd via Tweakimg.net
plan: Content-afbeeldingen voortaan via ic.tweakimg.net

Dat scheelt ons de off-topic discussie opnieuw voeren

[ Voor 14% gewijzigd door ACM op 24-04-2010 18:38 ]

[LauPro]

moto-moi schreef op zaterdag 24 april 2010 @ 18:30:
Waarom zou je bewust grotere requests gaan verplichten als je daar tijd en bandbreedte kunt afschaven? We hebben geen invloed op de machines die mensen thuis hebben, maar de snelheid dat onze site in ongeparsede vorm heeft, daar hebben we wel invloed op.

ACM schreef op zaterdag 24 april 2010 @ 18:31:
Vergeet niet dat als je 400 bytes aan cookies verstuurd en dat voor 50 requests moet doen, dat je toch alweer 20KB aan data verzend. En met 1Mbit upload is dat al minimaal 0.2 seconde die dan domweg verspild wordt aan het versturen van cookies die voor de betreffende requests overbodig zijn...

Lieve Adjes toch; 400 bytes op een request van 100.000+ bytes zet toch geen zoden aan de dijk . Toen ik hier net kwam als naïef LauProtje was ik van dat standpunt overtuigd . In een gemiddelde HTML-pagina zit al meer dan 400 bytes aan whitespace .

Verder denk ik dat je de verkeerde kant op zit te denken met die reversed proxy, de reden dat we tweakimg.net hebben is omdat we dan 100% zeker weten dat we de cookies niet meekrijgen bij elke request, dat zal een reversed proxy niet voorkomen.

Ik ondermijn dus dat hele concept dus dat argument gaat niet op.

Ik wil je overigens verwijzen naar deze twee .plans:
plan: Afbeeldingen voortaan geserveerd via Tweakimg.net
plan: Content-afbeeldingen voortaan via ic.tweakimg.net

Deze heb ik beide gelezen destijds en ik was verbaasd.

[Kees]

LauPro schreef op zaterdag 24 april 2010 @ 19:57:
[...]

[...]
Lieve Adjes toch; 400 bytes op een request van 100.000+ bytes zet toch geen zoden aan de dijk . Toen ik hier net kwam als naïef LauProtje was ik van dat standpunt overtuigd . In een gemiddelde HTML-pagina zit al meer dan 400 bytes aan whitespace .

Lieve LauPro, het gaat om een request, niet om een response.
Het gaat om wat jij naar ons toe zend over je (vaak tragere) upload, niet wat jij download. Een request voor dit topic zorgt ervoor dat ik 1238 bytes upload naar de servers om vervolgens dit topic terug te krijgen. Van die 1238 bytes worden er 733 gebruikt om mijn Cookie header te vullen. Als ik deze request zonder cookie doe, scheelt dat dus 60% aan upload. Stel nu dat ik 100 requests moet doen (ik heb 100 ppp, en dus zie ik ook 100 usericons, dus zo gek is dat niet). 100 requests * 1238 bytes = 120kilobytes die ik moet uploaden naar de server. Met een upload van 1 mbit ben ik dus bijna een seconde bezig om alleen maar deze pagina te requesten. Als ik geen cookies mee hoef te sturen bij 99 van mijn requests, dan scheelt mij dat dus 0.6 seconden, en dat is best veel.

Verder kunnen we wel een reverse proxy gebruiken, maar dan hebben we wel het 'probleem' dat wij geen caching mogen toestaan op afgesloten gedeeltes van de site, want dan wordt hij door de reverse proxy gecached, en kan in principe iedereen ineens die pagina/plaatje/video bekijken ook al hebben ze er geen rechten toe. Dus voor die content voegt het alleen maar extra overhead toe, want je connect met de proxy, die ziet dat hij er geen cache van heeft (of mag hebben) en stuurt je dus weer door naar apache. En in een samenleving waar elke miliseconde telt, is dat gewoon overhead die uitstekend op deze manier te vermijden is.

Ik ondermijn dus dat hele concept dus dat argument gaat niet op.
[...]
Deze heb ik beide gelezen destijds en ik was verbaasd.

Ik ondermijn jouw ondermijning van onze onderbouwing, dus het concept gaat wel weer op!

[crisp]

LauPro schreef op zaterdag 24 april 2010 @ 18:08:
[...] Op deze pagina zie ik nog steeds een client parse time van 1,2 seconden (!).

Uit deze opmerking maak ik op dat je een client parsetijd van 1,2 seconden blijkbaar veel vind? Ik zou zeggen: installeer eens een plugin die waterfall charts kan maken van je HTTP verkeer en ga eens op verschillende sites kijken wat de tijd is tussen start rendering van je browser en 'dom ready' (dat is wat wij feitelijk weergeven als clientside parsetime).

Overigens zit in die 1,2 seconden ook nog het ophalen van o.a. de adsense ads en soms zelfs een request naar doubleclick. Analytics doen we sinds kort asynchroon, maar dat zat er voorheen ook nog bij. Het is dus niet zo dat het ook 1,2 seconden duurt voordat de content beschikbaar is - zeker niet bij een gevulde ('primed') cache.

LauPro schreef op zaterdag 24 april 2010 @ 19:57:
[...] Lieve Adjes toch; 400 bytes op een request van 100.000+ bytes zet toch geen zoden aan de dijk

400 bytes per request En de meeste resources die je opvraagt (van o.a. tweakimg.net) zijn aanzienlijk kleiner dan 100.000+ bytes. Daarbij gebruiken we uiteraard ook HTTP compressie voor dingen als css en javascripts.

[ Voor 7% gewijzigd door crisp op 24-04-2010 20:39 ]

[LauPro]

Kees schreef op zaterdag 24 april 2010 @ 20:19:
Lieve LauPro, het gaat om een request, niet om een response.
Het gaat om wat jij naar ons toe zend over je (vaak tragere) upload, niet wat jij download. Een request voor dit topic zorgt ervoor dat ik 1238 bytes upload naar de servers om vervolgens dit topic terug te krijgen. Van die 1238 bytes worden er 733 gebruikt om mijn Cookie header te vullen. Als ik deze request zonder cookie doe, scheelt dat dus 60% aan upload. Stel nu dat ik 100 requests moet doen (ik heb 100 ppp, en dus zie ik ook 100 usericons, dus zo gek is dat niet). 100 requests * 1238 bytes = 120kilobytes die ik moet uploaden naar de server. Met een upload van 1 mbit ben ik dus bijna een seconde bezig om alleen maar deze pagina te requesten. Als ik geen cookies mee hoef te sturen bij 99 van mijn requests, dan scheelt mij dat dus 0.6 seconden, en dat is best veel.

Lieve Kees
• De TCP window size MTU is doorgaans maximaal 1500 Bytes. Het maakt voor packet switching niet uit of je nu 400 of 1200 bytes stuurt, het hele packet komt toch in een buffer.
• Een goede browser zou plaatjes die gecached zijn en niet verlopen gewoon lekker met rust moeten laten op de server, dus deze complete laadtijd geld alleen de eerste keer dat een bezoeker een website bezoekt.
• Is het niet zo dat met keepalive http-sessie een cookie-request maar 1 keer langs komt?

Verder kunnen we wel een reverse proxy gebruiken, maar dan hebben we wel het 'probleem' dat wij geen caching mogen toestaan op afgesloten gedeeltes van de site, want dan wordt hij door de reverse proxy gecached, en kan in principe iedereen ineens die pagina/plaatje/video bekijken ook al hebben ze er geen rechten toe. Dus voor die content voegt het alleen maar extra overhead toe, want je connect met de proxy, die ziet dat hij er geen cache van heeft (of mag hebben) en stuurt je dus weer door naar apache. En in een samenleving waar elke miliseconde telt, is dat gewoon overhead die uitstekend op deze manier te vermijden is.

Je kan gewoon bepaalde gedeeltes uitsluiten van de proxy, en dan gaat dat inderdaad het nut van de proxy voorbij, maar jullie hebben toch ook load balancers? Deze functie zou te combineren moeten zijn.

[ACM]

[quote]LauPro schreef op zaterdag 24 april 2010 @ 21:17:
• De TCP window size is doorgaans maximaal 1500 Bytes. Het maakt voor packet switching niet uit of je nu 400 of 1200 bytes stuurt, het hele packet komt toch in een buffer.
Hoe je het ook wendt of keert, er zit een verschil in verzendtijd. Ongeacht of de buffer wel of niet beide maten packets kan houden. Het is daarbij overigens wel zo dat packets een bepaalde vaste component in hun verzendtijd hebben en/of dat de grootte en verzendtijd niet volledig lineair gekoppeld zijn.
Daar komt overigens nog bij dat er nog altijd mensen zijn met een MTU van 576 bytes (lijkt er zelfs op dat het er relatief veel zijn) en daarbij maakt het natuurlijk helemaal uit als we het voor elkaar krijgen om fragmentatie te voorkomen.

[q]• Een goede browser zou plaatjes die gecached zijn en niet verlopen gewoon lekker met rust moeten laten op de server, dus deze complete laadtijd geld alleen de eerste keer dat een bezoeker een website bezoekt.
Klopt, of als je op f5 drukt... En veel mensen die een pagina willen verversen drukken op f5 (ipv de veel efficientere alt+d,enter)

[q]• Is het niet zo dat met keepalive http-sessie een cookie-request maar 1 keer langs komt?
Ik kan het me eigenlijk niet voorstellen dat een halve request gedaan zou mogen worden. Maar daar heb ik nooit onderzoek naar gedaan.

Je kan gewoon bepaalde gedeeltes uitsluiten van de proxy, en dan gaat dat inderdaad het nut van de proxy voorbij, maar jullie hebben toch ook load balancers? Deze functie zou te combineren moeten zijn.

Maar dat suggereert dat het nodig is. Je stelt onze huidige aanpak hier uitgebreid aan de kaak en probeert ons zelfs een beetje belachelijk te maken. Maar je geeft alleen maar redenen waarom de cookie-less-domains niet uit zouden maken, je noemt geen nadelen, hooguit dat de voordelen niet heel significant zijn... Verder moeten we in elke variant met reverse proxies en/of snellere statische-file-servers een of andere selectie doen. Nu hebben we dat gedaan door gewoon de html zo te prepareren dat browsers het vanzelf goed doen en hebben we automatisch eventuele voordelen van cookie-free-domains meegepakt.

Overigens blijft dit allemaal nogal offtopic en de aandacht afleiden van de issue die wel relevant is/was hier.

Slasher schreef op zaterdag 24 april 2010 @ 21:34:
Kees bedankt voor je inspanning het werkt hier weer prima!

Laten we dan inderdaad hopen dat het nu niet toevallig even weg is terwijl de issue eigenlijk niet gevonden is

[LauPro]

ACM schreef op zaterdag 24 april 2010 @ 22:11:
Hoe je het ook wendt of keert, er zit een verschil in verzendtijd. Ongeacht of de buffer wel of niet beide maten packets kan houden.

Dit punt is mij duidelijk. Eerlijk gezegd vind ik 400-733 bytes aan cookies echt idioot veel. Ik zou altijd proberen (als je echt wil gaan optimaliseren) om zo'n HTTP-request binnen de MTU te houden. Meerdere frames moeten worden gesynced en dat is per definitie altijd langzamer, zeker over het relatief trage internet.

Tevens maakt met 1 KB+ aan cookie-informatie je debugging ook buitengewoon ingewikkeld.

1) Mijn eerste doel zou zijn om de cookies echt te gaan beperken tot het strikt noodzakelijke.

Klopt, of als je op f5 drukt... En veel mensen die een pagina willen verversen drukken op f5 (ipv de veel efficientere alt+d,enter)

Hier ligt dus nog een optimalisatie bij de browsers, afaik hebben veel browsers een soft reload en een hard/forced reload (vaak dmv modifier key, Ctrl+F5 in IE bijv.).

Ik kan het me eigenlijk niet voorstellen dat een halve request gedaan zou mogen worden. Maar daar heb ik nooit onderzoek naar gedaan.

Ik meen ooit te hebben gelezen dat je browsers bepaalde HTTP-headers kan laten filteren juist om dit soort problemen te voorkomen. Dit zou ik eerlijk gezegd ook moeten uitzoeken.

Maar dat suggereert dat het nodig is. Je stelt onze huidige aanpak hier uitgebreid aan de kaak en probeert ons zelfs een beetje belachelijk te maken. Maar je geeft alleen maar redenen waarom de cookie-less-domains niet uit zouden maken, je noemt geen nadelen, hooguit dat de voordelen niet heel significant zijn... Verder moeten we in elke variant met reverse proxies en/of snellere statische-file-servers een of andere selectie doen. Nu hebben we dat gedaan door gewoon de html zo te prepareren dat browsers het vanzelf goed doen en hebben we automatisch eventuele voordelen van cookie-free-domains meegepakt.

Het was niet mijn bedoeling om jullie belachelijk te maken, ik stel hier gewoon een punt ter discussie.

Ik zie symptoombestreiding ontstaan, en vervolgens een oplossing die imo niet optimaal is.

2) Als het zo is dat je je cookie-informatie niet kan verkleinen, en er een cookie free domein tegenaan moet gooien dan zie ik nog steeds niet de meerwaarde van een aparte webserver, andere webserver. Ik zou lekker in Apache aan de vhost het cookie free domain hangen en in de HTML het onderscheid maken. Op die manier hou je 1 applicatiedomein/webdir.

quote: http://acm.tweakblogs.net...-cookie-free-domains.html

Furthermore, Lighttpd and Varnish are both slightly faster than Apache with these kind of requests and for many of the requests that are now handled by ic.tweakimg.net, we skip some additional php-processing.

3) Als er weinig verschil aanwezig is tussen de verschillende webservers, en voor public plaatjes in principe geen php-verwerking nodig is, dan zie ik nogmaals geen nut van een compleet losse webserver, hiermee maak je een systeem alleen maar nodeloos complex en storingsgevoelig. Als het zo is dat plaatjes nu altijd via een php-script worden aangeleverd dan is het denk ik zaak om dat eerst eens static op een webserver te zetten.

Liever zie ik deze caching in een proxy gebeuren met idioot veel ram.

[ACM]

LauPro schreef op dinsdag 27 april 2010 @ 14:59:
Eerlijk gezegd vind ik 400-733 bytes aan cookies echt idioot veel.

Sja, het nadeel van willen weten waar je bezoekers zoal kijken en het hebben van advertenties. En ga nou niet daar ook weer van alles bij bekritiseren, we hebben nou eenmaal gekozen voor Google Analytics en zitten min of meer vast aan Doubleclick... dus een groot deel van die cookies hebben we daardoor relatief weinig invloed op. En ja, imho is Google Analytics ook overdreven scheutig met de data die ze in cookies schrijven.

Ik zou altijd proberen (als je echt wil gaan optimaliseren) om zo'n HTTP-request binnen de MTU te houden. Meerdere frames moeten worden gesynced en dat is per definitie altijd langzamer, zeker over het relatief trage internet.

Zolang de MTU 1500 is lukt dat vrijwel altijd wel. Met een MTU van 576, die sommige gebruikers hebben, is het sowieso een stuk lastiger en een paar honderd bytes aan cookies kan dan net de grens zijn.

1) Mijn eerste doel zou zijn om de cookies echt te gaan beperken tot het strikt noodzakelijke.

Doen we allang, voor zover we er dus invloed op hebben

Hier ligt dus nog een optimalisatie bij de browsers, afaik hebben veel browsers een soft reload en een hard/forced reload (vaak dmv modifier key, Ctrl+F5 in IE bijv.).

Bij een soft reload gaan ze vragen of resources veranderd zijn... En dus moeten ze een request doen en dus cookies meesturen. Bij een hard reload halen ze gewoon alles opnieuw op en doen ze dus voor alles een request

Ik zie symptoombestreiding ontstaan, en vervolgens een oplossing die imo niet optimaal is.

Het symptoom is dat browsers voor elke request cookies meesturen als het naar een bepaald domein is. Aangezien we toch efficientere static webservers wilden kunnen inzetten, hebben we dat gecombineerd met een cookie-free domain. Zo'n gekke keus is dat toch niet? Die 15 euro per jaar aan dns-kosten is ook niet bepaald een serieuze kostenpost voor ons en het heeft, vziw, verder geen nadelen.

2) Als het zo is dat je je cookie-informatie niet kan verkleinen, en er een cookie free domein tegenaan moet gooien dan zie ik nog steeds niet de meerwaarde van een aparte webserver, andere webserver. Ik zou lekker in Apache aan de vhost het cookie free domain hangen en in de HTML het onderscheid maken. Op die manier hou je 1 applicatiedomein/webdir.

Apache is sloom, lomp, etc. Lighttpd is veel efficienter met statische bestanden. Overigens verwar jij losse servers met losse applicatiedomeinen etc... Ze werken gewoon vanuit dezelfde directory en de varnishes gebruiken gewoon de Apache's als backend.
Sterker nog, we kunnen gewoon de loadbalancer zo configureren dat die ip's weer naar de apache's wijzigen en dan gaat het ook gewoon goed Alleen zijn we dan dus de winst van caches lokaal op de servers en de veel efficientere webservers voor statisch werk kwijt.

3) Als er weinig verschil aanwezig is tussen de verschillende webservers, en voor public plaatjes in principe geen php-verwerking nodig is, dan zie ik nogmaals geen nut van een compleet losse webserver, hiermee maak je een systeem alleen maar nodeloos complex en storingsgevoelig. Als het zo is dat plaatjes nu altijd via een php-script worden aangeleverd dan is het denk ik zaak om dat eerst eens static op een webserver te zetten.

De losse server is net zo handig als geen losse server... Jij lijkt te denken dat we er vreselijk veel moeite voor hebben moeten doen om dit zo te implementeren. Maar de 'static' servers leveren gewoon de boel uit dezelfde webroot vanuit dezelfde fysieke machines. Alleen dan met efficientere code.
Later bedachten we idd dat het niet zo handig is om de nfs-server steeds te benaderen met die php-geselecteerde afbeeldingen die in de content staan (het is weinig meer dan file_exists en readfile als de goede maat afbeelding al bestaat)... Dus daar hebben we toen een reverse proxy bij gezocht.

Voordeel van deze situatie is dat we de reverse proxy en de static content servers dedicated in kunnen zetten en ze zo dus gescheiden configuraties houden. Dat houdt het dus juist eenvoudiger

Liever zie ik deze caching in een proxy gebeuren met idioot veel ram.

Och, met een 5GB disk-cache zitten ze standaard op een gebruik van nog geen 4GB en hebben ze een hit-ratio van ruim 99%. Dus zoveel ram hebben ze niet nodig hoor, onze webservers hebben overigens aardig wat ram, juist mede vanwege deze reden, waardoor we daar voorlopig geen dedicated machines voor in hoeven te zetten

[Kees]

LauPro schreef op dinsdag 27 april 2010 @ 14:59:
[...]
2) Als het zo is dat je je cookie-informatie niet kan verkleinen, en er een cookie free domein tegenaan moet gooien dan zie ik nog steeds niet de meerwaarde van een aparte webserver, andere webserver. Ik zou lekker in Apache aan de vhost het cookie free domain hangen en in de HTML het onderscheid maken. Op die manier hou je 1 applicatiedomein/webdir.

[...]
3) Als er weinig verschil aanwezig is tussen de verschillende webservers, en voor public plaatjes in principe geen php-verwerking nodig is, dan zie ik nogmaals geen nut van een compleet losse webserver, hiermee maak je een systeem alleen maar nodeloos complex en storingsgevoelig. Als het zo is dat plaatjes nu altijd via een php-script worden aangeleverd dan is het denk ik zaak om dat eerst eens static op een webserver te zetten.

Liever zie ik deze caching in een proxy gebeuren met idioot veel ram.

Een aantal plaatjes worden on-demand geconverteerd (en daarna opgeslagen) zoals thumbnails. Daar gebruiken we juist een reverse proxy voor zodat die plaatjes 1 keer aan apache gevraagt worden en dan in de cache hangen.

Verder is apache als statische webserver gebruiken, met een aparte vhost nogal.. slecht. Apache heeft per request veel meer resources nodig dan lighttpd (helemaal als je ook php modules e.d. geladen hebt). Hierdoor kun je al snel een factor 10(!!) verschil zien in het aantal requests/seconde dat ze kunnen afhandelen. Verder willen we op apache keepalive niet aan hebben staan voor alle connecties, en dat kan juist wel aan op lighttpd en varnish.