michi bloggt!

-> http://m78.tumblr.com/

just in case, that anybody is still following things here: greetings from helsinki :-)

(ende der durchsage)

* Stochastic Models of Noncontractual Consumer Relationships
* Market Response Models

Yippie!!

Der erste seit Jahren (siehe auch smeidu). Das Wochenende hat er aber leider nicht überlebt. Ich denke er wusste über sein Schicksal Bescheid, und hatte daher diesen traurigen Blick.

Innerhalb weniger Wochen ist nun das zweite knallgraue Mammut-Projekt online gegangen: myworld II (siehe hier die neuen Features)

Gratulation mal wieder an das gesamte Team (michi w, ronald, elias, bodi, fabian, alex) und diesmal allen voran an Robert (bzw hier sein myworld Profil) und Kristina. Ein Projekt mit einem derartigen Funktionsumfang in dermaßen kurzer Zeit (4 Monate?) mit einem durchaus "jugendlichen" Team so sauber abzuwickeln, das hat mich wirklich schwer beeindruckt.

Die Punkte im folgende Chart stellen die zeitliche Verteilung der SVN Commits (=Code Änderungen) dar. Darüber hab ich nun grafisch die geplanten Sprints gelegt:


Man beachte die spät nächtlichen Commits zum Schluss!

Seit jeher [1], [2] liebäugele ich damit anstatt MyISAM die InnoDB als Storage Engine für unsere MySQL Datenbanken zu verwenden. Seit jeher nahm ich mir aber nie die Zeit einen solchen Wechsel mit Benchmarks zu belegen. Vor allem in Kombination mit Helma (siehe meine Seminar Notizen) scheint InnoDB die bessere Wahl zu sein.

Bernhard stellte erst kürzlich ausführliche Benchmark-Ergebnisse für die von ihm betreute Helma-basierende Site club3k.at online: http://www.bluelife.at/wiki/Benchmarks:MyISAM_vs_InnoDB
Und kam für seine Daten und für seine Queries zu dem Ergebnis, dass InnoDB bis zu 10% besser performt.

Ich bin nun ganz analog zu Bernhard vorgegangen, und hab mir ebenfalls mittels des MySQL-Query-Logs die tatsächlichen Queries zusammengesammelt, und hab diese dann auf eine MySQL-Datenbank mit den Echt-Daten von twoday.net (mittlerweile rund 3GB) mittels mysqlslap abgefeuert. Bei meinem Setup hab ich aber die UPDATE-Statements zu den SELECTs hinzugenommen um auch Schreib-Operationen zu berücksichtigen.

Die ganzen Details und Schwierigkeiten der Benchmarks lasse ich hier mal weg, und reduziere mein Ergebniss auf folgende zwei Aussagen:
* Mittels eines "Optimize Table" konnte ich eine Verbesserung der MyISAM-Datenbank von 16% erzielen. Ergo sollten wir vielleicht öfters die Tabellen optimieren lassen.
* Durch den Wechsel aller DB-Tabellen auf InnoDB konnte ich (im Vgl zur optimierten MyISAM-DB) eine Verbesserung von fast 40% erzielen (vorausgesetzt dass ich dem innodb_buffer_pool_size genügend Speicher zuweise).

Nicht schlecht, oder? Sprich, eventuell werden wir also doch bald umsteigen. Argumente gäbe es jetzt genügend.