michi bloggt!

(follow-up zu spam everywhere und Referrer Spam adé)

Angesichts der nackten Zahlen könnte man meinen dass Dreckbacks eine späte Renaissance erleben würden, und nun doch noch ein massen-taugliches Mittel zur weltweiten Verknüpfung wurden. Hier auf twoday.net werden z.b. über 100mal soviele Dreckbacks verzeichnet wie Kommentare. Mindestens ein Blog-Server ging auch angesichts der Popularität der Dreckbacks kurzfristig in die Knie.
Einziges Problem: 99,9% der abgegebenen Dreckbacks sind Spam! Bisher standen wir dem Problem eher machtlos gegenüber. Bis ich nun endlich auf einen erschreckend simplen aber effektiven Mechanismus gestossen bin, sich dagegen zur Wehr zu setzen. Wir verlangen nun, dass die Trackbacks von der gleichen IP-Range aus abgesetzt werden, auf der dann auch das referenzierte Blog liegt. Da die Spammer unterschiedliche Farmen zum Spammen und zum Hosten der Sites verwenden (müssen), bleiben diese nun alle hängen. Einziger Wermutstropfen: Dreckbacks welche von irgendwelchen Desktop-Clients, oder anderen Services geschickt werden, kommen nun ebenfalls nicht mehr durch. Das ist aber noch immer besser als die andere verbleibende Option: nämlich Dreckbacks komplett abzudrehen.

-> Wordpress Widgets API (available widgets)
-> Typo Sidebars (more info)
-> TypePad Widget API
-> Google Gadgets API
-> Developing Dashboard Widgets



Nachtrag: die über 2 jahre alte twoday "widget" API. kann sich durchaus noch immer sehen lassen.

Aus mir komplett unerfindlichen Gründen beschloss die MySQL Replikation heute ab 14:10 plötzlich die komplette Bandbreite des Switches auszulasten.

Daher kam es heute zu einer doch starken Beeinträchtigung von twoday.net. Etliche Requests wurden mit einem Fehler abgespeist.

Die Replikation (welche eigentlich bloss zu Backupzwecken läuft) hab ich nun vorläufig mal deaktiviert. Und siehe da, jetzt läuft wieder alles wie geschmiert.

Bei manchen Fehlern kann man nur den Kopf schütteln.

am Beispiel der Website unseres Baseballvereins:
* Bulldogs 1998 - 99
* Bulldogs 2000 - 2001
* Metrostars 2002 - 2006
* Metrostars 2006+ (under construction)

"Bulldogs 98" war übrigens eine der ersten Seiten vom Matthias. Und auf den sich drehenden 3D-Baseball links oben waren wir verdammt stolz damals.

Am lebendigsten, aber auch am chaotischsten war "Bulldogs 00" (siehe etwa die OssiWessi-Seite). Eine Art wiki-seite, auf der jeder seinen Unfug treiben konnte, und auch trieb.

Nach der doch recht statischen, biederen Seite von jetzt, hoffe ich dass wieder etwas mehr Leben in die Community kommt. Unabhängig davon ist aber blogr ein feiner Ort um die ganzen coolen (und weniger coolen) Fotos endlich wo vernünftig unterzubringen.

-> http://www.sixapart.com/pronet/comment_spam

dürfte schon etwas älter sein, denn der Artikel wurde anscheinend noch vor dem 3.2er Release von Movable Type verfasst, welches etliche Ansätze bereits im Core vereint (siehe hier), dennoch ist die Abhandlung lesenswert.

Six Apart Recommendations for Movable Type Users
* Upgrade to the latest version of Movable Type
* Use TypeKey and comment moderation
* Brad Choate's MT-DSBL
* Jay Allen's MT-Blacklist
* Phil Ringnalda's Real Comment Throttle

Bemerkenswert vor allem dass weder MT noch Wordpress auf Captchas setzen. Ich finde jedenfalls die Empfehlung, alle User welche über einen offenen Proxy angesurft kommen (und somit anonym bleiben wollen) zu blocken, weitaus problematischer, als die mangelnde Barrierefreiheit von Captchas.

Ich weiß, ich weiß Captchas knacken ist mittlerweile nicht mehr so schwierig, dennoch halten Captchas einen einmal die Amateur-Spammer vom Hals.

Unfassbar jedenfalls mit welchen Spam-Mengen manche User (etwa Basicthinking) derzeit bereits zu kämpfen haben. Da kommt noch einiges auf uns zu.

wer will, wer mag, wer hat noch nicht?
-> https://github.com/antville/helma/pipermail/helma-user/2006-July/006593.html

Zusammen mit Hannes seinem (für unsere Bedürfnissse adaptierten) Skript, globaler Blacklists und eigener Stop-Wort-Listen dürften wir unser Referrer-Spam-Probleme nun sehr gut in den Griff bekommen haben.
Jedenfalls kommen, wenn ich mir nun die Logfiles so ansehe, nur noch ganz ganz wenige Spammer durch. Hoffentlich bleibt das auch so.

Als nächstes gilt es den Trackback Spam zu bekämpfen. "Vor dem Spiel ist nach dem Spiel" wie man schön sagt, nicht wahr?

Ich selbst verwende zwar (noch) keinen Desktop-Client zum Bloggen, aber wenn dann würde ich definitiv BlogDesk von Johannes Oppermann einsetzen:

-> http://www.blogdesk.org/de/index.htm

Der Entwickler kontaktiere mich/uns netterweise bereits vor langer langer Zeit, und informierte uns das beim Upload von Bildern auf unserer Seite Fehler geworfen werden. Nun hab ich mich also endlich um die Behebung des Bugs gekümmert, und siehe da, man kann nun endlich auch den wirklich gut gelungenen ImageWizard verwenden, mit welchem sich etwa folgende Effekte ganz einfach erzielen lassen:

wie bereits erwähnt nahm ich an einem von MySQL AB angebotenen Workshop über Performance Tuning & Optimization teil. Vortragender war Kristian Köhntopp (Blog). Die Teilnehmer, etwa 20 an der Zahl, kamen erstaunlicherweise fast gar nicht aus der Web-Programmierung.

Gründsätzliche Messages des Seminars:
* Optimiere erst dann wenn auch Optimierungsbedarf besteht
* Stell dir eine Test-Umgebung zum Benchmarken zusammen, und verwende "echte" Daten, "echte" Requests und "echte" Server. Philosophieren ob ein bestimmter Index so oder so definiert werden sollte, nützt gar nichts. Benchmarke es am besten selber.
* Es gibt einen Sättigunspunkt, ab dem die Performance zusammenbricht, und es gilt diesen im vorhinein zu bestimmen, um keine bösen Überraschungen erleben zu müssen.

Hier nun ein paar etliche unsortierte Notizen vom Seminar:
* "Dont over-optimize", ansonsten läuft man Gefahr zwar für den vorliegenden Spezialfall gut aufgestellt zu sein, aber bei geringfügigen Veränderungen der Daten, bzw der Requests in Schwierigkeiten zu kommen
* Mit munin lassen sich auch Mysql Key Figures monitoren (siehe hier)
* Datenbanken lieben Hauptspeicher. Sobald man mehr als 3 GB eingebaut hat, sollte man unbedingt 64bit CPUs mit aktuellen 2.6er Kernel verwenden
* Datenbanken lieben schnelle Festplatten. RAID-5 ist aber überhaupt keine gute Idee, da kleine random writes sehr langsam sind. Besser sind viele (billige) Platten im RAID-10. Benchmarke das RAID mittels SysBench.
* Jeder Thread/Connection hat seinen eigenen Speicher. Daher Connection Pooling.
* MySQL Query Cache verwendet LRU-Mechanimus (genauso wie Helma; macht also in Kombination mit Helma DB-Mapping nur selten sind). Um diesen aber verwenden zu können, muss man seinem Connector/J mit useServerPrepStmts=false konfigurieren.
* Der Query-Cache lässt sich mittels SQL_CACHE bzw SQL_NO_CACHE für einzelne Queries aus- bzw ein-schalten.
* sobald (table_locks_immediate / table_locks_waited) < 100 sollte man über InnoDB anstatt MyIsam nachdenken, da dann die Table-Locks ständig zu unnötigen Wartezeiten führen. Auf twoday.net liegt dieser Wert etwa bei 200, dennoch gibt es etliche andere potentielle Gründe für InnoDB (vor allem der nächste Punkt).
* InnoDB sortiert Daten nach Primary Key. Ist daher performanter wenn ein Datensatz über den Primary Key accessed wird (wie das bei Helma eben ständig der Fall ist). Ausserdem enthält der Indexbaum im Gegensatz zu MyIsam ebenfalls bereits den Primary Key. Daher werden Abfrage a la 'Select TEXT_ID from AV_TEXT where TEXT_F_SITE=123' komplett aus dem Index heraus beantwortet, ohne die Datentabelle zu bemühen. In MyIsam müsste man hierfür einen kombinierten Index auf (TEXT_F_SITE, TEXT_ID) legen.
* Lese und verstehe "How MySQL Uses Indexes"
* Make your indexes as small (and as few) as possible: Vermeide Indizes auf UTF-8 Columns (dreimal so groß wie iso-8859-1 columns). Optimizer muss sich vor jeder Query entscheiden welcher Index verwendet werden soll -> kostet CPU.
* Make your data as small as possible: Verwende nur UTF-8 wenn wirklich notwendig. Verwende "NOT NULL" und "unsigned" bei den Datentypen-Deklarationen.
* Vermische nicht OLTP und OLAP im Datenbank-Design!
* Konvertierung einer Tabelle in InnoDB aus Optimierungsgründen zweimal ausführen. Sprich 'ALTER TABLE .. engine=InnoDB; ALTER TABLE .. engine=InnoDB;'
* Primary Key für InnoDB-Tabellen sollte möglichst klein sein.
* Linux' Disk-Cache, welcher für MyIsam (nicht aber von InnoDB) entscheidend ist, verwendet ebenfalls LRU und arbeitet auf Block-Ebene (meine gegenteilige Annahme hier war also falsch)
* Man kann für InnoDB die Transaktionssicherheit mittels 'innodb_flush_log_at_trx_commit=0' ausschalten, und somit die Performance deutlich erhöhen.
* MySQL Cluster (NDB) ist etwas für Leute mit fetter Geldbörse. Erstens da man sämtliche Daten im RAM halten muss. Zweitens weil man gut beraten ist, MySQL Support hierfür anzufordern. Und zu guter Letzt sollte man auch besser auf Mysql 5.1 warten, bzw sogar 5.2.
* Es gibt neben MyIsam und InnoDB noch andere interessante Storage Engines: CSV, Memory, Archive
* De-Normalisierung zwecks Performance-Optimierung ist in Ordnung, aber man sollte immer ein Skript zur Verfügung haben, welches die Daten-Konsistenz wiederherstellt.
* Partitioning erlaubt es Tabellen kleiner zu machen. Klassischer Anwendungsfall für twoday.net wäre es z.b. alle Tables nach zugehöriger Site zu partitionieren. Dieses Feature sollte man aber auch besser erst ab 5.1 verwenden.
* Indizes können Performance verschlechtern. Ein Index welcher das Resultset nicht zumindest auf ein Zwanzigstel reduziert, ist eher kontraproduktiv. (z.b. ein Index auf Geschlecht, oder aber auch auf TEXT_PROTOTYPE). Bei der Index-Optimierung sollte man stets 'EXPLAIN SELECT..' ausführen, und dann auch noch sein Benchmarking-Setup verwenden, anstatt zu mutmassen.
* DRBD ist eine gute Alternative zu einen MySQL Master/Master-Setup um Ausfallssicherheit zu gewinnen.
* Logge auf eine separate Partition. Bevorzugtes Filesystem: reisferfs. Mounten mit 'notail,noatime'.

Und hier noch ein paar vom Vortragenden empfohlene Blogs rund um MySQL:
* http://mysqlperformanceblog.com
* http://www.planetmysql.org/
* http://de.planetmysql.org/
* http://jan.kneschke.de/blog/

Der RSS Traffic auf twoday.net hat sich innerhalb der letzten beiden Monaten verdoppelt. Deutliches Zeichen dafür dass die Nutzung dieser sich rasant ausbreitet. Mittlerweile muss der der Server über 3 RSS-Requests pro Sekunde verarbeiten. Tendenz weiter steigend.
Peinlicherweise schickten wir unseren RSS-Clients bis jetzt keine sogenannten ETags (bzw Last-Modified-Timestamps) im Response zurück, so dass die Feeds bei jedem Request komplett neu abgeholt werden mussten. Dieser Helma-Patch vom Hannes löste das Problem, und siehe da, die verbrauchte RSS-Bandbreite halbierte sich von einem Tag auf den anderen (bei gleichbleibender Request-Zahl).