michi bloggt!

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?

Traut man den Leuten in München gar nicht zu. Aber die sind besser als ihr Ruf.







[more]

Die Italiener fordern die Rückgabe von Bruno. Paah, nicht mit mir! Ich behalte meinen Teil. Auch wenn ich gehofft hatte, mehr abzubekommen. Aus dem Batzen geht sich ja nicht einmal ein vernünftiges Braunbären-Gulasch aus.

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:

"Apocalyptica" spielen zum Auftakt der EU-Ratspräsidentschaft in Brüssel auf und sorgen für Abwechslung nach den Mozartklängen [derStandard.at]

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/

die kanzlerin tut es, ich tue es (bzw hier), und wann tust du es?

ok, ok, ich gebs zu. ich tu es noch gar nicht. muss mir erst überlegen, was ich denn da überhaupt online stellen will. wird also noch brauchen.

Das folgende Video ist aber auf alle Fälle sehenswert. Bei 1:14 wirds für die orthopäden spannend. Hoffe die Copyright-Inhaberin verklagt mich nicht.



(Auf Grund eines Bugs des Video-Players muss man noch rechts unten auf das Icon klicken, damit man das Video vernünftig sieht. Der Verursacher dieses Bugs wird das hoffentlich bald richten *räusper*)

Mindestens ebenso sehenswert: Die Live&Direkt-Berichterstattung von Anil im Coke-Blog (Achtung, das war jetzt Schleichwerbung)

Mal wieder ein etwas provokativerer titel :-) Aber so eine Aktion gehört sich für ein feines Grand Hotel wirklich nicht.

-> http://www.panhans.at/

Ich bekomm ja nur noch selten Post. Doch letztens fand sich ein Schreiben des Hotels Panhans im Briefkasten, welches vorgab die Preisakzeptanz ihrer Urlaubsangebote testen zu wollen. Angeboten wurde ein (wirklich traumhaft klingendes) Wochenende für 2 Personen, welches normalerweise 385€ kostet, mit deutlichen Preisnachlass.

Laut dem Schreiben erhalten ein Drittel der Adressaten einen Nachlass von 10%, ein Drittel einen Nachlass von 20% und ein Drittel einen Nachlass von 50%. In Erwartung dass mein Glück mir mal wieder treu bleibt, war ich auch nicht allzusehr überrascht den 50%-Nachlass zugeteilt zu bekommen. Das Pech für Panhans ist nun aber, dass zufälligerweise meine beiden Mitbewohner ebenfalls das gleiche Schreiben erhielten. Ebenfalls mit 50% Nachlass.

Bei einer Irrtumswahrscheinlichkeit von 5% liesse sich die Hypothese der vermeintlichen Gleichverteilung der Nachlässe also nicht halten. Ergo: Panhans lügt!

Hat vielleicht noch jemand ein solches Schreiben bekommen? Dann liesse sich die Stichprobe etwas vergrößern.

Nichtsdestotrotz ist das Angebot sehr verlockend. Aber das wäre ja so, als würde ich bei einen der Viagra-Spammer tatsächlich Viagra bestellen.

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).