Wie dem ein oder anderem vielleicht aufgefallen ist, war ab gestern Mittag hier das Licht aus! Wie so oft sieht der größte Fehler vor dem Bildschirm… grins. Und dieser Depp wird niemals wieder ein OS-Upgrade so zwischen Brötchen und anderer Arbeit versuchen!!

Nun ja, ich habe mir also durch eine selten dämliche Verkettung den kompletten Server zerschossen, mich dann zur einer vollständigen Neuinstallation entschlossen. Da ich so sauer war und nicht mehr die Backups kontrolliert habe, war das ganze dann a) nervenaufreibender und b) zeitaufwendiger… ;-) 

Ich kann euch sagen, man kann 100 Backups der Datenbank haben, in dem Moment wo man ein…

mysql -uDBUSER -pGEHEIMESPASSWORT --default_character_set utf8 --database=BLOG < MeineSicherung.sql

…in die Konsole tippt und Enter drückt, da fängt man an die Fingernägel abzunagen!

Na ja, sieht so aus, als würde der Blog laufen, meine Mails wieder ankommen… Bleibt so ca. 10 Tage Aufwand für das Feintuning am Apache, MySQL, QMail, PHP und was mir sonst so einfällt.
Denn aktuell habe ich nur die Firewall konfiguriert und den Rest alles auf default gelassen! Oh, und mein Backupkonzept inkl. Worstcase-Szenario wird überarbeitet werden!!!

Kann sein, dass ich ein paar Stunden, Tage, Wochen oder Monate weg bin!

Also nicht ich – eher diese Domain hier. Ich ziehe auf einen anderen Server um, da weiß man ja nie so genau was passiert?!
Besonders da wir ja wissen:

Only wimps use backup…

Also, man sieht sich… wahrscheinlich… *SCNR*

• Making changes to the pages built by the Content Management Systems (CMS) with no need to make changes to the CMS itself,
• Recompressing an image when its HTML context changes to serve only the bytes required (typically tedious to optimize manually), and
• Extending the cache lifetime of the logo and images of your website to a year, while still allowing you to update these at any time.

Laut Google könnte ich nun einen 50% schnelleren Seitenaufbau haben:

We’ve seen mod_pagespeed reduce page load times by up to 50%

Aktuell registriere ich ein lahmes Backend und ein gleich schnelles Frontend – wir warten ab. Wenn etwas nicht funktionieren sollte – bitte laut schreien…. ;-)

Der Tag mit Semmelstatz

Für die letzte Alternative habe ich mich entschieden – hauptsächlich aus Spassss an der Freud’ und am frickeln!
Ich mag das Plugin aber auch aus anderen Gründen… es gibt einen schnellen Überblick über Besucher, begehrte Artikel, Referer. Desweiteren läuft es auf dem Server und der eigenen Datenbank und verwendet PHP-Bordmittel, kein Javascript oder ähnliches. Schick.
Ebenso ist es das Statistik-Plugin, das ich mit als erstes eingesetzt habe – die historische Zahlen reichen zurück bis zum 13.10.2008, darauf verzichte ich nur ungerne.

Was bleibt sind aber ein Haufen Nachteile…

Auf Semmelstaz angesprochen, sagte ein Kollege vor einiger Zeit: Zum scheis*en taugt’s!
Und ja… da ist mitunter was dran.

Ich habe vor einiger Zeit die jeweiligen Besucherstatistiken mit den Werten von Google Analytics verglichen. Das die Zahlen abweichen war klar – interessanter, die Höhe:
Im Monatsdurchschnitt hatte ich eine Abweichung der Besucherzahlen in Höhe von 39%!

Die niedrigste Abweichung betrug 19%, die höchste sagenhafte 54%. Interessant ist zudem, dass die Abweichung geringer wird, je mehr Besucher am Tag kommen.
Zudem ist der Vergleich auch noch eher nach dem Prinzip Apfel->Birnen, denn ich habe GA Visits mit Semmel Besuchern verglichen. Realistische wäre es die Unique Visitors von GA zu verwenden, denn so zählt Semmelstatz auch: Jede IP-Adresse wird am Tag nur einmal gezählt!

Als erstes stand also eine Bereinigung der Besucherzahlen an – von jedem Tag habe ich großzügig und generell 1/3 abgezogen, nun sehen die Stats schon deutlich realistischer aus.

Dies ist allerdings keine Lösung für die Zukunft, der Code muss optimiert werden.
Naheliegend ist es, die Boterkennung zu verbessern. Wie?

Semmelsatz analysiert für die Identifizierung eines Bots den User-Agent des Besuchers. Dieser sieht beim Google-Bot z.B. so aus:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Semmelstatz analysiert diesen String nun nach bestimmten Keywords, in dem Fall z.B. “google”. Wort gefunden -> Bot. Nix zählen.

Meiner Meinung nach sollte die Größe einer Datenbank nicht begrenzt sein – und nur eine volle Datenbank ist eine gute Datenbank ;-)
Folglich habe ich in Schritt 1 Semmelstatz ein wenig modifiziert und schreibe nun auch den jeweiligen User-Agent in die Tabelle…
Viele Tage später, nach Analyse von tausenden Einträgen und Ausführungen von unzähligen selects kann ich behaupten:
In meiner Statz-Tabelle gibt es zu 99,9% keine Bots mehr, die man am User-Agent erkennen könnte!

Entsprechend habe ich die function sem_AreYouBot in der semmelstatz.php erweitert, bzw. bereinigt. Da ich unter anderem ‘bot’, ‘spider’, ‘crawler’ als Einzelwörter mit aufgenommen habe (funktioniert hervorragend und fehlerfrei – ich schreibe z.Z. auch jeden Bot in eine Tabelle und bin mir somit absolut sicher), flogen Einträge heraus, die diese Wörte beinhalten.

Herausgekommen ist dabei dieses Array, das jeder Semmelsatz-User gerne verwenden kann und sollte :-)

Von dieser Erweiterung habe ich mir allerdings etwas mehr versprochen – meine Abweichungen gegenüber Google Analytics sind zwar zurückgegangen, jedoch nicht im erhofften Umfang – im Schnitt liege ich nun bei 29% gegenüber ehemals 39% Abweichung.

Dies wiederum bedeutet, dass ich immer noch viele Bots als Besucher zähle. Bots, die man nicht durch den User-Agent als solche identifizieren kann. Das Konzept von Semmelstatz stößt also zunächst einmal an seine Grenzen – nicht jedoch meine Ideen :-)

Seit vielen Monaten verwende ich das grandiose Antispam-Plugin NoSpamNX, seitdem hat mich kein Spamkommentar von einem Bot mehr erreicht.
Moment… NoSpamNX identifiziert Spam-Bots durch ihr Verhalten? Bots, die Semmelstatz als normale Besucher identifiziert? Großartig!

Seit einigen Tage läuft hier eine Erweiterung bei NoSpamNX mit:
Wenn ein Bot erkannt und geblockt wird, fliegt er aus der Semmelstatz-Tabelle! Dies funktioniert bisher großartig…

Desweiteren beschäftige ich mich auch noch mit $_SERVER['REMOTE_ADDR'] – sprich der IP-Adresse des Möchtegern-Besuchers. Experimentell versuche ich mich an einem forward and reverse DNS Check bei jeder Adresse, die in die Semmelsatz Tabelle geht:

Ich schreibe gerade mit der IP-Adresse 91.52.159.28. Aufgelöst ergibt diese p5B349F1C.dip.t-dialin.net – und im Umkehrschluss ergibt dieser Name wieder die gleiche IP-Adresse.

Bei gut und gerne 20% meiner Besucher schlägt diese Abfrage jedoch fehl. Bei einigen hat der aufgelöste Hostname beim reverse DNS eine andere IP als die, die bei mir ankam. Sehr suspekt, geradezu böse -> Mülleimer.
Zu anderen gibt es auch einige, bei denen die Auflösung des Hostnames fehlschlägt. Was ich von diesen Treffern halten soll, weiß ich noch nicht so genau. Sehr viele finde ich jedoch in einschlägigen RBLs unter der Kategorie: Spammer

Eine weitere Möglichkeit ist es noch, Semmelsatz um eine Javascript bzw. Ajax-Funktionalität zu erweitern, sprich den Zähler durch etwas javascript-basiertes auszulösen. Da ich jedoch bei Wikipedia nachlesen muss, was Javascript ist ;-) beschäftige ich mich die nächste Zeit erstmal noch mit den Dingen, die ich zu können glaube:
Frickelei mit PHP und SQL!

Und – was macht ihr so bei Langeweile?

Das ganze ist sowas wie ein Push-Verfahren für den RSS-Feed:
Der RSS-Reader fragt nicht mehr in regelmäßigen Abständen nach neuen Artikeln, sondern bekommt ein Push/Ping/Whatever… ein neuer Artikel ist sofort nach Veröffentlichung zusehen. Vorrausgesetzt, der RSS-Reader unterstützt PuSH – wie z.B. der Google Reader.

Gestern habe ich gelesen, dass die auf wordpress.com gehosteten Blogs dieses Feature nun unterstützen. Eigene Blogs sollten natürlich kein Nachteil haben – es gibt folglich ein entsprechendes Plugin: PuSHPress

Zugegeben, mir fällt gerade kein Grund ein, warum meine Artikel sofort gefunden/gelesen werden sollten – und nicht erst nach ~ 30 Minuten.
Aber Echtzeitweb ist cool und trendy :-)
Und neue Spielsachen… ähm, ich mein Features teste ich doch gerne.

Ein klein wenig skeptisch bin ich, mit Blick auf Serverlast und ähnlichem. Abwarten!
Wer PuSH’t mit von euch?

PS: Und jetzt sprecht mal dreimal laut hintereinander PubSubHubbub. Riesen Wort!

Chefkoch gefeuert!

Wie bereitet man am besten eine Hauskatze zu? Geht es nach dem italienischen TV-Koch Beppe Bigazzi, legt man das Tier drei Tage in Quellwasser ein und lässt es dann im eigenen Saft schmoren.

Schon auf den kleinsten Kondomen sollte “Large” stehen

Männer wählen oft viel zu große Kondome aus. Gründe dafür sind der Konsum von Pornofilmen und eine verzerrte Wahrnehmung der eigenen Penis-Größe [...]
Schreiben Sie auf keinen Fall groß, mittel und extraklein drauf.“

• Kostenloser Webseiten und Server Last Test
  50 gleichzeitige Zugriffe testen den Blog unter ein wenig Last
• Google Reader goes PubSubHubbub
  - PubSubHubbub auf dem eigenen WordPress Blog aktivieren
• Wer kauft spendet welche Bundestags-Partei?
  Spenden über 50.000 Euro werden nun direkt auf der Website des Bundestags veröffentlicht. Durchaus interessant.
• Vor dem Abflug bitte waschen und reichlich Deo benutzen. Ansonsten – Flugverbot
• WordPress-Plugin: Kommentarzähler im Backend
• Last but not least: Homberhto macht ein Gewinnspiel aufgrund seines 2jährigen Bestehens. Das erwähne ich nicht, weil ich gewinnen will, sondern weil sein Blog echt klasse ist :-)

</weekly></gN8>

KeepAlive on

Vorgeschichte:
Seit vielen Monaten beobachte ich die Ladezeiten des Blogs mittels Pingdom, die Grafiken sind überaus nett und aufschlussreich – viele von euch werden den Service kennen.

Es ging mir immer auf den Keks, dass die ersten Objekte zwar super schnell geladen werden, aber ab der zehnten Anfrage die Zeit zwischen Connect und First Byte a (relativ gesehen) in den Keller ging.
Insgesamt kam ich in den letzten Wochen auf eine Ladezeit von knappen 5 Sekunden – was sicherlich nicht schlecht ist. Für einen Dedicated Server allerdings auch keine Sensation.

Meine server-tuning.conf des Apache kenne ich schon auswendig, die Einstellungen passen.
Heute habe ich aus Langeweile einfach mal die Keepalive Directive auf off gesetzt.

Der Pingdom-Test hat mich sprachlos gemacht:
Gesamtladezeit 1,7 Sekunden, die Zeiten zwischen Connect und First Byte sind immer angenehm kurz.

KeepAlive off

Nun bin ich etwas ratlos!
Bisher habe ich KeepAlive für eine super Sache gehalten, der Performance mehr als förderlich.

Mein Blog gibt auf der Startseite ~ 50 Objekte aus, mit KeepAlive ist mit ein wenig Glück und einer schnellen Verbindung auf der Gegenseite nur eine TCP/IP-Verbindung möglich. So wird es eigentlich auch im Netz beschrieben…

Hat jemand von euch Erfahrungen bzgl. KeepAlive?

Werde es ein paar Tage auf off lassen und einmal beobachten… Seltsam ist das allemal.

Natürlich stellt sich auch die Frage, wie der Test von Pingdom auf den normalen Browser-Besucher anwendbar ist…

Ihre sichere Online-Festplatte mit weltweitem Zugriff!
HiDrive Media 20 exklusiv für Sie – und das vor dem offiziellen Produktstart am 01.03.2010!
Große Treueaktion für weit über 1 Mio. STRATO Kunden: Die ersten 10.000 Pakete dauerhaft für 0 Euro/Mon.¹ !

Oh, in der Tat. Bin wirklich schon lange genug Kunde und zahle jeden Monat auch genug Geld. Also mal gucken, ob ich unter den ersten 10.000 bin…
Link gefolgt… einloggen mit Kd-Nr. oder Domain-Namen (von letzteren habe ich ja ein paar)… aha, geht nicht. Zugangsdaten nicht erkannt. Andere Domain, dann Kunden-Nr. Es bleibt dabei – Zugangsdaten nicht erkannt.

Angebots-Fail

Starke Leistung. Als Server-Kunde, der jeden Monat (i.d.R.) mehr zahlt als jeder Webhosting-Kunde, bin ich nicht würdig genug an dem Angebot teilzunehmen.
Überlege ein Downgrade zu machen und nur noch 1/10 des jetzigen Preises monatlich zu entrichten.

Gut das ich eh nicht gewusst habe, was ich mit 20 Gigs online anstellen soll. Besonders da der Server die zehnfache Menge bietet…
Aber so vom Prinzip her -> Fail!

Habe denen auch gerade eine Mail geschickt. Erwarte aber nicht wirklich eine Antwort…

Danke das ich meiner Unmut Luft machen konnte… :-)

Server:~ # ping -c 5 blogoscoop.net
PING blogoscoop.net (212.87.142.148) 56(84) bytes of data.
--- blogoscoop.net ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4014ms

…was mich so langsam aber sicher nervt. Da ich das Icon von Blogoscoop in meinem Footer eingebaut habe, werden meine Seiten natürlich nie richtig, vollständig geladen.
Klar, Ausfälle des Webservers kommen in den besten Familien vor – aber mehr denn je überlege ich mir nun, welchen Nutzen Blogoscoop noch/überhaupt für mich hat…

Seit dem 18.08.2008 bin ich dort angemeldet, seitdem wird mein Blog in den dortigen Statistiken erfasst. Ich nehme an, von dort kam noch nie ein Besucher (mehr) auf meinen Blog.

Eine der Ideen hinter dem Dienst war/ist ja nach wie vor, Bloggersdorf zu vermessen, eine Größenordnung anzuzeigen, vielleicht sogar den ein oder anderen neuen Blog aufzuzeigen. Diese Idee ist ja auch eine gute – und vor allem unterstützenswerte.
Aber an Tagen wie diesem… *seufz*

Das ganze bringt zwei Vorteile mit sich:

• Die Ladezeit der Website reduziert sich aufgrund der geringeren Strecke, die Bits & Bytes zurücklegen müssen
• Der Browser lädt die komplette Seite schneller, weil der Content von verschiedenen (Sub-) Domains kommt.
  Speziell der letzte Punkt ist interessant, dies schauen wir uns nun mal genauer an.

Ein richtiges CDN bei einem großen Anbieter (wie das Amazon S3 Netzwerk) ist für die meisten Blogs ja ein wenig überdimensioniert. Also scheidet der erste o.g. Punkt am Geldbeutel und somit für den Durchschnittsblogger schonmal aus.
Aber wie sieht es mit der Auslagerung auf eine zweite (und/oder dritte) Domain aus? Bilder, CSS & Javascript ist bei jedem WordPress-Blog reichlich vorhanden, bietet sich also förmlich an.
Werfen wir einen Blick auf AskApache, wo das ganze Verfahren anschaulich dokumentiert ist:

So instead of waiting for 30 items from 1 source, it waits for 30 items from 3 different sources, drastically speeding up the transfer. By using multiple subdomains browsers are further able to maintain persistant connections with all 3 unique servers, making the site load incredibly faster.

Klingt gut.
Ich habe für den Anfang alle Bilder des aktuellen Themes, sowohl die CSS-Datei als solche auf static.gregel.com ausgelagert. Wie immer gilt: Viele Wege führen nach Rom, speziell bei WordPress.

Zum Beipiel bietet das in meiner Cache-Analyse genannte WordPress-Plugin W3 Total Cache von Haus aus die Möglichkeit CDN zu aktivieren (Über W3 Total Cache hat hombertho gebloggt, die entsprechenden Kommentare sind auch lesenswert).
Desweiteren finden sich im WordPress Plugin Directory noch einige andere Plugins speziell für diesen Zweck, z.B. CDN Rewrites oder CDN Tools.

Alle erfüllen sicherlich ihren Zweck – für mich waren sie aber entweder oversized oder suspekt. Letzteres, weil ich auch nach Studium des jeweiligen Codes nicht ganz verstanden habe, wo an welcher Stelle wie engegriffen wird – nichts für mich.

Zudem wollte ich ja klein anfangen – CSS auslagern und damit alle Bilder, die via CSS verknüpft sind. Und dies schafft man mit einfachen WordPress-Bordmitteln und drei Zeilen Code…

So verwendet jedes vernünftige Theme für das Einbinden der CSS im Head-Bereich der Seiten eine Variable:

<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" type="text/css" media="screen" />

Die Variable zielt im Normal auf domain.xy/blogverzeichnis/wp-content/themes/name/styles.css – also biegen wir dieses Ziel doch einfach um auf unsere (Sub-) Domain für statischen Content!

function stylesheet_uri_neu ($stylesheet_uri, $stylesheet) {
$stylesheet_neu_uri = 'http://static.domain.xy/dir/style.css';
return $stylesheet_neu_uri;
}
add_filter('stylesheet_uri' , 'stylesheet_uri_neu', 10, 2);

Die paar Zeilen in eine Datei name.php packen, wie jedes andere Plugin hochladen, aktivieren – fertig. Oder alternativ direkt in die functions.php des jeweiligen Themes.
Ab sofort wird die CSS-Datei und alle darin verknüpften Bilder von der neuen Subdomain geholt und unsere Seite lädt wieder ein wenig schneller.
Mission Accomplished.