michi bloggt!

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.

* Server Instance Types
* Firefox Extension for Amazon EC2
* Amazon S3 Firefox Organizer
* Getting Started Tutorial
* Video: Create Your Own Customized AMI

..und die sind nicht von schlechten Eltern: http://hetzner.de/rootserver.html

z.B. 1,5 TB Festplatte, 6 GB RAM, 64Bit Dual Core für 79€ pro Monat

Relatd: Amazon E2C now offers L and XL servers (via chl)

1,7TB Festplatte, 15 GB RAM, 64Bit, 4 virtual cores für 425€ pro Monat

mod_jk bietet vier verschiedene Berechnungs-Methoden zum Verteilen der Last an:

• Request
• Session
• Traffic
• Busyness

Bei einer Server-Landschaft, bei welcher es gilt, die Requests auf gleichstarke Rechner zu verteilen, wird man mit einer Request-basierten Gleichverteilung schnell ein sehr gutes Ergebnis erzielen.

Sind aber die Rechner unterschiedlich stark, so wird man sehr viel Augenmerk auf das manuell zu konfigurierenden Aufteilungsverhaeltnis legen muessen, denn ansonsten passiert es einem leicht dass der langsamere Rechner die Performance (Requests per second) des Gesamtsystems runter zieht.

Annahme: Server A schafft 10 req/s und Server B 4 req/s. Dann erreicht man mit einem Load Balancer, welcher die Requests (defaultmaessig) im Verhaeltnis 1:1 verteilt bloss 8 req/s. Sprich durch Hinzunahme des weiteren Servers B hat man eigentlich eine schlechtere Performance als wenn man nur mit dem Server A arbeitet. Bizarr!

Nur wenn man den Load Balancer (mod_jk) die Requests im Verhaeltnis 5:2 aufteilen laesst, gelangt man in die Naehe der theoretischen 14 req/s. In der Praxis liegt man dennoch idR darunter.

Smarter waere statt einem Request-basierten Mechanismus eben ein "Busyness-Mechanismus", welcher selbstaendig beruecksichtigt welcher Server wie schnell mit einem Request fertig wird (so wie es mod_jk eigentlich auch anbieten sollte; siehe die mod_jk-Doku). Aber mit diesem konnte ich bis dato einfach in den Benchmark-Tests keine Verbesserung gegenueber den austarierten Request-basierten Mechanismus erzielen. Keine Ahnung wieso.

Die Quintessenz ist jedenfalls: In einem Web-Cluster-Setup sollte man stets gleichstarke Rechner vereinen, denn dann erspart man sich die ganze Rechnerei von vornherein.

Der dritte (knallgraue) Hackday ist vorüber, und diesmal hab ich mich doch glatt einen ganzen Tag lang verlaufen, und war mit meinem Ergebnis am Ende des Tages höchst unzufrieden.

Ich versuchte mich erneut an SolR und wollte mittels selbst geschriebener Plugins SolR das Extrahieren von berühmten Persönlichkeiten und Orten beibringen (an Hand von simplen Lookup-Listen). Aber solche Art der Daten-Analyse hätte ich viel eher bei der Daten-Aufbereitung (in Helma) erledigen können/sollen, anstatt mich mit Java-Klassen und -Interfaces herumzuärgern. Schade, denn am Ende des Tages stand ich wirklich mit leeren Händen da.

Die coolsten Hacks stammten neidlos von anderen. Johannes fabrizierte einen type-ahead Spell-Checker in JavaScript, und Thomas einen famosen Random Text Generator, welchen ich dann demnächst hier automatisiert bloggen lassen werde :-) Ich hoffe ja dass die beiden (und natürlich auch noch die anderen) über ihre Projekte noch näheres berichten werden.

Als ich unlängst meinen Rechner neu aufsetzte, verzichtete ich doch glatt auf das Aufspielen irgendeiner "halb-legalen" MS Office-Version, und es fehlt mir seither nicht im geringsten. Denn mittlerweile gibt es mit OpenOffice (nun in noch besserer Version 2.3) und Google Docs (ab sofort auch neben Word- und Excel- auch mit einem Powerpoint-Ersatz).

Kaum zu glauben, dass es Microsoft trotz Office-Konkurrenz, Vista-Pleite, Monster Pönal Strafen und fehlendem Online-Erfolg noch immer so gut geht: http://finance.google.com/finance?client=ob&q=MSFT

14 Mrd USD Netto Gewinn, oder auch 27% Gewinnspanne. Unfassbar.

A fake SMTP Server for automated testing of sending of Emails for your Java application: http://subethasmtp.tigris.org/wiser.html

Kind of like dumbster, just smarter. In particular you don't have to handle character encodings by yourself.

[so, das war nun mal wieder was technisches. zufrieden? :-)]

Heute vom Max, unserem unangefochtenen RegExp-Guru gelernt:

var rexp = new RegExp("\/sites\/([a-zA-Z0-9_-]{1,2})([a-zA-Z0-9_-]{0,50})\/media\/", "g");
str = str.replace(rexp, function(x0, x1, x2) {
  return  staticBaseUri+ "/sites/" + x1.toLowerCase() + "/" + x1 + (x2 || "")+ "/media/";
});

Sprich, man kann anstatt eines Strings auch eine Methode als zweites Argument für String.replace übergeben um das Ergebnis der Regular Expression noch weiter zu verarbeiten. Äußerst nützlich!!

Siehe auch hier die offizielle Dokumentation hierfür.

-> http://www.nengine.org/wiki/Benchmarks:Lighttpd_vs_Apache-mpm

Sowohl Lighttpd 1.5.0 mit mod_proxy_core als auch Apache 2.2.4 (mpm-worker) mit mod_jk 1.2.23 schaffen ~150 Requests pro Sekunde sind also von der Performance her identisch.

Beides sind exzellente Webserver und für Helma Load Balancing sehr gut geeignet. Man kann also mit gutem Gewissen sein Apache Setup weiter verwenden.

Bernhard Fröhlich beantwortet eine uralte Frage (siehe mod_jk vs mod_proxy), die ich mir stets alle paar Monate aufs neue gestellt hab.

Da dürfte auf alle Fälle jemand einiges mit Helma vorhaben!? :-)

Tja, scheint tatsächlich so zu sein, dass ich an meinem Samsung X20 hänge. Heuer wurde er bereits mit 2GB RAM aufgefettet, bekam das Motherboard gewechselt (noch auf Garantie!) und nun musste ich die Festplatte austauschen.

Aber weder will ich derzeit auf Vista noch auf Apple switchen. Da bleib ich lieber old school, und versuch eben das Leben des Rechners noch um paar Monate zu verlängern.