Content Delivery Network (CDN) von Google für Eigenprojekte nutzen

Artikel vom 21. Dezember 2009

Mit App Engine stellt Google jedem ambitionierten Programmierer eine skalierbare Entwicklungsumgebung bereit, die sich in Punkten Performance, Speicher und Bandbreite an die wachsenden Ansprüche der Anwendungen dynamisch anpasst. Ursprünglich für Ausführungen komplexer Java- und Python-Skripte angelegt, kann auf Google App Engine gleicherweise statischer Content geparkt und in eigenen Seiten vorteilhaft eingebunden werden. Mit CDN als Turbo.

Länge, die in die Tiefe geht
Cloud Computing und CDN – nie etwas davon gehört? Im Unterschied zu den nahezu unzählig vorhandenen Beiträgen à la “Nutzen Sie CDN, um Ihre Webseiten zu beschleunigen” bleibt der Leser nach diesem Artikel nicht unwissend im Regen stehen. Der Bericht geht gleichermaßen auf die praktische Seite der Nutzung eines CDN ein, konkretisiert die Pluspunkte solch eines Netzwerks für den Website-Entwickler und erläutert in einfachen, für Einsteiger verständlichen Schritten die Inbetriebnahme der praktischen Lösung. Legen wir mit Verständnisfragen los.

App Engine: Die Flugzeug-Turbine steht für (Webseiten-)Turbo

Was ist ein CDN und welche Aufgabe hat es zu erledigen?
CDN steht für Content Delivery Network – ein intelligent ausgelegter Verbund aus mehreren kontinental zerstreuten Servern bzw. Server-Farmen. Die zu erfüllende Mission: Je nach geografischem Standort der Webseiten-Besucher reagiert der nächstgelegene Server auf die Browser-Anfrage und kann die angeforderten Daten prompter, also zeitsparender ausliefern als der Konkurrent auf gegenüberliegender Welthälfte. So teilen sich die Rechner im Verbund die Last und das Traffic-Aufkommen, sichern aber auch die höchste Erreichbarkeit und die niedrigste Ladezeit der dort gehosteten Webseiten oder statische Objekte. Eine “Win-Win”-Situation, sozusagen.

Ein banales Quiz zum Verständnis: Eine durchschnittliche Webseite sendet circa 20 Anfragen an den Server, um für die Darstellung notwendige Informationen zu erhalten. Wann sind die Daten schlagartiger zurück?

A. Wenn sich der zuständige Server “um die Ecke” befindet
B. Wenn die Anfrage um den halben Globus geht

Für größere Websites mit internationalem Publikum empfiehlt sich zweifellos ein Hosting-Provider mit angelegtem CDN (z.B. Amazon CloudFront). Dank der Ortung anhand von IP-Adressen treffen statische Files wie Bilder, CSS oder JavaScript im Browser der Kunden zügiger ein. Was bringt diese Erkenntnis wiederum für den Website- bzw. Shop-Betreiber (Produktbilder sind die besten Kandidaten)?

Konsumenten bedanken sich für flüchtiges Laden der Inhalte (und kaufen nachweislich mehr, denn jede Sekunde zählt).
Google als Suchmaschine lässt die technische Performance einzelner Pages ins Ranking einfliessen (wer braucht da noch Suchmaschinenmarketing).

Handeln ist angesagt!

Google mit eigenem Content Delivery Network
Wie bei der Einleitung oben bereits erwähnt, gehört auch Google App Engine zum kleinen, jedoch sehr feinen Kreis der Anbieter, die ihre Infrastruktur um das Content Delivery Network bereichert haben und gestellte Requests dementsprechend auch IP-bezogen verarbeiten.

Bedauerlicherweise kann Google mit keiner Anbindung an die lokal verfügbaren Server innerhalb Europa dienen (Amazon CloudFront dagegen in den USA, Europa und Asien “vertreten”), so dass beispielsweise Anfragen aus Deutschland von den in Amerika ansässigen Webservern entgegengenommen und abgearbeitet werden (einer der Server). Kleiner Wermutstropfen: Die Reaktionszeiten der ausländischen Google-Rechner sind beeindruckend geringfügig, kaum ein deutscher Hoster kann mit solch winzigen Millisekunden konkurrieren. Glück im Unglück, quasi.

Im Übrigen lässt Google eigene Applikationen ebenfalls auf den selben Maschinen hosten bzw. laufen wie die App Engine Anwendungen der Dritthersteller – Google Closure Compiler sei als Beispiel genannt. Das kann als Garant für ununterbrochene Stabilität und langfristige Zuverlässigkeit des CDN-Hosters aus Mountain View verstanden werden.

Zusätzlicher Nutzen des Hostings bei Google App Engine
Alleine wegen einem bereitgestellten CDN wäre Google’s App Engine für deutschsprachige Websites nicht interessant genug gewesen, wenn da im Zusammenhang nicht noch weitere, für Webworker recht spannende Instrumente dabei wären, welche “die Cloud” attraktiv gestalten (lassen). Fassen wir weitere Vorteile von Google App Engine ausführlich zusammen:

1. Kostenlose Nutzung des Dienstes
Jede bei Google App Engine angelegte Anwendung (in unserem Fall sind es Projekte mit statischen Inhalten) verfügt über ausreichend CPU, Bandbreite und Speicher. Fünf Millionen Aufrufe pro Monat kosten keinen Cent. Darüber hinaus wird nach CPU-Stunden oder Gigabyte-weise abgerechnet, wobei sich die jeweiligen Einheiten in Cent-Bereichen befinden (dazu die Preistabelle). Keine monatlichen Bindungsverträge et cetera.

Nutzungsstatistik auch für kostenfrei verfügbares Kontingent

2. Gesonderte, Cookie-freie (Sub)Domain
Je nach Wunsch kann das Projekt bei App Engine mit eigener Domain verknüpft werden, Anfragen an statische Daten werden z.B. auf static.domain.de umgeleitet. Verzichtet man auf die Verknüpfung der eigenen Domain mit angelegtem App Engine Project, so ist die öffentlich erreichbare Subdomain xxx.appspot.com (xxx steht dabei für den Projektnamen) das neue Zuhause der im Webseiten-Quelltext referenzierten Dateien.

Irrelevant wofür sich der Entwickler letztendlich entscheidet (eigene Domain oder doch ohne), in beiden Fällen werden beim Datenabruf – etwa die Darstellung der Bilder oder Einbindung von CSS – seitens Google keine Cookies mitgeschickt, gesetzt oder ausgelesen. Frei von jeglichen Cookies für noch weniger Bytes beim Austausch zwischen dem Server und den Clients.

Pluspunkt: Je nach Alter können diverse Browser lediglich eine begrenzte Anzahl an gleichzeitigen Anfragen pro Domain stellen. Kommt eine abweichende Domain bzw. Subdomain als eine weitere Datenquelle ins Spiel, kommt es zwangsläufig plötzlicher bei der Fertigstellung des Ladevorgangs voran.

Beide Punkte (abweichende Domain + keine Cookies) werden von Page Speed und Yahoo! YSlow als relevant eingestuft und sollen daher Beachtung finden.

Analyse-Tools bewerten die Webseiten nach mehreren Kriterien

3. GZIP-Komprimierung und Caching von Dateien
Komprimierfähige Dateien wie beispielsweise Stylesheets und JavaScript werden von Google in gestraffter Form verschickt und auf der Client-Seite (in diesem Fall ist es der Browser) entpackt. So wird Traffic gespart und die Geschwindigkeit der Datenübertragung zusätzlich gesteigert. Google App Engine erkennt solche Dateien selbsttätig und behandelt sie mit der GZIP-Komprimierung, ohne dass der Administrator des Accounts dafür aktiv werden muss (z.B. Modifizierungen am Server oder an der .htaccess).

Nach wenigen manuellen Korrekturen versieht der App Engine Server den ausgehenden Datenstrom mit korrekten Headern, die nachhaltig und effizient dafür sorgen, dass die im Browser-Cache abgelegten Elemente bis auf Wiederruf dort aufbewahrt und für die Anzeige verwendet werden sollen. Unverzügliche Darstellung im Browserfenster und ökonomische Anfragestellung zum entfernten Server ergeben sich im Endeffekt.

GZIP-komprimiert und in den Browser-Cache befördert

4. Traffic-Einsparung und Server-Schonung
Durch die Auslagerung der statischen Files auf den Google-Server kommt der eigene Server (hoffentlich) zur Ruhe und kann sich um andere Rechenaufgaben wie z.B. die Generierung von dynamischen Inhalten kümmern. Die Praxis bestätigt immer wieder aufs Neue: Nach der Ausgliederung pendelt die Serverlast spürbar zurück.

Live-Beispiel der Implementierung
Um das Hosting der Daten auf bzw. in Google App Engine und die entsprechende Integration der Quelle im XHTML-Gerüst zu demonstrieren, wurden statische Elemente (Stylesheets und Grafiken) meiner Portfolio-Website eBiene.de auf Google als eigenständiges Projekt ausgelagert. Es ging nicht um die Notwendigkeit, vielmehr um die Machbarkeit der Realisierung.

Wir verlassen an dieser Stellen den theoretischen Part des Artikels. Der praktische Teil spezifiziert, wie Objekte nach Google App Engine übertragen und in die Projektseiten eingebunden werden. Spot ab!

1. Projekt anlegen
Auf der Google App Engine Website gelangt man nach der Registrierung bzw. Anmeldung (Keine Abfrage von Konto- oder Kreditkartendaten, dafür eine kostenfreie Verifizierung per SMS notwendig) auf die Übersichtsseite der gegenwärtigen Projekte. Sind keine Projekte bis dato existent, hat man eine direkte Möglichkeit den Namen für das neue Projekt zu vergeben. Der Projektname mutiert zugleich zur Subdomain von appspot.com (wpseocdn.appspot.com ist in unserem Beispiel die entsprechende Subdomain). Die systemweite Eindeutigkeit des Application Identifiers hat den bitteren Nachgeschmack, das die Vielzahl der möglichen Namen von anderen Teilnehmern bereits genutzt und somit längt vergeben ist. Kreativität ist also gefragt.

Ist die Applikation erfolgreich angelegt, bekommt Developer die Gelegenheit auf das Projekt-Dashboard zu springen: In der Zusammenfassung werden Statistiken für jegliche Art an Verbrauch chronologisch abgebildet. CPU-Gesamtzeit, verstrichene Bandbreite und so weiter.

Application Identifier als Subdomain
Application Identifier wird zur Subdomain des Projektes

2. Upload-Client in Betrieb nehmen
Die Nutzung des Dienstes wird durch die fehlende Möglichkeit erschwert, Daten auf die bekannte Weise via lokales FTP-Programm zum Google-Server zu übertragen. Für diesen Zweck existiert u.a. ein Entwickler-Werkzeug in Form einer smarten Anwendung, die einen vorher definierten Ordner samt Inhalt (Verzeichnisse, Files) auf den entfernten Rechner dupliziert: Ein Klick auf Deploy gleicht den Bestand der Datenstruktur ab.

Auf der offiziellen Download-Seite wird Google App Engine SDK für das gewünschte Betriebsystem heruntergeladen und installiert. Im geöffneten Tool-Fenster kann über das Menü eine New Applikation angelegt werden: Application Name ist der eben im Web gewählte Application Identifier, Application Directory ist der Ort auf der heimischen Festplatte, der als Referenz für die Spiegelung der Dateien gelten soll. Port ist 8080, andere Optionen bleiben unberührt.

Google App Engine Launcher
Lediglich 2 Felder pro Projekt gehören ausgefüllt

3. Statische Inhalte in Google App Engine definieren
Die Applikation wird nach dem Klick auf den Button Create als entsprechender Listeneintrag im Client und auf der Festplatte im gleichnamigen Ordner angelegt. Navigiert man dahin, werden dort 3 Standard-Systemdateien vorgefunden:

app.yaml
index.yaml
main.py

Im Verzeichnis werden nun Unterordner für statische Inhalte erstellt. Exemplarisch: css und img, wo jeweils Stylesheets und Bilder separiert aufbewahrt werden. Neu hinzugefügte Ordner gehören in der Konfigurationsdatei app.yaml als Ordner mit nicht dynamischem Content deklariert. Die Datei app.yaml passen wir nun händisch im Texteditor an – nach der Änderung sieht sie wie folgt aus (wobei xxx für den Projektnamen steht):

application: xxx
version: 1
runtime: python
api_version: 1

default_expiration: "365d"

handlers:
- url: /css
  static_dir: css

- url: /img
  static_dir: img

Der Parameter default_expiration kommuniziert die Tagesanzahl für das Caching, die der Server wiederum an den Browser sendet. Der Wert ist variabel.

Exemplarische Ordnerstruktur einer App Engine Application

4. Hochladen und im XHTML einbinden
Befinden sich nun Dateien in den erstellten Ordnern, so können diese via Schaltfläche Deploy auf den Server gespiegelt werden. Im zusätzlich eingeblendeten Fenster zeigt die Anwendung den Ablauf der laufenden Aktion und weist auf eventuelle Fehler hin.

Geglückter Upload sichert die Erreichbarkeit der übertragenen Dateien unter der bekannten Subdomain. Ein Test in der Adresszeile des Browsers genügt als Bestätigung. Fällt die Prüfung positiv aus, kann die Statik im Quelltext der Webseiten referenziert werden. Als Musterbeispiel sei eine Bilddatei meines SEO-Plugins genannt: http://wpseocdn.appspot.com/…/wpseo-125×125-1.png.

Das waren die vier Schritte, die für den Umzug vom traditionellen Hoster auf Google App Engine notwendig waren. Leider erkennt Yslow die Google App Engine Plattform nicht als vollwertigen CDN-Hoster. Das liegt an der Tatsache, dass Google im Analyse-Tool nicht als solcher hinterlegt ist. Yahoo! verrät, wie die interne Liste um weitere CDN-Provider erweitert werden kann.

Fazit
Google App Engine ist eine perfekte Alternative zum gewöhlichen Webhoster, wenn es darum geht, statische Medien sinnvoll und gewinnbringend auszulagern. Ob eine Website für diesen Zweck groß genug, die Zielgruppe ausreichend international und die angesprochene Upload-Lösung bequem ist, entscheiden ganz alleine die Projektmacher. Als kostenloser Einstieg ins Cloud Computing ist Google App Engine jedoch wärmstens zu empfehlen.

[Der Autor] Sergej Müller ist enthusiastischer Software Engineer mit Schwerpunkten Webentwicklung und WordPress. Seit 2007 programmiert und vertreibt er wpSEO, das weltberühmte und patentierte SEO-Plugin für WordPress-Blogs.

56 Kommentare zum Artikel

222 Tage zuvor | #1 Alexander

Sehr ausführlich und informativ. Einer, der mir das Prinzip CDN endlich mal gut rüber gebracht hat, sodass ich es verstanden habe.

Weiter so und schöne Festtage!

Alex

222 Tage zuvor | #2 Oliver Schlöbe

Vielen Dank dafür, Sergej! Im Zuge von YSlow wollte ich CDN auch schon mal ausprobieren, habe es mangels Zeit und Infos aber erstmal sein lassen. Nun hab ich ja beides: Infos aus deinem Beitrag und Zeit dank Urlaub. Danke.

Schöne Feiertage dir!

222 Tage zuvor | #3 Sergej Müller

Gerne, Jungs. Gerne.

222 Tage zuvor | #4 Nils

Wirklich sehr interessant und super geschrieben!
Bei größeren Blogs sollte sich ein CDN auch schon auszahlen oder?
Auch von mir natürlich erholsame Feiertage ;)

222 Tage zuvor | #5 Sergej Müller

Bei größeren Blogs mit international ausgerichtetem Publikum auf alle Fälle. Im Ausland kenne ich kein bekanntes Blog, welches nicht auf CDN setzt. Im deutschsprachigen Raum sind solche Blogs eher Ausnahme.

222 Tage zuvor | #6 Patrick

Toller Artikel. Quasi CDN for Dummies ;-) Hast Du Dir zufällig mal Gedanken gemacht wie man Teiles eines WordPress-Blogs auf das Google Netzwerk auslagern kann? Mein Traum wäre alle Artikel, die älter als X Tage sind als statischen HTML-File auf das Netzwerk zu schieben und dann von dort auszuliefern.
Wenn jemand das hinbekommt, dann doch wohl Du ;-)

Beste Grüße von der anderen Seite der Grenze zu Pinneberg.

222 Tage zuvor | #7 Sergej Müller

Patrick, ja die gleiche Idee hatte ich auch. Aber nicht nur für HTML, sondern auch für Images, die gleich beim Hochladen in die Mediathek zu Google geschoben werden. Werden wir sehen, das Jahr 2010 hat ja 365 Tage ;)

222 Tage zuvor | #8 Patrick

Wenn Du einen Beta-Tester brauchst… HIER!!!

222 Tage zuvor | #9 Sergej Müller

Merke ich mir.

222 Tage zuvor | #10 Oliver Schlöbe

Wobei es sowas schon gibt: http://wordpress.org/extend/plugins/search.php?q=cdn

Vor allem über ersteres Ergebnis hörte ich schon Gutes und auch bei W3 Total Cache lässt sich das zuschalten.

Genutzt habe ich allerdings beides selbst noch nicht.

222 Tage zuvor | #11 Sergej Müller

Wobei ich der Meinung bin, W3 Total Cache setzt auf Amazon S3 als CDN.
Aber Oliver, mal ehrlich – es gibt Plugins für alle Bereiche: Ob SEO, Antispam oder WordPress-Sicherheit :) Mal schauen…

222 Tage zuvor | #12 Oliver Schlöbe

Heh, grundlegend will ich natürlich niemanden davon abhalten, ein weiteres Plugin zu schreiben. :)

Dennoch kann man die vorhandenen ja mal ausprobieren… vielleicht sind sie ja in Sachen Usability, Sicherheit und Code Quality unter aller Sau, dann wäre ein weiteres CDN-Plugin natürlich höchst willkommen.

222 Tage zuvor | #13 Sergej Müller

Genau, wolltest du ja zwischen den Feiertagen ausprobieren. Berichte doch mal, ob ich mir Gedanken machen soll ;)

222 Tage zuvor | #14 Sergej Müller

Ach ja, und ich halte fest, Oliver hat mich daran gehindert, neues Plugin zu schreiben ;)

222 Tage zuvor | #15 Oliver Schlöbe

Mist, da hab ich mir wohl jetzt selbst ein Ei gelegt, wa? Ich bin unschuldig. :-( ;-)

222 Tage zuvor | #16 Patrick

Ich habe jetzt mal ein bisschen rumgespielt und das klappt ganz gut. Hast Du zufällig eine Idee wie man das /wp-include/js Verzeichnis auf die App Engine auslagern kann? Evtl. mit einem mod_rewrite? Da werden ja so einie JS-Dateien geladen, die es evtl. lohnt zu verschieben.

222 Tage zuvor | #17 Sergej Müller

@Patrick
Nee, da muss ich leider passen. Da brauchst du schon einen richtigen mod_rewrite Experten.

221 Tage zuvor | #18 Dieter

@Sergej
Ein ganz großes Dankeschön für diesen gelungenen ausführlichen Artikel.

Ich habe gerade auf meiner WordPress-Website Webseiten-Infos.de den statischen Inhalt Grafiken auf Subdomains ausgelagert. Bringt das überhaupt etwas? Ich habe mit Firbug (Netzwerk) den Eindruck geringfügig. Die Zahl der gleichzeitigen HTTP-Request ist ja je nach Browser unterschiedlich stark eingeschränkt.

Die Auslagerung auf Googles App Engine könnte aber mehr bringen. Ich werde es mal testen.

221 Tage zuvor | #19 Sergej Müller

Dieter, eine Subdomain ist schon deswegen gut, weil sie keine Cookies mitsendet (im Standard-Fall, da abweichend von der WP-Domain) und das bedeutet schon viel.

221 Tage zuvor | #20 Constantin – SEO-United.de

Hallo,

vielen Dank erstmal für den ausführlichen Artikel zu der Entwicklungsumgebung. Google macht das schon recht Geschickt, die skalieren immer ihre Anwendungen für eigene Mitarbeiter für den freien Markt. Die Ressourcen dann bereitzustellen dürfte weitaus weniger kosten, als der Vorteil aus den Daten wert ist…

Liebe Grüße,
Constantin

221 Tage zuvor | #21 ocean90

@Sergej und Oliver

Also W3TC unterstützt zwar CDN, aber nicht Googles App Engine.
Die App Engine ist ja auch eher indirekt als CDN gedacht, sodass die bisherigen Plugins dies (noch?) nicht unterstützen.

Also Sergej, halt dich ran. ;)

221 Tage zuvor | #22 Sergej Müller

@ocean90
Ich bin der Meinung, im Code von W3TC etwas von Amazon S3 gesehen zu haben. Das oben platzierte Plugin, was Oliver da gepostet hat, unterstützt soweit Google App Engine als CDN. Hab ich aber noch nicht angetestet.

220 Tage zuvor | #23 Gregor

Googles App Engine oder Amazon CloudFront für ein Projekt mit fast ausschließlich deutschen Nutzern?

220 Tage zuvor | #24 Dennis

Hallo Sergej,
für Performance sind CDNs wirklich hervorragend.

Blöd nur, dass man sich mit einem CDN – vor allem wenn es von Google kommt – einer großen Abmahngefahr aussetzt.
Ich habe vor 2 Wochen eine Artikel darüber geschrieben: http://j.mp/6UOC32

Kurz: Wer ein CDN nutzt, ermöglicht dem Anbieter die Speicherung der IP-Adresse seines Besuchers. Der Besucher hat keine Möglichkeit zu widersprechen. Da die IP-Adresse von manchen Gerichten als personenbezogene Information gewertet wurde, ist das illegal.
Wenn die speichernden Server im EU-Ausland stehen, macht es die
Sache nochmals schlimmer.

Insgesamt ist die Rechtssprechung nicht ganz klar, was leider den Speilraum für Abahmanwälte offen hält.

219 Tage zuvor | #25 Sergej Müller

@Gregor
Dann das CDN von Amazon, weil es direkte Server in Europa stehen hat. Ebenfalls schnell.

219 Tage zuvor | #26 Ahmet Topal

Das ist gut, Google als Hosting zu benutzen :) Habe es zwar schon für Wave Robots gemacht, aber für den eigenen Host, auch eine gute Möglichkeit :)

Danke :)

219 Tage zuvor | #27 Sergej Müller

@Dennis
Warum soll ein CDN oder der dahinterstehende Betreiber die IP-Adresse des Nutzers protokollieren? Diese werden lediglich ausgewertet, um Inhalt gerecht auszuliefern. Auch wenn jemand sie speichert, wird er das öffentlich kaum zugeben, da absolut unnötig und daher sehr fraglich. Es ist ja nicht Akismet, die IPs definitiv speichern, da darauf die gesamte Datenbank samt Auswertungen aufsetzt. EIn CDN braucht die IP nur einmal, ohne diese je wieder zu verwenden oder zu referenzieren.

219 Tage zuvor | #28 Lazy

Hi Sergej,

wollte die Kommentarfunktion nur “missbrauchen”, um dir fröhliche Weihnachten und schöne, ruhige Feiertage zu wünschen. Auf ein erfolgreiches und primär gesundes neues WordPress Jahr :)

Liebe Grüße

Chris

218 Tage zuvor | #29 Sergej Müller

Chris,

kein Problem. Alles klar, danke schön. Auch dir viel Gesundheit und Erfolg.

Grüße aus dem fast schneelosen Bayern,
Sergej

212 Tage zuvor | #30 plerzelwupp

Vielen Dank für diese hilfreiche Einführung. Ich bin entsprechend vorgegangen und es klappt soweit ganz gut.

Weiß denn jemand, ob es prinzipiell möglich ist, auch Bilder auszulagern, die über die tinthump.php angesprochen werden? Für mich sieht es so aus, als würde diese keine externen URLs vertragen(?)

Viele Grüße und einen “guten Rutsch”
Oliver

212 Tage zuvor | #31 Sergej Müller

Oliver, freut mich, dass mein Artikel dir helfen konnte.
Nein, da wird ein lokaler Pfad erwartet – eine Verknüpfung mit Google App Engine ist daher leider nicht ohne Aufwand möglich.

203 Tage zuvor | #32 Lukas

Hallo Sergej,

vielen Dank für den sehr interessanten Artikel!
Magst du uns verraten (falls du die Daten noch parat hast)
# Was für einen Geschwindigkeitszuwachs du bei eBiene.de messen konntest?
(Toolbars, Webserver Statistiken, Google Webmaster Tools)

vielen Dank
Lukas

203 Tage zuvor | #33 Sergej Müller

Lukas,

sehr minimal: Google’s Server sind ein wenig schneller als meines Hosters, auch Verteilung auf mehrere Domains bringt einen Vorteil. eBiene.de als Portfolio ist auch eine sehr sparsam angelegte Website, was die Anzahl der Requests angeht.

Um es richtig zu messen, müsste ein größeres, international ausgelegtes Projekt ran. Im Laufe des Jahres werde ich diese Technik auf einem Online-Shop einsetzen und anschliessend berichten.

198 Tage zuvor | #34 lukas

Ich werde mich wohl mal vorsichtig dranwaagen.
Hab leider aktuell mit dem Testprojekt 21mio Aufrufe aber dafür nur 80Gig Traffic.

Darf ich fragen, mit welchen Tools du die Zeit misst?

198 Tage zuvor | #35 Sergej Müller

Lukas, um die Zeit zu messen benutze ich Firebug. Sonst aber auch einfach die Konsole, da kann man auch schnell sehen, wie schnell ein Server auf die Anfragen reagiert.

195 Tage zuvor | #36 Soenke Ruempler

Guter Artikel, allerdings solltest du folgendes updaten:

"Bedauerlicherweise kann Google mit keiner Anbindung an die lokal verfügbaren Server innerhalb Europa dienen (Amazon CloudFront dagegen in den USA, Europa und Asien “vertreten”), so dass beispielsweise Anfragen aus Deutschland von den in Amerika ansässigen Webservern entgegengenommen und abgearbeitet werden (einer der Server)."

Kann ich so nicht bestätigen. GAE deployed sehrwohl auch in EU (und andere) Rechenzentren. Die Lichtgeschwindigkeit konnte G noch nicht verändern, daher hat auch G eine Latenz von ca. 150msec durch den Atlantik. ;)

Hier meine gemessenen Ping-Zeiten (mit ‘mtr’):

Vom Decix aus: 20msec
Von Alice aus: 50msec
Von USA (rackspace) aus: 50msec

An den Marktführer AKAMAI kommt das noch lange nicht dran, aber dafür kostet es auch 10-20x weniger. Und ich denke, dass die Infrastruktur mit der Zeit eher besser als schlechter wird :)

195 Tage zuvor | #37 Sergej Müller

@Soenke Ruempler
Danke für deinen ausführlichen Kommentar. Bevor ich einen Artikel schreibe, prüfe ich alle Angaben. Und solange ich selbst keine Bestätigung dafür habe, dass Google ebenfalls aus EU Daten streut, werde ich auch nichts im Beitrag korrigieren – auf meine Tests haben immer Server mit dem Standort USA geantwortet (anders bei Amazon).

AKAMAI spricht auch eher professionelle Anwender an. Erst Amazon, Google und Co. machen CC und CDN für den "kleinen" Unternehmer bezahlbar.

184 Tage zuvor | #38 Mariusz

Hi,

danke fuer den Artikel. Habe ihn zwar ein wenig spaet gefunden, fand ihn aber sehr gut.

Die Tipps habe ich auch gleich mal ausprobiert (bei 3 Blogs) und konnte keine wirkliche Steigerung beobachten. Getestet habe ich mit diesen Tools hier: http://j.mp/caqPl3 , YSlow und Chromium.

Die Daten auf dem CDN brauchten im Schnitt 10-20 ms mehr.
Dies wuerde dann auch die Pings bestaetigen.

VG Mariusz

184 Tage zuvor | #39 Sergej Müller

@Mariusz
Absolut richtig. Dennoch sollte man den Artikel nicht nur einfach überfliegen, vielmehr gründlich durchlesen, denn es handelt es sich um ein komplexes Thema.

Und wie ich oben explizit erwähne, werden Seitenbesucher aus deutschsprachigen Ländern keine spürbare Performance zu “sehen” bekommen, da Google keinen Verteilerknoten in Europa parat hält. So werden Daten immer aus Amerika geliefert und ob die Auslieferungszeiten prompter sind als die des heimischen Hosters, hängt ganz alleine an dem Hoster des Vertrauens. Dabei kann GAE schneller sein (wie meine Tests zeigen), muss es aber nicht (wie deine Auswertungen zeigen).

180 Tage zuvor | #40 jan

hallo,

danke, toller artikel!

jan

125 Tage zuvor | #41 Mac_BetH

Hallo Sergej,

vielen Dank für deine tolle und einfache Beschreibung dieses Dienstes. Oliver (Plerzelwupp) hat mich hier her geschickt um meine Seite schneller zu machen. Es hat mir fast 1.5 Sekunden gebracht!

Super!

Gruß
Matthias

92 Tage zuvor | #42 Christian

Hallo Sergej,

danke für die gute Zusammenfassung. Aber nur zum Verständnis: Verliert man durch die Auslagerung einiger JS-Bibliotheken (z.B. jquery) in das Google CDN nicht den Vorteil, alles JS in einer Datei auszulagern? Denn so werden aus einem HTTP-Request eben (mindestens) zwei. Und naja, egal wie schnell der CDN-Zugriff auch sein mag, ein Request mehr ist einfacher einer mehr, oder?

Sprich: wird das ganze nicht erst dann interessant, wenn man das CDN auch für eigene Files nutzen kann?

Gruß,
Christian

92 Tage zuvor | #43 Christian

äh, sorry, ich nehm alles zurück – hätte mal besser lesen sollen…

92 Tage zuvor | #44 Sergej Müller

Christian, nicht die Rede wert ;)

61 Tage zuvor | #45 CL

Wärs nicht das “einfachste” einfach eine neue Klasse für GAE für dieses Plugin zu schreiben? http://j.mp/a6AhWe

61 Tage zuvor | #46 Sergej Müller

Vielleicht. Vielleicht auch nicht.

44 Tage zuvor | #47 cocker

Wo liegt jetzt genau der Unterschied zwischen Amazon S3 und dem CDN von google? Amazon S3 ist doch viel bekannter, oder?

44 Tage zuvor | #48 Sergej Müller

Amazon ist bekannter, korrekt. Bei Google hast du jedoch ein bestimmtes Kontingent an Freivolumen.

44 Tage zuvor | #49 Viktor

hmm, wirklich Klasse Anleitung – auch für Dummies – nur klappen tuts dennoch nicht :( – Keine Fehlermeldung, aber auch kein Bild….

44 Tage zuvor | #50 Sergej Müller

Klappt mit Sicherheit. Hatte vor paar Tagen auch ein CDN für wpSEO angelegt.

44 Tage zuvor | #51 Viktor

im Dashboard scheint auch alles Ok zu sein, keine 404, nichts, nur ausliefern mag er sie nicht… (außer das python Skript, das geht)
http://j.mp/9rQ1QO

44 Tage zuvor | #52 Sergej Müller

So über die Kommentare kann ich dir nicht helfen. Wenn du die Yaml-Datei um den Pfad versehen hast, müsste alles klappen.

44 Tage zuvor | #53 Viktor

ich Döskopp hab hab die

- url .*

dringelassen :(
- jetzt gehts! Danke nochmal für die Anleitung!

Soviel zum Thema genau nach Anleitung ;) – Schande über mein Haupt.

37 Tage zuvor | #54 Jaime

Nein, ich gebe nicht auf ;-) Die Anleitung und auch der Artikel waren ja verständlich (Danke dafür). Aber da ich auf Windows erst noch Python installieren musste gabe es dort Fehler und es gab für mich leider keinen Erfolg.

Ein Erfolgserlebnis musste aber her .. also hab ich es mit CloudFront probiert. Das ging ruckzuck über die Bühne, S3Fox installiert und schon hatte ich meinen Erfolg.

Aber verbissen wie ich nunmal bin … Fehlermelungen durch Google geschickt ;-) und das fehlende Python PIL Modul nachinstalliert. Und siehe da, jetzt klappts auch bei mir mit dem Google CDN.

Mir gefällt Amazon CloudFront von der Verwaltung her (bisher) besser.

37 Tage zuvor | #55 Sergej Müller

Jaime, freut mich für dein Erfolgserlebnis ;)
Ich konnte mich allerdings mit Amazon nicht wirklich anfreunden. Bin mit App Engine irgendwie glücklicher.

37 Tage zuvor | #56 Jaime

Ich schrieb ja auch vorsichtshalber (bisher) :D. Das kann sich im Laufe der Zeit noch ändern ;-)