tiny little gizmos

2 Tage down

Ich habe gerade gesehen, dass mein Webserver 2 Tage down war. Mist!
Daran nerven mich zwei Dinge:

1. ist das ungefähr schon 20 mal passiert. Ich weiss nicht, weshalb der Apache derart wackelig ist.

2. Scheinbar hat der Hoster darauf kein Monitoring laufen, weil ich niemals über Probleme informiert werde, sondern immer durch Zufall darauf komme. Ich schaue ja nicht dreimal am Tag meine Website an.

3. Könnte man das durch ein Skript, welches den Dienst automatisch neu startet noch vereinfachen, aber was verlange ich da…

Okay, ich bezahle vergleichsweise schmales Geld für die Kiste und mein Wohlergehen hängt nicht von meinem privaten Blog ab, aber so ein Servermonitoring ist heute eigentlich Standard und frisst kein Brot.

Genau sowas ist eben der Unterschied zwischen einem echten Hoster und einem Spielzeugprovider.

*grummel*

Store and Forward, Offlinenetz… was bitte?

Berufsbedingt setze ich mich momentan verstärkt mit Netzwerkthemen auseinander – auch ausserhalb der Arbeit. In den letzten Wochen habe ich mich mit einigen Leuten getroffen, die nicht nur mit dem aktuellen Internet arbeiten, sondern sich in der Freizeit auch mit Alternativen für bestimmte Spezialanwendungen auseinandersetzen.

Nun habe ich in zwei Gesprächen – immerhin unter wirklichen Nerds – das Thema „Store-and Forward in Netzen in denen Knoten nicht ständig verbunden sind“ angesprochen und ergänzt „so ähnlich, wie damals das Fido Net“. Beide Male habe ich in ratlose Gesichter geblickt. „Was war denn das Fido-Net?“

Ich hätte genausogut von Aufstieg und Fall des Osmanischen Reiches erzählen können. Kein Plan, kein Geschichtsbewusstsein. Das hatte ich nicht erwartet, weil Retrocomputing ja gerade ziemlicher Trend ist. Immerhin waren Mitte der 90er weltweit fast 40.000 Systeme mit mehreren 100.000 Nutzern vernetzt – alles von Privatpersonen betrieben.

Wer sich für die Vernetzung zwischen Ende der 70er bis Mitte der 90er Jahre, bevor es das Internet für Privatpersonen gab interessiert, dem kann ich die wirklich gute Dokumentation „BBS The Documentary“ ans Herz legen. Dankenswerterweise sind die Folgen bei Youtube zu sehen, da die DVDs nur in USA erhältlich waren.

Die Folge in der das Fidonet behandelt wird, ist diese. Viel Spass!

 

VirtualBox komplett löschen (Apple Mac)

HINWEIS: Der Artikel bezieht sich auf eine Version von Virtual Box, die im Januar 2013 aktuell war. Änderungen, die seitdem an dem Produkt vorgenommen wurden, finden sich hier nicht wieder, da ich es seit damals nicht mehr benutzt habe.

Ich bin frustriert. Heute habe ich meinen kompletten Tag weggeworfen. Anstatt am Rechner zu tun, was ich zu tun habe, habe ich mich den kompletten Tag mit den Zickigkeiten von VirtualBox rumgeärgert. Mit VirtualBox kann man einen kompletten Rechner in einem anderen Rechner emulieren. Der Sinn darin kann – wie im vorliegenden Fall – darin liegen, eine fertig eingerichtete Entwicklungsumgebung für eine komplexe Webapplikation (also einen Webserver) auf seinem Arbeitsplatzrechner zu installieren.

Normalerweise geht das recht schmerzfrei. Heute hätte ich aber schreien können, so sehr hat mich der Mist geärgert. Da ich dabei durchaus einiges gerlernt habe, möchte ich mein frisch erworbenes Wissen der Allgemeinheit zur Verfügung stellen.

Vorgestern habe ich eine (fast) fertig konfigurierte VM (Virtuelle Maschine) zur Verfügung gestellt bekommen. Es ist ein Debian Linux mit einer komplexen Webapplikation und vier Netzwerkschnittstellen. Es war schon etwas hakelig, das Ding so zum Laufen zu bekommen, dass man von aussen – also vom Gastsystem, einem Apple Mac – den Webserver, den Datenbankserver und den SFTP Server ansprechen kann. Aber es lief dann irgendwann zufriedenstellend.

Bis heute Morgen.

Da hat sich die komplette VM zerlegt. Weshalb auch immer. War nicht wieder in Gang zu bringen. Ganz klarer Fall – neu installieren. Beim zweiten Mal weiss man ja, worauf man zu achten hat.

Denkste!

Neu installieren gerne – aber die Netzwerkadapter liefen trotzdem nicht. Selbst die radikale Variante, VirtualBox neu zu installieren und dann die VM darauf neu aufzuspielen brachte keine Besserung. Um ein paar Stunden suchen und Fluchen abzukürzen: VirtualBox lässt sich nicht komplett deinstallieren sondern behält tonnenweise Mist auf der Festplatte, der bei der nächsten Neuinstallation „freundlicherweise“ wieder eingelesen wird. Das führt direkt zu der Frage:

Wie kann man VirtualBox denn nun vollständig deinstallieren?

  • Zunächst löscht man die alle Maschinen in dem Programm
  • Dann fährt man VirtualBox herunter
  • Dann löscht man tatsächlich die ganzen VM-Dateien auf der Platte
  • Jetzt öffnet man das DMG Installationsimage aus dem man die Software dereinst installiert hatte. Aber bitte exakt dieselber Version. Das habt Ihr doch sicherlich gut aufgehoben, oder? 😉
  • In dem Image liegt ein Deinstallationsskript – aber draufklicken nützt nicht. Stattdessen öffnet man jetzt ein Terminalfenster und begibt sich auf der Kommandozeile in das Installationsimage:
    cd /Volumes/VirtualBox/

    Nun muss man das Uninstall Skript mit Administratorrechten starten. Dazu gibt man ein:

    sudo ./VirtualBox_Uninstall.tool

    Pukt und Slash müssen vor den Skriptname, weil die Shell das Skript sonst in allen möglichen Verzeichnissen sucht, ausser im aktuellen.

  • Nun muss man noch eine Frage mit ‚yes‘ beantworten und schon geht die Löschorgie los.

Wer nun aber glaubt, damit sei alles erledigt liegt falsch. Jetzt kommt noch ziemlich viel Handarbeit. Innerhalb des eigenen Homeverzeichnisses (~/ bzw. /Users/username/) muss noch in den folgenden Verzeichnissen nach Überresten gesucht werden, die zu entfernen sind (alles in dem virtualbox vorkommt):

  • ~/Library/
  • ~/Library/Application Support/
  • ~/Library/Caches/
  • ~/Library/LaunchAgents/
  • ~/Library/PreferencesPanes/
  • ~/Library/Preferences/

Es kann natürlich auch nichts schaden, dieselben Verzeichnisse noch mal auf Systemebene zu durchsuchen:

  • /Library/Extensions/
  • /Library/StartupItems/

Ist doch alles fast selbsterklärend, oder? Nein, nicht wirklich. Ich könnte ausrasten. Wenn man schon ein Skript zur Deinstalltion schreibt, wieso vergisst das Ding dann 50% der Arbeit?

Die Erkenntnis hat mich mit dem vielen hin- und herprobieren, suchen usw. fast einen kompletten Tag gekostet. Ich hoffe, dass ich jemand anderem mit dem Beitrag das Leben ein bischen erleichtern kann.

Instagram? Muhahaha…

Letzte Woche gab es einen Sturm im Wasserglas: Instagram verkauft DEINE Bilder.

Zunächst mal stimmte das so nicht ganz. Deutscher „Qualitätsjournalismus“ eben. Instagramm hat sich bestimmte Nutzungsrechte eingeräumt – was auch schon nicht nett ist und sicherlich auch nicht gerichtsfest. Aber Leute – hey – der Laden gehört zu Facebook. ’nuff said.

Zudem: Ich habe nie kapiert, was an dem Ding toll sein soll. Ein Service, der schlechte Schnappschüsse vergilbt aussehen lässt. Toll! Nicht.
Ansonsten gilt wie immer bei Diensten im Internet:

Wenn Du für einen Dienst nicht zahlst, bist Du nicht der Kunde, sondern die Ware.

In diesem Sinne möchte ich mal wieder auf den hervorragenden Webcomic von XKCD verweisen, der das Thema mal wieder voll auf den Punkt bringt:

Zwei niedliche Browserspielchen für zwischendurch

Gerade habe ich zwei tolle kleine Browser Spiele für zwischendurch gefunden:

Reaching Finality ist ein süsses kleines RPG im Zelda-Stil und in „feinster“ Gameboy-Auflösung.

Reaching Finality - Oberwelt

Reaching Finality - Oberwelt

Reaching Finality - Unterwelt

Reaching Finality - Unterwelt

Auch klasse: Forget me not.

Extrem reduziert Grafik, aber tolles Gameplay. Wie fühlt es sich an? Wie eine Mischung aus Pac-Man, einem Shooter in 2D und Adventure. Ach, probiert es doch einfach aus…

Forget me not

Forget me not

Noch mehr Spielereien von Nerds

Bin gerade über zwei lustige Dinge aus der Rubrik „Das passiert, wenn Leute zuviel Zeit haben“ gestolpert. Oder auch: „Wenn die Spielidee klasse ist, ist es egal, wie die Grafik ausieht“.

Portal auf TI Taschenrechner

Erinnert sich noch jemand an Taschenrechner? War mal ein heisses Ding in den 70ern und 80ern. Ich habe hier auch noch so ein Gerät rumliegen: Einen Texas Instruments TI-84, programmierbar und mit Klötzchengrafik. Irgendjemand hat sich nun den Spass gemacht, das Spiel Portal auf dem Gerät umzetzen. Sieht gut aus. Seht selbst:

 

Rollenspiel mit Textgrafik – im Browser!

Und wenn wir schon mal in den 70er/80er Jahren sind: Star Wars und Rogue. Ersteres kennt jeder, das zweite vielleicht nicht. Roguelikes sind Rollenspiele in denen man durch Dungeon rennt, Monster besiegt und Schätze einsammelt. Der Witz ist, dass das alles ohne Grafik, nur mit Text symbolisiert wird. Ondřej Žára hat nun ein solches Spiel programmiert – mit Star Wars Thema und im Broser lauffähig. Genial!

Browser Star Wars Rogue

Browser Star Wars Rogue

=> Hier geht es zum Spiel

Beides gefunden auf Nerdcore. Danke!

Noch mehr Mobile-Mist

Ich hatte mich ja neulich schon mal darüber ausgelassen, dass mir die ganze Entwicklung mobiler Betriebssysteme nicht schmeckt. Unsere ach-so-tollen Hyper-Super-Duper-Hi-End-Smartphones schmiessen neuerding immer mehr Funktionen raus, die seit mindestens 10 Jahren (in Mobilfunkzeit: „schon immer“) Standard waren. Neueste Entdeckung:

Android kann offensichtlich nur noch normale HTTP(S) Links.

Ich hatte gerade mir JQuery Mobile versucht, mir ein kleines Telefonbuch zu basteln und musste feststellen, dass alle Links, die mit tel:// sms:// oder mailto: anfingen, nicht mehr unterstützt werden.

Wirklich grossartiges Krüppelzeug, Ihr Arschlöcher!

Kann Nokia mal bitte wieder vernünftige Handies bauen – ich sehne mich wirklich danach, diesen unausgegorenen Ami-Rotz (Apple, Google, Microsoft, RIM) wieder loszuwerden.

Schnell, schneller, noch schneller !!!

Ich war eben in Hamburg um Marco zu treffen. Marco ist als Webentwickler in San Francisco tätig und gerade für kurze Zeit in Deutschland zu Besuch. Wir kennen uns seit zwölf Jahren und sind beide seit geraumer Zeit für grosse E-Commerce Websites zuständig. Er im Bereich Publishing und Buchungssysteme und ich für Onlineshops. Den halben Nachmittag haben wir unter anderem für einen Erfahrungsaustausch genutzt. Obwohl „unsere“ Systeme völlig unterschiedlich sind, ähneln sich die Herausforderungen, mit denen wir konfrontiert werden. Zwei der wichtigsten Kriterien sind Belastbarkeit mit vielen Besuchern und Transaktionen sowie Geschwindigkeit.

Zeit ist Geld. Nutzer warten nicht gerne. Ist die Website zu langsam, ziehen sie weiter. Google straft seit einiger Zeit ebenfalls Seiten im Pagerank ab, die langsam laden. Daraus folgern nochmals weniger Besucher. Wenige Zehntelsekunden können auf diese Weise durchaus einige tausend Euro ausmachen. Es lohnt sich also, Zeit und Geld in die Beschleunigung der Website zu investieren. Wir haben in unserer Firma in den letzten zehn Monaten sehr viele kleine und grosse Massnahmen zur Beschleunigung der Shops durchgeführt, die in Summe wirklich sehr viel gebracht haben.

Im Groben gibt es drei Bereiche, die für die Geschwindigkeit der Website verantwortlich sind:

  1. Der Client
    Letztlich zählt, wie schnell der Browser des Nutzers reagiert. Es geht also um die Zeit zwischen Klick und fertiger Seite. Gegen langsame Rechner und Browser kann man als Websitebetreiber nichts machen. Aber man kann die Seiten so ausliefern, dass der Browser möglichst wenig Mühe mit dem Rendern hat. Stichworte sind: Weniger komplexe Seiten, Reduzierung der Requests, mehr parallele Downloads.
  2. Das Netzwerk
    Hiermit ist alles zwischen Rechenzentrum und Nutzer gemeint. Hier hat man als Betreiber jedoch wenig Einfluss. Bei der Auswahl des Rechenzentrums sollte man auf redundante Anbindung aller relevanten Backbones und ausreichend verfügbarer Bandbreite achten. Wenn die Zielmärkte global verteilt sind, sollte die Nutzung eines spezialisierten Content Delivery Networks in Erwägung gezogen werden.
  3. Die Systemarchitektur
    Wie baut man ein komplexes Setup aus unterschiedlichen Servern und Netzwerkgeräten im Rechenzentrum um die Inhalte möglichst schnell ausliefern zu können? Genau das war der Schwerpunkt unseres Erfahrungsaustauschs.

Interessanterweise sahen wir beide einige der momentan angesagten Methoden zur Realisierung von E-Commerce Sytemen eher etwas kritisch. Wir sind zum Beispiel beide für möglichst schlanke Systeme zu haben, weil diese sowohl Ressourcen sparen, als auch Geschwindigkeit bringen.

Problembereich Frameworks

Komplexe Frameworks für eCommerce Systeme, auf die potentiell unbegrenzt viele Nutzer zugreifen können, sind unter den Aspekten Geschwindigkeit und Ressourcen eher schwierig. Zumal die Erfahrung zeigt, dass die damit beabsichtigte Beschleunigung von Entwicklungszyklen in der Realität oftmals nicht eintritt. Teilweise wird die Entwicklung sogar langsamer und fehleranfälliger.

Cache as cache can

Auch der gerade sehr angesagte Einsatz von Full-Page Caches hat nicht nur Vorteile. Bei Publikationen (Onlinemagazine o.ä.) sind sie voll in ihrem Element, können enorme Geschwindigkeitsvorteile bringen und die Content Management System entlasten. Ihre Geschwindigkeit kommt daher, dass sie fertige Seiten vorhalten und ohne grosse Verzögerung an jeden Nutzer ausliefern können.

Im eCommerce Umfeld macht aber genau die daraus resultierende geringe Flexibilität Probleme, wie ich am Beispiel einer Kategorieseite eines Onlineshops erläutern möchte.

Problemfeld Caching – ein einfaches Beispiel

Eine Kategorieseite besteht aus vielen Elementen, die erst aus der Datenbank zusammengesucht und dann zusammengebaut werden müssen. Die Daten der Produkte, die in der Kategorie sind und der aktuellen Seitenzahl entsprechen, weitere Daten zur Kategorie selber (Titel, Beschreibungen, Links auf Headergrafiken usw.) und weitere Elemente, wie Kategoriebaum, Breadcrumbnavigation usw.

Um solch eine Seite aufzubauen können durchaus hunderte einzelne Datenbankabfragen nötig sein. Klar, das sowas dauert. Die Seite nur einmal zusammenzubauen und dann immer wieder fertig auszuliefern ist doch toll, oder?

Darauf kann ich nur mit einem beherzten „jein“ antworten. Die Seiten werden aus dem Cache teilweise 5-10 mal schneller ausgeliefert und belasten die Applicationserver nicht mehr. So weit so toll.

Das gilt allerdings nur, solange die Standardseiten angezeigt werden. Sobald der Nutzer die Anzahl der anzuzeigenden Artikel pro Seite oder die Sortierung (nach Preis, Aktualität, Beliebtheit oder sonstwas, auf- oder absteigend) ändert oder sogar Filter setzt, greift das tolle Caching nicht mehr, weil man derart viele mögliche Seiten nicht mehr sinnvoll vorhalten kann.

Ein weiteres Problem ist die Invalidierung der gecachten Seiten. In einem hochdynamischen System müssen die erzeugten Seiten genauso schnell gelöscht und neu erzeugt werden, wie sich die zugrundeliegenden Daten ändern. Ansonsten bekommt der Nutzer unentwegt veraltete und inkonsistente Daten angezeigt, wie z.B. Artikel, die gerade ausverkauft wurden.

Wenn z.B. ein Artikel, der auf der ersten von 50 Kategorieseiten steht, gerade ausverkauft wurde, muss nicht nur seine Detailseite aus dem Cache entfernt werden, sondern ausserdem 50 Kategorieseiten neu erzeugt werden; die erste, weil er dort nicht mehr enthalten sein darf, und die 49 folgenden, weil sich die Position aller nachfolgenden Artikel geändert hat.

Dieses noch recht einfache Beispiel zeigt bereits viele potentielle Fehlerquellen. Hinzu kommt, dass sich personalisierte Seiten, die individuell für den Nutzer zusammengebaut werden, prinzipiell überhaupt nicht cachen lassen. Von Problemfällen wie mitgeführten Sessions (Warenkörben, personalisierten Einstellungen, Logins, Kampagnentracking) und so weiter ganz zu schweigen. Alles lösbar, aber bei weitem nicht trivial und zum Teil hebelt man damit den Geschwindigkeitsvorteil des Full Page Caches wieder aus.

Less is more

Bleibt die Frage offen „…und wie bekommen wir das Ding nun schnell?“
Platt gesagt durch Weglassen und Datenoptimierung.

  • Full Page Caches sind toll für Publikationen, aber problematisch bei Transaktionssystemen. Nehmen wir diesen Komplexitätslayer lieber aus dem System raus.
  • Optimieren wir stattdessen den Applicationserver. Die verwendeten Frameworks müssen schlank und schnell sein. Wenn für die Initialisierung der Anwendung mit Konfiguration und Aufbau der Datenbankverbindung schon 200ms draufgehen, brauchen wir gar nicht erst weitermachen.
  • Pro anzuzeigender Seite dürfen nur wenige und einfache Datenbankabfragen nötig sein. Es kann sinnvoll sein, hochgradig normalisierte Datenstrukturen für die Anzeige zu Flattables zusammenzufassen.

Der Erfolg eines solchen Vorgehens ist spürbar. Marco meinte zu einem Kunden, der den Einsatz eines Full-Page-Chaches anregte, sinngemäss:

„Die Seite in 200 Millisekunden fertig. Was willst Du da noch beschleunigen?“

Nebenbei sei bemerkt, dass dieses System nicht nur pfeilschnell ist, sondern zudem mit sehr wenig Hardware betrieben wird.

Und? Wie ist Euer Shopsystem so? 😉

Grundprobleme des Internet – Unbeständigkeit

Gerade bin ich bei Tech Crunch über einen interessanten kurzen Artikel gestolpert. In „All Your Metadata Shall Be In Water Writ“ wirft Devin Coldewey das Problem auf, dass man sich nicht wirklich auf die Korrektheit von Daten aus dem Internet verlassen kann. Er bezieht sich auf die Unbeständigkeit von Daten, zum Beispiel Artikel in Blogs, Homepages, Wikipedia und sonstwas.

Man findet leicht Unmengen von Informationen zu fast jedem denkbaren Thema, aber man kann sich nicht auf deren Beständigkeit und Integrität verlassen.

  • Die Information kann zwischem den letzten Abruf und dem aktuellen verändert worden sein.
    Das ist zum Beispiel bei Publikationen („Internetzeitungen“) oder auch Blogs durchaus üblich.
  • Die Information kann vollständig verschwunden sein.
    Der Betreiber existiert nicht mehr, hat das Interesse verloren, verfolgt jetzt andere Ziele oder wurde verklagt.
  • Die Information kann beim Transport vom Server zum Client verändert worden sein.
    Stichwort Zwangsproxy zum Beispiel bei UMTS Verbindungen. Hier wird bereits heute von den Providern der auszuliefernde Inhalt verändert.
  • Die Angaben zum Ort, an dem die Information vermutet wird, können manipuliert sein.
    Das passiert bei nahezu allen DSL Anbietern in Deutschland, wenn im Browser fehlerhafte URL eingegeben werden.
  • Die Information kann personalisiert sein, d.h. in Abhängigkeit meinem Browser, Betriebssystem, Standort, Netzwerkanschluss, Login oder sonstigen Parameter kann mir abweichender Inhalt angezeigt werden.
    Das ist unter Umständen sogar sinnvoll, wenn Websites an Smartphones angepasst werden. Hingegen zumindest fragwürdig, wenn Google in Abhängigkeit vom Land aus dem eine Suchanfrage kommt, bestimmte Ergebnisse unterdrückt.

An den Beispielen wird jedenfalls deutlich, dass keine Verlässlichkeit gegeben ist. Coldewey schreibt:

There is no simple and reliable way to tell whether the information you are looking at has been altered in any way. Every word, every image, every byte has to some significant degree an unknown provenance.

Die o.g. Methoden können in bestimmten Szenarien durchaus nützlich und sinnvoll sein. In anderen Szenarien können es gezielte Manipulationen sein, um z.B. bestimmte Reaktionen auszulösen, Daten abzugreifen, Falschinformationen weiterzugeben, Reputation zu zerstören, rechtliche Massnahmen zu beeinflussen oder sonstige dunkle Machenschaften durchzuführen.

Auf jeden Fall sollte man sich stets bewusst sein, dass es bei Daten aus dem Internet keine Verlässlichkeit gibt, wenn man auf der Basis dieser Daten wichtige Entscheidungen treffen will.

Nächste Seite »