PHP CMS opzetten CDN (Content delivery Network)

[juggle]

Beste Tweakers,

Voor ons inhouse ontwikkelde CMS in PHP willen we nu we wat meer gebruikers hebben de layout en scripts centraal gaan opslaan. De topic titel geeft aan dat we een CDN willen opzetten, in de praktijk zal dit niet anders zijn dan een server waarop de layout, javascripts en updates geplaatst worden.

Alvorens over te gaan op de vraag wil ik een situatieschets geven:

Huidige situatie:
Op dit moment wordt er een kopie van ons cms inclusief alle assets op de server van de klant geplaatst. Updates worden handmatig doorgevoerd door ons. Een wijziging in de layout of javascript dient per site te worden doorgevoerd. Wij zijn op dit moment al bezig een automatisch update systeem te ontwikkelen zie dit topic: http://gathering.tweakers...s/1348182///updates%2Ccms

Gewenste situatie:
Alle layout afbeeldingen, javascripts en componenten van derden worden op een centrale server geplaatst en in het cms opgevraagd. HTML sjablonen, PHP scripts en Framework componenten staan op de server van de klant en updates worden met behulp van het centrale update systeem doorgevoerd. De updates staan op deze zelfde server.

Voordelen

• Layout en script wijzigingen zijn door ons centraal en gemakkelijker door te voeren
• Snelheid?, door centrale opslag kunnen klanten met meerdere cms, instanties sneller alle componenten laden
• Minder overhead in update functie. Deze beperkt zich puur en alleen voor systeem updates.

Nadelen

• Centrale opslag is foutgevoeliger, als onze server down is, werken de cms instanties niet. Caching hier de oplossing?
• Snelheid?, door centrale opslag is de snelheid juist lager omdat alle requests naar de zelfde server gaan. Eventueel hier ook met caching op te lossen?
• Onoverzichtelijker in onderhoud, updates via update systeem en scripts en layouts via onze CDN server

Eigenlijk zie ik alleen maar voordelen ipv nadelen. Wellicht dat ik zaken over het hoofd zie? Ik heb geen ervaring met het opzetten van een dergelijk systeem.

Mijn vraag is dus, zijn er Tweakers die hiermee ervaring hebben en eventueel interessante ervaringen kunnen delen?

[CyBeR]

Wat wij doen is, als ik je goed begrijp, soortgelijk.

Wij hebben een service (uitgevoerd op twee servers, hoewel er op dit moment maar een tegelijk actief is, dat wordt binnenkort anders) die we 'static content cache' noemen. Daarop gaat dus content die niet dynamisch gegenereerd is, en die cachet dat automatisch. Ons CMS genereert een URL in de vorm van 'http://static-server/f/rand/image/blah/blahblah.jpg' voor een file die eigenlijk gewoon '/image/blah/blahblah.jpg' heet. Alles daarvoor is een stukje configuratie. De servernaam natuurlijk, en de 'rand' dir is eigenlijk ene serie van vier random karakters, gegenereerd bij het configureren van de static service zelf.

Op het moment dat de static service een request binnenkrijgt voor een nog niet gecachete url, komt de 404 handler in werking die de url bekijkt en aan de hand daarvan (de 4 random chars) opzoekt om welke site 't gaat. De file wordt opgehaald, opgeslagen en doorgestuurd naar de client. De 1e keer is een dergelijk request dus iets langzamer, omdat 't ding eerst opgehaald moet worden bij de webservers. Daarna, echter, staat 't ding lokaal op 't filesystem en is 't serven een kwestie van sendfile() uitvoeren.

Tegenwoordig doen we dat met nginx, een glusterfs backend voor 't fs (zodat een file niet 2x gedownload hoeft te worden, en ook meteen weg is op beide servers als je 'm delete) en om 't retesnel te houden varnish ervoor. Die cachet los van het geheel in geheugen.

Om dingen te purgen is er een api die aangeroepen wordt door ons cms op het moment dat die weet dat er iets veranderd is, bijvoorbeeld de user heeft een plaatje vervangen. Die haalt de file weg op 't filesystem (Glusterfs dus) en stuurt een purge request naar varnish om 'm uit het geheugen te knikkeren.

Dit is in essentie wat CDN's zoals akamai ook doen, alleen dan op een wat kleinere schaal.

Overigens: die static service staat onder ons eigen domein. Dat is geen technische verplichting, maar 't heeft een voordeel omdat de browser dan allerlei dingen veel beter parallel doet en er geen cookies meegestuurd worden e.d.

[juggle]

Hallo CyBeR,

Bedankt voor je uitgebreide antwoord. Ik krijg het idee dat jullie oplossing iets uitgebreider is dan hoe ik het voor ogen heb. Mijn idee is niet om een caching cluster te gaan bouwen. Caching van contentpagina's wordt door het achterliggende framework geregeld op de server van de klant zelf. Eventueel kan memcached worden geactiveerd bij zeer druk bezochte websites.

Ik wil eigenlijk meer de fysieke backend van het cms centraal opslaan. Dus de admin layout afbeeldingen, css en javascripts. Om het simpel te houden zou je ipv:

http://www.website.nl/cms/assets/js/tree.js

iets krijgen als:

http://v2.cms.nl/assets/js/tree.js

[CyBeR]

Aha. Waarom wil je juist de admin-dingen los opslaan dan? Die worden typisch gezien minder vaak gebruikt dan je frontend-assets.

Overigens: ons cms cachet ook dat 't een lieve lust is. Inclusief aangepaste memcached voor nog meer performance, etc. Maar omdat alles via php gaat blijft dat redelijk veel overhead hebben, vandaar dat we een wat onafhankelijkere oplossing hebben gekozen.

[Verwijderd]

Tips:
- Gebruik een lightweight webserver zoals nginx en lighttpd (de laatste gebruik ik)
- Zet expire headers op de bestanden
- Gebruik meerdere hostnames voor bestanden zodat je bijv. cdn1.mycdn.nl, cdn2.mycdn.nl en cdn3.mycdn.nl krijgt

Ik gebruik zelf ook een cdn omdat mijn site over meerdere subdomeinen verdeeld is, dit werkt tot nu toe prima. Voor het cachen van contentpagina's zou ik overigens varnish gebruiken.

Voor meer tips kan je natuurlijk op de page-speed docs kijken en op Yahoo.