CDN dmv Vhosts/subdomains op Apache?

[McKaamos]

Hi all!

Sinds kort ben ik me wat meer aan het verdiepen in het sneller maken van websites.
Met een hoop ge-google kwam ik de term CDN, aka Content Delivery Network, tegen.
Kortgezegd: Plaats statische content op een andere locatie dan de dynamische content en je eigen domein, bestanden worden paralel gedownload en dat geeft een snelheidsboost.

Er blijken al een tal van dergelijke services te zijn, maar ik dacht: waarom zou je zoiets niet versimpelen en dan zelf doen?

Normaal HTTP verkeer gaat via 'serieel', eventueel met gebruik van keep-alives om het maken en verbreken van de HTTP verbinding tot een minimum te beperken en je downloads dus wat sneller te maken.

Als CDN dient om je downloads paralel te maken, waarom zou je dat dan niet simuleren door je domeinnaam te voorzien van subdomains als 'js.website.tld', 'css.website.tld' en 'img.website.tld'?
Maak een aantal Vhosts binnen Apache, knoop je subdomeinen er aan en programmeer je website zo dat hij plaatjes, css en javascript van drie verschillende locaties trekt?
Eventueel knoop je de document-root van die subdomains rechtstreeks aan de al bestaande mappen '/img', '/js' en '/css' van je website.

Hang daar dan binnen Apache ook nog eens memory caching aan, en je zou bliksemsnelle paralelle downloads krijgen.

De hamvraag is echter: Gaat Apache dit accepteren? De requests komen vanaf een enkel IP adres en komen ook uit bij een enkel IP adres. Zal hij dat gaan zien als één connectie, of maakt hij daadwerkelijk meerdere connecties?

Heeft iemand dit al eens geprobeerd? Of kan iemand mij verlichten met een inzage in hoe Apache dit zou behandelen?

[orf]

Te veel losse (sub)domeinen is ook niet goed, daar moeten DNS lookups voor gedaan worden. Zeker goed om voor je statische content een apart domein of subdomein te gebruiken. Een apart domein kan beter zijn dan een apart subdomein vanwege cookies. Het scheelt data en dus snelheid als cookies niet meegezonden worden bij requests naar statische data.

Als je een pagina opent op Tweakers zie je dat tweakimg gebruikt wordt voor statische content.

Wij (en Tweakers volgens mij ook) gebruiken Varnish voor het serveren van statische content (als caching proxy). Ook wel voor dynamische content, maar daar is de meerwaarde minder groot. Varnish is echt veel sneller dan Apache. Ook een andere webserver zoals bijvoorbeeld Nginx of Lighttpd kan goed werken voor statische content.

[Verwijderd]

McKaamos schreef op maandag 01 juli 2013 @ 20:17:

Sinds kort ben ik me wat meer aan het verdiepen in het sneller maken van websites.
Met een hoop ge-google kwam ik de term CDN, aka Content Delivery Network, tegen.
Kortgezegd: Plaats statische content op een andere locatie dan de dynamische content en je eigen domein, bestanden worden paralel gedownload en dat geeft een snelheidsboost.

Vergeet even niet dat bij een degelijk CDN je er gebruik van maakt dat statische content makkelijk verspreid kan worden over vele locaties (verdeeld over de gehele wereld) en dat op die manier de content bijna gegarandeerd dichter bij de eindgebruiker is. Minder hops, minder latency.

Er blijken al een tal van dergelijke services te zijn, maar ik dacht: waarom zou je zoiets niet versimpelen en dan zelf doen?
Normaal HTTP verkeer gaat via 'serieel', eventueel met gebruik van keep-alives om het maken en verbreken van de HTTP verbinding tot een minimum te beperken en je downloads dus wat sneller te maken.

Dat is kort door de bocht. Een gevaar van keep-alive is dat het lang niet altijd voordeel oplevert. Je wilt normaal gesproken geen keep-alive op een applicatieserver die slechts weinig request serveert en waar telkens enige tijd tussen requests zit. Een applicatieserver gebruikt doorgaans meer geheugen en kan zo minder gelijktijdige requests aan dan een server die is geoptimaliseerd voor een achterlijk aantal gelijktijdige connecties waarvoor per connectie weinig werk hoeft te worden gedaan. Met name weinig werk dat blocking is, en niet geparalleliseerd kan worden.

Als CDN dient om je downloads paralel te maken, waarom zou je dat dan niet simuleren door je domeinnaam te voorzien van subdomains als 'js.website.tld', 'css.website.tld' en 'img.website.tld'?
Maak een aantal Vhosts binnen Apache, knoop je subdomeinen er aan en programmeer je website zo dat hij plaatjes, css en javascript van drie verschillende locaties trekt?
Eventueel knoop je de document-root van die subdomains rechtstreeks aan de al bestaande mappen '/img', '/js' en '/css' van je website.

Dat is een bijkomend voordeel, maar niet het belangrijkst van een CDN. Dichtbij huis en meer geoptimaliseerde servers zijn de hoofdredenen.

Hang daar dan binnen Apache ook nog eens memory caching aan, en je zou bliksemsnelle paralelle downloads krijgen.

Of hang er een nog optimaler geconfigureerde service voor, zoals Varnish.

De hamvraag is echter: Gaat Apache dit accepteren? De requests komen vanaf een enkel IP adres en komen ook uit bij een enkel IP adres. Zal hij dat gaan zien als één connectie, of maakt hij daadwerkelijk meerdere connecties?

Je zou natuurlijk meerdere verschillende IP's kunnen gebruiken. Idealiter gebruik je ook geen subdomeinen maar echt andere domeinen zodat de browser niet slim probeert te doen.

Heeft iemand dit al eens geprobeerd? Of kan iemand mij verlichten met een inzage in hoe Apache dit zou behandelen?

Apache kan dit prima, maar je kijkt er volgens mij nog niet op de juiste manier naar.
Pak overigens de event of worker MPM, niet de prefork.

[McKaamos]

Ik begrijp dat ik de plank een beetje mis sla wat betreft CDN. Daar zitten inderdaad meerdere geografische locaties aan vast en wordt de dichtstbij gelegen node gekozen.
Heel interessant voor een internationale website. Voor mij zou het zich beperken tot Nederland en Vlaams Belgie. Je zou dan nog kunnen kiezen voor een server in Groningen en Eindhoven of Brussel.
Vraag is of dat rendabel is voor zo'n klein plakje van deze aardbol.

Het enige overblijvende voordeel is dan het paralelliseren van downloads.
En ik vroeg me dus af of het zou helpen als je de website opsplitst in subdomains voor diverse soorten content, waardoor al je losse files tegelijk gedownload worden.
Enige echte vraag die dan overblijft is of Apache en/of je webbrowser daar geen stokje voor steekt door alsnog een enkele HTTP connectie neer te zetten.

En ja, keepalives hebben zo hun voor- en nadelen. Daar ben ik me van bewust.
Neemt niet weg dat het meestal wel aan staat bij een webhoster.