255 Zeichen!?!

Mal ganz ehrlich… Aus welchem Jahrhundert ist denn diese Einschränkung noch übrig geblieben?

Medienkompetenz unter Politikern

Wie schön, dass die Leute, die über uns und unsere Zukunft entscheiden, genau wissen, worüber sie überhaupt reden…

In ihrem eigenen Videopodcast sprach sich Kanzlerin Merkel kürzlich im Zuge des Welttags des geistigen Eigentums gegen das Herunterladen von Computern aus. Das wäre eine Sache, vor der nationale Grenzen nicht schützen würden. Sich erst informieren und dann sprechen hätte zumindest vor der Offenbahrung ihrer Unwissenheit schützen können. Auch der Bericht der Kinderreporter im Frühstücksfernsehen der ARD brachte erschreckende Erkenntnisse zutage. […] Frau Zypries gab zunächst an, sie würde im Internet nicht rumspielen. Auf die Frage, welche Browser es gibt, wusste Frau Zypries aber keine Antwort.

Siehe Gulli.

Hauptsache Entscheidungen treffen, die für die Wiederwahl sorgen. Wer braucht schon Fachkenntnisse?

Abstürze durch PHP OpCode Caches

Thomas Kruse hat auf seinem Blog everflux seine Erfahrungen zur Stabilität mit den diversen OpCode Caches veröffentlicht – mit einem ziemlich eindeutigen Ergebnis: Sie sind es allesamt nicht. Abstürze gehören wohl zur Regel.

Jetzt kommt der Haken: Ich kann das nicht bestätigen.

Wir setzen seit langem auf einigen unserer Webserver (zukünftig wohl auf allen) eAccelerator ein, und haben damit noch nie Probleme gehabt. Derzeit laufen alle unsere Server auf Intel-Prozessoren, und der Wechsel zu 64bit Betriebssystemen steht erst jetzt an – vielleicht ändert das etwas. Wir werden sehen.

Ausserdem hängt die Instabilität – allen Berichten zufolge – auch stark mit den eingesetzten Scripten zusammen.

Wir sind in der glücklichen Lage, das ohne große Auswirkungen für unsere Besucher herausfinden zu können – mehreren identische Webservern hinter einem guten Load Balancer und leistungsfähigem Server-Monitoring sei dank.

Sollte sich dann etwas anderes herausstellen, dann gibt’s das natürlich hier zu lesen.

Leute, schaut EUReKA

Irgendwie hab ich wohl einen ungewöhnlichen Geschmack, was Serien angeht… Erst vor ein zwei Monaten sind Deadline und R.I.S. „ausgelaufen“.

Und jetzt?

Laut Quotenmeter.de leiden jetzt Primeval, EUReKA und Nemesis unter Zuschauermangel.

Primeval ist ganz nett, aber verzichtbar. Grob gesagt geht es darum, dass irgendwelche Urzeitmonster durch Dimensions-Risse in unsere aktuelle Welt kommen.

EUReKA ist ein lustiger, leichter SciFi/Mystery/Comedy-Verschnitt in einer abgedrehten, kleinen Welt – hier gibt es nichts, was nicht passieren kann. Bei der Serie täte es mir sehr leid, wenn sie abgesetzt werden sollte. Mein aktueller Serien-Favorit.

Und Nemesis ist ein ziemlich düsteres „Katastrophen-Mystery“ – Aliens versuchen die Menschheit zu mutieren. Sehenswert, wenn ich auch beanstanden muss, dass sich das ganze seit der ersten Folge irgendwie nicht mehr richtig weiter entwickelt und die Spannung etwas auf der Strecke bleibt.

Also: Leute, schaut EUReKA, damit Pro7 nicht auf irgendwelche dummen Gedanken kommt.

Gewalt und Sex in Computerspielen

Ach, diese Amis… Die Seite WhatThePlay.com hat gefragt, was Eltern am wenigsten in Computerspielen (ihrer Kinder) sehen wollen. Das Ergebnis:

Platz 1: Ein Mann und eine Frau, die Sex haben
Platz 2: Zwei Männer, die sich küssen
Platz 3: Ein abgehackter Kopf
Platz 4: Das Wort „Fuck“

Ein bisschen brutale Gewalt ist ja nicht so schlimm – aber Sex und Liebe? Oh mein Gott!

Benchmarking PHP: eAccelerator und andere OpCode Caches

Die Aufgabenstellung: Die Applikationen aus unserem Hause sollen so stabil und leistungsfähig laufen wie möglich. Ein wichtiger Bestandteil der Applikations-Infrastruktur stellen in unserem Bereich die Webserver dar, die PHP-Unterstützung mitbringen müssen.

Bei meinen Versuchen, die bestmögliche, unseren Anforderungen entsprechende Serverkonfiguration zu finden, habe ich ein paar Benchmarks gemacht, die ich hier mit der Welt teilen möchte.

Die Benchmarks

Im ersten Schritt habe ich diverse OpCode Caches und den ZEND Optimizer ausprobiert.

Das Testsystem ist ein DELL PowerEdge R200 Server mit einem Core2Duo E4500 Prozessor und 4GB RAM. Darauf zugegriffen wurde über ein lokales 100 MBit Netzwerk.

Der Server läuft auf Debian Linux (64bit), als Webserver-Software kam Apache 2.2.3 mit PHP 5.2.0 über mod_php zum Einsatz. Allesamt wurden aus den Debian-Paketen installiert.

Für meine Benchmarks habe ich drei verschiedene Scripte verwendet:

  • KCAPTCHA
    Ein Script, das Captcha-Bildchen erzeugt. Dieses Script verwendet zwar relativ viel die GD2 Grafik-Library, wodurch ein großer Teil des Programmablaufs genaugenommen „fix“ ist, weil die Geschwindigkeit von GD2 nicht durch die Optimierungen verändert wird. Das Programm führt aber auch einige Schleifen und Berechnungen in PHP durch, um die Grafik vor der Ausgabe zu verzerren.
  • Viel Code, wenig Ausführung
    Das zweite war ein eigentlich sehr einfaches, selbst geschriebenes Script, das nicht viel mehr gemacht hat, als die Zahlen von 1 bis 100 in einer Schleife auszugeben. Zusätzlich habe ich allerdings (absichtlich sinnloserweise) eine 20 KByte große PHP-Datei includiert, die einige Funktionen enthält, die ich bei meinen Projekten regelmäßig verwende. Damit sollte sich die reine Aufruf-Geschwindigkeit messen lassen, ohne durch eine Script-Laufzeit groß beeinflusst zu werden.
  • WordPress
    Last, but not least, um etwas praxisnäher zu testen: Eine WordPress 2.3-Installation, in die ich mit ein paar Blindtexten gefüllt habe. Als Datenbank kam eine ebenfalls lokal auf dem Server installierte MySQL-Instanz zum Einsatz.

Als Optimierer kamen zum Einsatz:

An den Einstellungen der verschiedenen Optimizer habe ich nichts geändert, also so weit überhaupt möglich immer die Standard-Einstellungen verwendet.

Was ist ein OpCode Cache?

eAccelerator, XCache und APC stellen OpCode Caches dar. Ohne einen solchen wird bei PHP bei jedem Script-Aufruf das entsprechende Script frisch „compiliert“ und dann ausgeführt. Wenn man aber einen OpCode Cache installiert, so werden die compilierten Scripte im Speicher gehalten, so dass sie bei einem weiteren Aufruf aus der Konserve verwendet werden können. Das spart ab dem zweiten Aufruf die Compilierungs-Zeit.

Einige der Caches bringen auch noch einen Optimizer mit.

Was ist ein OpCode Optimizer?

Der ZEND Optimizer dagegen ist ein OpCode Optimizer, der versucht, PHP-Scripte bei der Compilierung zu optimieren, sie also schneller zu machen. Als Beispiel kann man sich beispielsweise eine „kleine Schleife“ vorstellen:

for ($i = 0; $i < 3; $i++) {
echo 'Schleife<br />';
}
echo 'Schleife<br />';
echo 'Schleife<br />';
echo 'Schleife<br />';

Beide Beispiele ergeben das gleiche Resultat. Das obere Beispiel ist als Programmcode vielleicht ein bisschen „hübscher“ anzusehen. Trotzdem ist die untere Variante etwas schneller. Es müssen keine Variablen initialisiert, verglichen und hochgezählt werden, es muss nicht „im Programm zurückgesprungen“ werden. Klarer Geschwindigkeitsgewinn. Noch schneller wäre es als eine einzelne „echo“-Anweisung.

Solche Muster zu erkennen und zu ersetzen ist die Aufgabe eines OpCode Optimizers.

Benchmark 1: KCaptcha

Jetzt aber zu den Testergebnissen. Um die Geschwindigkeit zu überprüfen kam das Tool Apache Benchmark. Mit diesem habe ich von einem anderen Rechner über’s Netzwerk jeweils 10.000 Anfragen an die drei Test-Scripts abgefeuert, jeweils mit 20 parallel laufenden Anfragen.

Zuerst KCAPTCHA:

Die Skala unten gibt an, wie viele Sekunden für die 10.000 Aufrufe benötigt wurden.

Klarer Gewinner hier: Der eAccelerator.

zend + eaccelerator 177,54 Sek.
eaccelerator 177,60 Sek.
xcache 183,39 Sek.
apc 187,46 Sek.
none 190,00 Sek.
zend 225,10 Sek.

Auf den ersten Blick etwas überraschend mag wirken, dass der ZEND Optimizer sowohl auf dem ersten, als auch auf dem letzten Platz zu finden ist – ja sogar langsamer ist, als wenn man ganz auf den Einsatz einer Optimierung verzichtet. Die Lösung: Im Alleingang ohne OpCode Cache braucht der Optimizer mehr Zeit zum Optimieren, als durch die Optimierungen eingespart wird.

Im Gegenzug dazu kann der Optimizer in Kombination mit dem Cache seine Stärke ausspielen: Hier muss nur ein mal optimiert werden. Bei den folgenden 9.999 Aufrufen wird auf den bereits optimierten Code zugegriffen. Bei KCAPTCHA war die Ersparnis aber eher gering, was an der Struktur des Programmcodes liegt. Hier ist einfach nicht viel zu optimieren.

Benchmark 2: Test-Script „viel Code, wenig Ausführung“

Ein ähnliches Bild ergibt sich beim zweiten Testscript:

Hier tritt noch mehr in den Vorschein, dass der ZEND Optimizer die Laufzeit optimiert. Da dieses Script aber nahezu keine „Laufzeit“ hat, sondern nahezu nur aus Compilieren besteht, liegt der ZEND Optimizer auch dieses mal ganz hinten. Wieder ist der eAccelerator der Gewinner:

eaccelerator 2,40 Sek.
apc 2,48 Sek.
xcache 2,51 Sek.
zend + eaccelerator 2,85 Sek.
none 11,60 Sek.
zend 13,80 Sek.

Man sieht aber eindeutig den Vorteil, den ein OpCode Cache mitbringt. Von 11,6 Sekunden auf 2,4 Sekunden sind durchaus spürbar.

Benchmark 3: WordPress

Zum Abschluss noch ein „praxisnäheres“ Beispiel: Im dritten Durchlauf habe ich noch eine WordPress Installation getestet, indem ich 10.000 mal die Startseite aufgerufen habe. Ziel war es, herauszufinden, ob der ZEND Optimizer an dieser Stelle seine Asse ausspielen kann.

Auch dieses mal liegt der ZEND Optimizer ohne OpCode Cache abgeschlagen hinten. Was mich allerdings ein bisschen überrascht hat: Mit eingeschaltetem eAccelerator schnitt er immer noch schlechter ab, als der eAccelerator alleine.

eaccelerator 490,74 Sek.
xcache 501,41 Sek.
apc 501,45 Sek.
zend + eaccelerator 506,40 Sek.
none 873,98 Sek.
zend 928,10 Sek.

Fazit

Was die OpCode Caches angeht kann man eindeutig feststellen, dass es sich sehr lohnt, einen zu installieren. Der eAccelerator hat bei all meinen Tests als Sieger abgeschnitten, aber auch die anderen beiden Kandidaten haben sich nur unwesentlich schlechter geschlagen. Die Geschwindigkeitsgewinne gegenüber „Kein Cache“ sind schwer in Zahlen auszudrücken, da sie von Anwendung zu Anwendung schwanken (abhängig des Verhältnisses „Compilierung“ zu „Laufzeit“). Gerade bei WordPress, der getesteten Anwendung lag sie aber bei spürbaren 78% Leistungssteigerung.

Dagegen muss ich anhand der Ergebnisse meiner Tests von der Installation des ZEND Optimizers abraten, so lange nicht wichtige Gründe dafür vorliegen, warum er laufen muss. Im Normalfall ist er kontraproduktiv und verbraucht mehr Ressourcen als er einspart.

So viel zum ersten Teil meiner Forschungsreise. Im nächsten werde ich die Performance verschiedene Caching-Mechanismen vergleichen.

Unicode, UTF-8 und so weiter…

Wer schon immer mal mehr über Unicode lernen wollte, der sollte sich mal den Artikel „The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)“ von Joel Spolsky anschauen.

Unicode was a brave effort to create a single character set that included every reasonable writing system on the planet and some make-believe ones like Klingon, too. Some people are under the misconception that Unicode is simply a 16-bit code where each character takes 16 bits and therefore there are 65,536 possible characters. This is not, actually, correct. It is the single most common myth about Unicode, so if you thought that, don’t feel bad.