Ab heute habe ich mal im Blog ein Experiment gestartet bei dem jeder Besucher teilnimmt. Der Content meines Blogs wird ab sofort über ein CDN zur Verfügung gestellt, dies geschieht für den Webseitenbesucher “hoffentlich” unsichtbar ^^.

Das Experiment ? Warum eigentlich ?

(Anm. Ich habe diesen Absatz vorverlegt, Erklärung was ein CDN ist kommt danach) 
Ich möchte kurzerhand testen wie sich die Auslieferung via CDN auf die Webseite und die Besucher auswirkt, vor allem die Ladezeiten und ggf. entstehenden Fehler interessieren mich. Wenn du das hier also gelesen hast hinterlass mir doch mal ein kurzes Comment wie sich subjektiv die Ladegeschwindigkeit der Seite und der Bilder in den Postings aktuell “anfühlt”.

Das ganze ist für einen Blog wie solariz.de sicherlich nicht notwendig aber als Experimentelle Live Plattform wunderbar dazu geeignet Erfahrungen zu sammeln bevor ich mit solchen Konzepten an Livewebseiten von Kunden trete ;)

Wie geschrieben, bitte ich um Kommentare, gerne auch Anonym, ob Fehler auftreten oder es zu schlechter Performance kommt.

CDN ? Content Delivery Network ? Was das schon wieder ?

Direct Delivery of Content Ein CDN steht für Content Delivery/Distribution Network. Auf deutsch; Inhalt Verteilungs Netzwerk. Im Normalfall besteht eine Webseite aus zahlreichen “Files” wie Grafiken, HTML Dateien, Stylesheets und Javascripts. Diese werden in der Regel beim Besuch eines Benutzers von dessen Webbrowser direkt vom Webserver der Seite geladen. Dies verdeutlicht die erste Grafik auf der rechten Seite.

Dies hat einige Nachteile, einer davon ist das der Webserver ortsgebunden betrieben wird. Der Webserver von solariz.de steht z.B. in Frankfurt am Main. Greife ich nun aus dem Ausland auf die Seite zu muss die Anfrage erst ihren Weg nach FFM finden und die Antwort geht dann ebenso diesen Weg zurück. Man spricht hier von “Hops” je mehr Hops nötig desto schlechter ist in der Regel die erzielte Geschwindigkeit.

Ein weiterer Nachteil ist das bei großen Webseitenprojekten die Besucherzahlen den Betreiber meist dazu zwingen mehrere Webserver betreiben zu müssen da ein einzelner die Menge der Anfragen und des Traffics nicht mehr abarbeiten kann. Wie ein Normaler HomePC kann ein Server eben auch nur eine gewisse Anzahl an gleichzeitigen Aufgaben bewältigen.

image Hier setzt nun die Verteilung des Contents via CDN ein. Anstatt die Anfragen zentral zu sammeln und bearbeiten werden diese nun dezentral versorgt. Ein CDN besteht aus duzenden Servern die meist auf der ganzen Welt verteilt sind. In der Theorie bekommt der Webseitenbesucher nun nicht mehr die Inhalte vom Server in Frankfurt sondern von einem Server aus dem CDN Netzwerk welcher dem Benutzer am nächsten steht. Besucht also jemand aus New York meine Webseite werden die Bilder nicht mehr über den Atlantik geschickt sondern direkt vom CDN Server in New York an den Nutzer geschickt.

Der Vorteil für mich als Webseitenbetreiber ist auch das man Traffickosten einsparen kann. Anstatt das alle User Bilder, Videos und Downloads vom eigenen Server laden wird nun der Traffic auf den CDN Servern generiert. Der eigene Server wird somit entlastet und muss nur die “Masterkopie” bereithalten.

Alles oder nur Häppchen ?

Anders als bei Videoportalen ist bei einer normalen Webseite die Frage was per CDN ausgeliefert wird nicht sehr eindeutig. Man kann entweder die komplette Seite per CDN ausliefern, dies wirft aber auch viel Synchronisationsaufwand in das Projekt. Alternativ kann man ausschließlich Binärinhalte per CDN ausliefern also in der Regel alle Download und Bilder einer Webseite. Dies macht in der Regel auch den Hauptanteil des Traffics einer Normalen Webseite aus. Eine weitere Möglichkeit, für welche auch ich mich entschieden habe, ist das neben den Binarys auch weitere statische Webseitenbestandteile per CDN ausgeliefert werden. Im Normalfall erstellt man eine Webseite einmal und ändert dann nur selten etwas am Layout; Stylesheets und HTML Strukurtemplates sind also fix. Warum diese dann nicht auch in die CDN “Wolke” packen ? Einziger Haken dabei ist die Revisionierung der ganzen Seite. Jeder der schon mal mit Cacheproxys gearbeitet hat kennt das Problem. Es muss etwas an den Stylesheets der Seite geändert werden aber die alten CSS Daten sind noch im Cache und nach wie vor valide. Was hier hilft ist das ansprechen der CSS Daten in Revisionen. Statt wieder eine neue styles.css hochzuladen muss die neue einen anderen Namen tragen, z.B. styles2.css. Wenn man dies beachtet hat man kein Problem mehr damit.

Amazon Logo Diesen Blog unterstützen?
Bestell dir doch etwas bei Amazon. Nutze diesen speziellen Link, es kostet dich nichts extra und für jeden Kauf darüber erhalte ich eine kleine Gutschrift. Danke!
✉ Marco Götze//

Kommentare

noch 31 Einträge