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

Formate: | Größe: Mb
Anmelden mitoder Benutzernamen eingeben

Der Adminblogger
Könntest Du mal was zu den technischen Details sagen? Wie wird Content ins CDN hochgeladen? FTP? SCP? Wie lange dauert es, bis hochgeladener Content über das CDN erreichbar ist?Was kostet das Ganze bei MZIMA?Gruß, Marcel.
Der Adminblogger
Get-Parameter an der URL zum Stylesheet oder JavaScript sind eine schlechte Idee. Browser könnten das dadurch als dynamischen Content betrachten und überhaupt nicht cachen.Besser ist es da die revisionsnummer oder das datum in den dateinamen einzupflegen, z.b. style_12345.css und das dann per mod_rewrite auf die style.css umzubiegen. Wenn man dann noch ordentlich Expire-Header setzt, so dass das ganze z.B. für 2 Jahre beim Client gecached wird, hat man schon ne Menge gewonnen.Gruß, Marcel.
Der Adminblogger
Könntest Du mal was zu den technischen Details sagen? Wie wird Content ins CDN hochgeladen? FTP? SCP? Wie lange dauert es, bis hochgeladener Content über das CDN erreichbar ist?

Was kostet das Ganze bei MZIMA?

Gruß,
Marcel.
Der Adminblogger
Get-Parameter an der URL zum Stylesheet oder JavaScript sind eine schlechte Idee. Browser könnten das dadurch als dynamischen Content betrachten und überhaupt nicht cachen.

Besser ist es da die revisionsnummer oder das datum in den dateinamen einzupflegen, z.b. style_12345.css und das dann per mod_rewrite auf die style.css umzubiegen. Wenn man dann noch ordentlich Expire-Header setzt, so dass das ganze z.B. für 2 Jahre beim Client gecached wird, hat man schon ne Menge gewonnen.

Gruß,
Marcel.
Der Adminblogger
Könntest Du mal was zu den technischen Details sagen? Wie wird Content ins CDN hochgeladen? FTP? SCP? Wie lange dauert es, bis hochgeladener Content über das CDN erreichbar ist?Was kostet das Ganze bei MZIMA?Gruß,Marcel.
Der Adminblogger
Get-Parameter an der URL zum Stylesheet oder JavaScript sind eine schlechte Idee. Browser könnten das dadurch als dynamischen Content betrachten und überhaupt nicht cachen.Besser ist es da die revisionsnummer oder das datum in den dateinamen einzupflegen, z.b. style_12345.css und das dann per mod_rewrite auf die style.css umzubiegen. Wenn man dann noch ordentlich Expire-Header setzt, so dass das ganze z.B. für 2 Jahre beim Client gecached wird, hat man schon ne Menge gewonnen.Gruß,Marcel.
solariz
Naja solang der server vom Nachbar Weltweit schnell erreichbar ist, ist`s mir recht ^^
Marvin
>> um 90% zurück gegangen sind folglich kommen sie von woanderst.
Hehe, das kann auch der Server des Nachbarn bewirken ;)
★Marco Gö†ze
Was ySlow angeht ist das ganz einfach ;) ySlow kennt nur einige wenige CDN`s siehe dazu die FAQ by yahoo: developer.yahoo.com/faq.htmll#faq_cdn... ist auch recht simple da man auch alleine in den eigenen Apache Logs erkennt das seit Aktivierung des CDN die Hit`s der Seite um 90% zurück gegangen sind folglich kommen sie von woanderst. Auch das sie tatsächlich in mehreren Ländern stehen ist mit Pagespeed Measurement Services aus anderen Ländern relativ einfach aufzeigbar. So hatte ich Vorher bei Messungen aus der USA 10 - 15 Sekunden, dies hat sich nun auf 3-5 reduziert.Das einzige was mich momentan noch beschäftigt ist wie ich herausfinde, nichtmal unbedingt bei mir, wo der DNS Alias mich gerade hinroutet. Der A bzw. CNAME zeigt immer auf einen der CDN Master die Umleitung erfolgt dort aber auch nicht per Header redirect das würde ja eine andere IP bedeuten sondern per IPv4 Sourcerouting, darüber gibt es Bücher mit 300+ Seiten ^^ Muss mich da mal einlesen.
★Marco Gö†ze
Naja solang der server vom Nachbar Weltweit schnell erreichbar ist, ist`s mir recht ^^
Marvin
>> um 90% zurück gegangen sind folglich kommen sie von woanderst. Hehe, das kann auch der Server des Nachbarn bewirken ;)
solariz
Was ySlow angeht ist das ganz einfach ;) ySlow kennt nur einige wenige CDN`s siehe dazu die FAQ by yahoo: developer.yahoo.com/faq.htmll#faq_cdn

Nachweisen ist auch recht simple da man auch alleine in den eigenen Apache Logs erkennt das seit Aktivierung des CDN die Hit`s der Seite um 90% zurück gegangen sind folglich kommen sie von woanderst. Auch das sie tatsächlich in mehreren Ländern stehen ist mit Pagespeed Measurement Services aus anderen Ländern relativ einfach aufzeigbar. So hatte ich Vorher bei Messungen aus der USA 10 - 15 Sekunden, dies hat sich nun auf 3-5 reduziert.

Das einzige was mich momentan noch beschäftigt ist wie ich herausfinde, nichtmal unbedingt bei mir, wo der DNS Alias mich gerade hinroutet. Der A bzw. CNAME zeigt immer auf einen der CDN Master die Umleitung erfolgt dort aber auch nicht per Header redirect das würde ja eine andere IP bedeuten sondern per IPv4 Sourcerouting, darüber gibt es Bücher mit 300+ Seiten ^^ Muss mich da mal einlesen.
★Marco Gö†ze
Was ySlow angeht ist das ganz einfach ;) ySlow kennt nur einige wenige CDN`s siehe dazu die FAQ by yahoo:developer.yahoo.com/ysl.l...Nachweisen ist auch recht simple da man auch alleine in den eigenen Apache Logs erkennt das seit Aktivierung des CDN die Hit`s der Seite um 90% zurück gegangen sind folglich kommen sie von woanderst. Auch das sie tatsächlich in mehreren Ländern stehen ist mit Pagespeed Measurement Services aus anderen Ländern relativ einfach aufzeigbar. So hatte ich Vorher bei Messungen aus der USA 10 - 15 Sekunden, dies hat sich nun auf 3-5 reduziert.Das einzige was mich momentan noch beschäftigt ist wie ich herausfinde, nichtmal unbedingt bei mir, wo der DNS Alias mich gerade hinroutet. Der A bzw. CNAME zeigt immer auf einen der CDN Master die Umleitung erfolgt dort aber auch nicht per Header redirect das würde ja eine andere IP bedeuten sondern per IPv4 Sourcerouting, darüber gibt es Bücher mit 300+ Seiten ^^ Muss mich da mal einlesen.
Marvin
Hehe, wie kannst du dir erklären, dass YSlow bei all deinen Bildern und CSS-Dateien das gier ausgibt: "There are 42 static components that are not on CDN."

Deswegen auch meine Nachfrage, wie kannst überhaupt nachweisen bzw. feststellen, dass dein CDN-Provider auch das tut, was er verspricht... IP ist nicht alles, IP kann jeder abweichende Server haben, heißt nicht, dass die Daten aus einem CDN-Verbund kommen.
Marvin
Hehe, wie kannst du dir erklären, dass YSlow bei all deinen Bildern und CSS-Dateien das gier ausgibt: "There are 42 static components that are not on CDN."Deswegen auch meine Nachfrage, wie kannst überhaupt nachweisen bzw. feststellen, dass dein CDN-Provider auch das tut, was er verspricht... IP ist nicht alles, IP kann jeder abweichende Server haben, heißt nicht, dass die Daten aus einem CDN-Verbund kommen.
solariz
Feststellen das die Bilder vom CDN Server kommen kann man recht einfach, der Hostname der Bilder bzw Files wird geändert somit kommen hier bei mir nun alle Daten von cdn1.solariz.de welcher von der IP nicht mehr auf meinen Server zeigt sondern auf einen Masterserver des CDN Betreibers.

Wie ich nun jedoch genau feststelle von welchem Server im CDN Netz die Antworten kommen ist ohne Hilfsmittel des Providers nicht so einfach da ja eben alles versteckt im Hintergrund abläuft. So 100% habe ich das noch nicht raus bin aber dabei mich in der Materie gerade etwas einzuarbeiten. Wer hier gute Lektüre empfehlen kann immer her damit ;)

Vom CDN Betreiber selbst, in meinem Fall NetDNA, habe ich eine übersicht welcher der 16 Server wieviele Anfragen an welchem Tag bearbeitet hat. NetNDA habe ich gewählt da diese eine Trialphase anbieten. Rein Technisch wären andere Anbieter besser aufgestellt denn NetNDA hat in EU nur einen Server stehen was bei 75% nutzern aus EU also eigentlich quatsch ist. Alternativ gibt es noch das Coral CDN hier bekommt man aber exakt null statistische Informationen und genau um die geht es mir im test ja. Naja mal sehen Amazon S3 wäre noch ne möglichkeit, ich steig da aber noch nicht durch die Tarife durch. Für Privatwebseitenbetreiber lohnt es sich meist nicht da die meisten CDN betreiber mindestens 1Terabyte pro Monat abrechnen, ganz soviel hab ich dann noch nicht ;)

Ich bleib mal drann und schau was ich da noch für infos bekomme, wollte am Wochenende mal meine ersten Eindrück in einem Blogpost summieren.
Marvin
Kennst du vielleicht einen Online-Dienst, der dir zeigen kann, in welchem Land der Server für die angeforderte Datei aus einem CDN-Netzwerk angesprungen ist? Oder wie stellst du fest, ob es tatsächlich funktioniert ;)
★Marco Gö†ze
Feststellen das die Bilder vom CDN Server kommen kann man recht einfach, der Hostname der Bilder bzw Files wird geändert somit kommen hier bei mir nun alle Daten von cdn1.solariz.de welcher von der IP nicht mehr auf meinen Server zeigt sondern auf einen Masterserver des CDN Betreibers.Wie ich nun jedoch genau feststelle von welchem Server im CDN Netz die Antworten kommen ist ohne Hilfsmittel des Providers nicht so einfach da ja eben alles versteckt im Hintergrund abläuft. So 100% habe ich das noch nicht raus bin aber dabei mich in der Materie gerade etwas einzuarbeiten. Wer hier gute Lektüre empfehlen kann immer her damit ;)Vom CDN Betreiber selbst, in meinem Fall NetDNA, habe ich eine Übersicht welcher der 16 Server wieviele Anfragen an welchem Tag bearbeitet hat. NetNDA habe ich gewählt da diese eine Trialphase anbieten. Rein Technisch wären andere Anbieter besser aufgestellt denn NetNDA hat in EU nur einen Server stehen was bei 75% nutzern aus EU also eigentlich quatsch ist. Alternativ gibt es noch das Coral CDN hier bekommt man aber exakt null statistische Informationen und genau um die geht es mir im test ja. Naja mal sehen Amazon S3 wäre noch ne möglichkeit, ich steig da aber noch nicht durch die Tarife durch. Für Privatwebseitenbetreiber lohnt es sich meist nicht da die meisten CDN betreiber mindestens 1Terabyte pro Monat abrechnen, ganz soviel hab ich dann noch nicht ;)Ich bleib mal drann und schau was ich da noch für infos bekomme, wollte am Wochenende mal meine ersten Eindrück in einem Blogpost summieren.
Marvin
Kennst du vielleicht einen Online-Dienst, der dir zeigen kann, in welchem Land der Server für die angeforderte Datei aus einem CDN-Netzwerk angesprungen ist? Oder wie stellst du fest, ob es tatsächlich funktioniert ;)
Robert Curth
Sorry zufällig war natürlich mal wieder wirklich ungenau von mir ausgedrückt :) Natürlich nicht zufällig. Wir bei YiGG benutzen zB einfach das letzte Änderungsdatum für unser CSS. Sowas kann man natürlich auch sehr schön im Versionskontrollsystem seiner Wahl automatisieren.
Robert Curth
Sorry zufällig war natürlich mal wieder wirklich ungenau von mir ausgedrückt :) Natürlich nicht zufällig. Wir bei YiGG benutzen zB einfach das letzte Änderungsdatum für unser CSS. Sowas kann man natürlich auch sehr schön im Versionskontrollsystem seiner Wahl automatisieren.
solariz
@magic: Das wäre super. Am meisten stören mich die Networking Buttons die hängen ab und an. Ggf. fliegt der kram raus. Allgemein bin ich mit den CDN selbst bisher happy, nur hin und wieder routet er mich in die USA hmm ;|
magic23
Also bisher "fühlt" sich dein Blog durchaus schneller an. Gab in der Vergangenheit durchaus öfter mal Tage, an dem die Ladezeiten hier zu wünschen übrig liesen. Werde Morgen vom Geschäft aus mal einen Test mit unseren überall in der Welt verteilten Proxies starten. Mal schauen, wie die Zugriffszeiten über Singapur, Boston, Milton Keynes, Paris, Barcelona, Vasteras usw. sind. Berichte dann hier..
Hudiny
Also vom Blackberry ging es ganz fix finde ich. Laptop und Desktop sind schon aus :)
★Marco Gö†ze
@magic: Das wäre super. Am meisten stören mich die Networking Buttons die hängen ab und an. Ggf. fliegt der kram raus. Allgemein bin ich mit den CDN selbst bisher happy, nur hin und wieder routet er mich in die USA hmm ;|
solariz
@Robert: das funkitoniert zwar wunderbar führt dann aber den Sinn eines Caches ad absurdum. Ich möchte ja schon das eine CSS oder JS Datei im CDN Cache bleibt und von dort geliefert wird solange sich nichts ändert.

Was besser funktioniert anstatt eines random wertes wäre eine Getvariable als CRC16 "style.css?crc=8734543834" oder Lastmodified Checksum "style.css?lastmod=01345678" somit hat man a) die eigene Faulheit befriedigt ^^ und b) man kann dennoch den Cach nutzen :)
magic23
Also bisher "fühlt" sich dein Blog durchaus schneller an. Gab in der Vergangenheit durchaus öfter mal Tage, an dem die Ladezeiten hier zu wünschen übrig liesen. Werde Morgen vom Geschäft aus mal einen Test mit unseren überall in der Welt verteilten Proxies starten. Mal schauen, wie die Zugriffszeiten über Singapur, Boston, Milton Keynes, Paris, Barcelona, Vasteras usw. sind. Berichte dann hier..
Hudiny
Also vom Blackberry ging es ganz fix finde ich. Laptop und Desktop sind schon aus :)
Robert Curth
Bezgl. dem deployen neuer Stylesheets habe ich einen ganz trivialen Tipp: Zufällige Get-Parameter.

style.css?rev=2 usw.

Finde ich sehr gut, weil man dann nicht das Stylesheet selber umbenennen muss. :)
★Marco Gö†ze
@Robert: das funkitoniert zwar wunderbar führt dann aber den Sinn eines Caches ad absurdum. Ich möchte ja schon das eine CSS oder JS Datei im CDN Cache bleibt und von dort geliefert wird solange sich nichts ändert.Was besser funktioniert anstatt eines random wertes wäre eine Getvariable als CRC16 "style.css?crc=8734543834" oder Lastmodified Checksum "style.css?lastmod=01345678" somit hat man a) die eigene Faulheit befriedigt ^^ und b) man kann dennoch den Cach nutzen :)