Das Referrer SEO Experiment – Backlinks in Logs zur Suchmaschinenoptimierung

SEO hat viele Facetten. Eine Methode der Suchmaschinenoptimierung ist das Sammeln von Backlinks. Mit simulierten Referrer-Klicks kann man massenhaft Links in Serverlogs für Google platzieren.

Es gab eine Zeit, da habe ich viel mit Google experimentiert. Die Idee zu diesem Experiment hatte ich beim auswerten meiner Serverlogs. In den Logs finden sich regelmäßig URL’s aus fremden Serverstatistiken. Diese Backlinks könnte man auch generieren.
Mehr von diesem Beitrag lesen

Advertisements

Top10 gratis Apps – Netzwerktools für Google Android

Für nur 59,90 € gibt’s den iPodTouch-Clone bei Pearl.de als Android Touchlet. Kostenlose Software sowie gratis Spiele gibt es im App Center und Google Market reichlich. Anbei eine kleine Auswahl meiner persönlichen Top10 an Netzwerktools für Android und wofür man diese einsetzen kann.
Mehr von diesem Beitrag lesen

Batch per Cron, Tasks und Backends mit Google App Engine realisieren

Mit der Google App Engine ist es sehr einfach möglich langlaufende Programme per Batch im Hintergrund asynchron zu starten. Kleine Tasks mit einer Laufzeit von bis zu 10 Minuten können über den Webserver ausgeführt werden. Für echte Batches, die mehreren Stunden dauern, können mehrere separate Backend Server genutzt werden.

Das Limit liegt derzeit bei 48 GHz für die CPU und 10 GB für den RAM. Die kleinste Serverinstanz mit 600 MHz und 128 MB kosten ab 0,08 US-Dollar pro Stunde. Insgesamt können bis zu fünf verschiedene Backends definiert werden.

Google Appengine Backends

GAE Admin Console Backends

Mehr von diesem Beitrag lesen

Das Google SEO Experiment – Suchmaschinenoptimierung für über 500.000 Keywords

Alles begann mit folgendem SEO Experiment:

Was passiert, wenn Google sich selbst durchsucht?

Innerhalb kürzester Zeit wurde meine Testdomain zu über 500.000 Keywords ohne viel Suchmaschienenoptimierung gefunden. Egal welches Thema oder welche Sprache, die Domain war zu allem und jedem in den Top 10 der Suchergebnisse vertreten.

Auch wenn mein Experiment mittlerweile etwas länger zurückliegt, noch heute funktionieren viele Internetprojekte erfolgreich auf Basis des nachfolgend beschriebenen Grundprinzips.

SEO Motto: Masse statt Klasse

Durch Suchmaschinenoptimierung sollen möglichst viele Besucher auf eine Internetseite gelotst werden. Denn letztlich kann man mit jedem Besucher bares Geld verdienen. Bei der Optimierung von Webseiten für Suchmaschienen gibt es zwei vollkommen gegensätzliche Ansätze.

Mehr von diesem Beitrag lesen

Skalierung: Grenzwerte und Richtlinien – Google App Engine

Google klassifiziert eine App Engine abhängig davon, ob bestimmten Grenzwerte eingehalten werden. Daraus lassen sich Richtlinien für die Implementierung ableiten, um nicht in der Sandbox zu landen.

GAE Grenzwerte - Quelle http://www.youtube.com/watch?v=rP-kjrx9CRE

Auf der Google I/O 2011 wurden o.g. Grenzwerte (Min 0:12:25) vorgestellt. Die maximale Laufzeit eines Skriptes sollte unter einer Sekunde liegen. Der erste Loading Request beim Start einer Instanz sollte unter fünf Sekunden liegen. Die optimale Latenz für einen Warmup ist abhängig von der Anzahl an Zugriffen pro Sekunde und darf je Zugriff bei 200ms liegen.

Architektur des Google App Engine Cloud Service Framework macht Webseiten für Startups skalierbar

Die Architektur des Google App Engine Cloud Service (GAE) ist ein Framework bzw. Server Stack, der es ermöglicht eine Webseite skalierbar mit hoher Performance zu betreiben ohne als Startup bei der Unternehmensgründung selbst eine Infrastruktur aus Clustern aufbauen und betreiben zu müssen. Das Hosting einer Webapp ist in der Free Version sogar kostenlos, sodass eine Homepage gratis für Googles Plattform in Python, Java oder Go entwickelt werden kann. Steigt die Serverlast später an, kann der eigene Cluster mitwachsen ohne dafür die Software anpassen zu müssen.

Der Vorteil der Cloud ist, dass bei einer Plattform als Service nur variable Kosten anfallen. Um die Skalierbarkeit kümmern sich andere und man selbst hat keine Fixkosten von mehrere tausende Euro pro Monat für IT-Spezialisten. Dieser Artikel beschreibt Aufbau und Funktionsweise der App Engine, über die täglich Millionen von Besuchern möglich sind.

Startup / skalierbarer Webserver

Besonders für Startups eignet sich die App Engine, da die Infrastruktur mitwächst und zu Beginn kostenlos ist.

Die traditionelle IT-Architektur im Client-/Serverumfeld bzw. von Webservern ist meist statisch und zentralisiert. Das bedeutet die Anwendung besteht aus einem oder mehreren fest konfigurierten Servern in einem Rechenzentrum und nutzt ein relationales Datenbanksystem. Die Kapazität dieser Ressourcen und damit die maximal mögliche Serverlast ist begrenzt. Übersteigt die Besucherzahl dann zunehmend die Kapazitäten des eigenen Systems ist guter Rat teuer, denn nicht jeder IT’ler beherrscht Skalierung.

Die Infrastruktur der App Engine wird als Platform as a Service (PaaS) genutzt. Bei dieser Plattform sind die Webserver, der Cache, die Datenbank und die Dateiserver weltweit in einer public Cloud verteilte, sodass jeder Request von anderen Servern beantwortet werden kann. Die Anzahl der benötigten Server wird dynamisch an die aktuelle Last angepasst. Ideal für Startups und neue Projekte, in denen sich die IT auf die Umsetzung der Anwendung konzentriert und nicht zusätzlich mit der Infrastruktur sowie deren Betrieb belastet wird.

Komponenten / Server Stack

Mit der Google App Engine kann sofort mit der Umsetzung der Webseite begonnen werden, da sie alle nötigen Komponenten für Entwicklung, Test, Deployment und Betrieb enthält.

Die Komponenten der Google App Engine Cloud können auch für den Aufbau einer eigenen skalierbaren Infrastrukturen adaptiert werden. Für Teile existieren Open Source Lösungen oder Amazon Services, die im eigenen Stack integrierbar sind. Im Vergleich zu einer Apache MySQL PHP Installation unter Linux (LAMP) oder Windows (WAMP) ähnelt die App Engine von der Laufzeitumgebung eher einem Java EE Application Server (JBoss, Websphere, Tomcat), da Programme z.B. auch bei Python im Hauptspeicher gecached werden.

Bestandteile des App Engine Cloud Service sind:

  • Webspace (Application)
  • Webserver (Instanz)
  • Load-Balancer (Scheduler)
  • Laufzeitumgebung (Python, Java, Go)
  • Cache (Memcache)
  • hierarchische Datenbank (Datastore)
  • relationale Datenbank (SQL-DB)
  • Fileserver (Blobstore)
  • Scheduler (Cron)
  • Webhook (Task)
  • Batchserver (Backend)
  • HTTP-Push (Channel)
  • Emailserver (API)
  • Bibliotheken (API’s)
  • Entwicklungsumgebung (Eclipse)
  • Testumgebung (SDK)
  • Deploymentverfahren (SDK)
  • Versionsverwaltung (GAE)
  • Benutzerverwaltung (GAE)
  • Logging (GAE)
  • Monitoring (GAE)
  • Domainverwaltung (Apps)
  • Dokumentation (Web)

Jede Komponente der App Engine Architektur ist skalierbar! Um die Kapazität der Cloud insgesamt zu erweitern müssen nur weitere Server hinzugefügt werden. Zudem kann ein Server seine Aufgabe ändern indem er mit einem anderen Image ausgeführt wird. Das gesamte System ist weniger anfällig gegen Ausfälle einzelner Server. Um das Management der Cloud kümmert sich Google, zu jeder Uhrzeit und auch am Wochenende.

Mehr von diesem Beitrag lesen

Memcache Quota Limit – 212 MB, 48 Stunden – Google Appengine

Der Google Appengine Memcache hat aktuell folgende Limits: maximal 212 MB Space, maximal 48 Stunden und 1 MB je Datensatz sowie maximal 10 K Datensätze. Langfristig können 500 KB zwischengespeichert werden.

Von Google selbst wird keine Quota für den Memcache veröffentlicht, sodass man die Werte nur durch eigene Tests ermitteln kann. Über die google.appengine.api kann mit memcache.get_stats()[‚bytes‘] die aktuelle Größe und mit memcache.get_stats()[‚oldest_item_age‘] der älteste Datensatz ermittelt werden.

Im Memcache können kurzfristig maximal 222.003.552 Byte und langfristig nur 500.269 Byte gespeichert werden, die maximale Dauer beträgt 172.800 Sekunden und maximale Größe 1.000.000 Byte für einen Datensatz. Bei mehr als 10.000 Datensätzen wirft die Appengine eine Exception und steigt mit einem 500 Server Error aus.

Mehr von diesem Beitrag lesen