Umlaute in der Datenbank von latin1 nach UTF8 korrigieren

Lange habe ich das Problem mit den Umlauten in meinem Blog vor mich hergeschoben, aber heute habe ich endlich mal die Zeit genutzt und das Problem beseitigt. Schon vor einiger Zeit habe ich Dank WordPress von latin1 auf utf8 umstellen ein Lösung des Problems gefunden. Ich weiß gar nicht mehr so genau wie das eigentlich bei mir passiert ist. Entweder als ich von 1blu zu 1&1 gewechselt habe oder als ich ein neues Image auf dem 1&1 vServer installiert habe. Na jedenfalls hatte ich das Problem bis eben, dass die Umlaute in bestimmten, hauptsächliche ältere Beiträge, nicht korrekt („ĂĽ“ statt „ü“, „ö“ tatt „ö“, etc.) angezeigt wurden. Nun habe ich das Tool „DSB’s Umlaut Korrektur (DUK)“ des MySQLDumper-Entwicklers ausprobiert und es hat geklappt.
Das Programm ist eigentlich ganz einfach gestrickt: Vorher am besten ein Backup der Datenbank machen. Schließlich kann immer etwas schief gehen! Die ZIP-Datei runterladen und entpacken. In die mitgelieferte PHP-Datei „dsdb_wrapper.php“ noch die Zugangsdaten (Server, DB-Name, Passwort) zur Datenbank eintragen und diese dann per FTP auf den Server laden. Anschließend muss man nur noch die mitgelieferte EXE-Datei „duk.exe“ starten und dort den Pfad zur PHP-Datei „dsdb_wrapper.php“ auf dem Webserver eintragen. Jetzt ist man eigentlich nur noch 4 Klicks vom Erfolg entfernt. Den ersten Klick macht man auf „Verbinden“. Bei erfolgreicher Verbindung sollten unten schon die Tabellen der DB angezeigt werden. Anschließend klickt man auf „Spaltenstruktur analysieren“. Danach auf „Umlaute prüfen“ und dann auf „Umlaute korrigieren“. Nun werden alle Umlaute automatisch korrigiert. Als Abschluss würde ich empfehlen die PHP-Datei „dsdb_wrapper.php“ vom Webserver nach getaner Arbeit wieder zu entfernen. Sicher ist sicher ;)

Weitere Informationen zum Thema: Workshop gegen das Chaos | Upgrade erfolgreich, Umlaute tot

WordPress und MySQL optimieren

Gestern hatte ich  mit Gilly kurz über MySQL-Datenbanken und WordPress gesprochen. Gerade bei vielen Zugriffen auf ein Blog müssen MySQL und PHP einiges an Arbeit leisten. Bei vielen gleichzeitigen Zugriffen auf das WordPress Blog, kann es passieren das die Datenbank und das WordPress langsam oder gar nicht funktionieren. Damit dieses Verhalten etwas eingegrenzt wird, muss man zu einigen Optimierungstricks greifen.
Sofern möglich sollte man seine Hardware vom Server etwas optimieren. Manchmal reicht es schon aus CPU, RAM oder Festplatte auszutauschen. Rüstet man den Server mit mehr RAM aus, so können Datenbankabfragen in diesem zwischengespeichert werden oder mehr Speicher für die PHP-Engine reserviert werden. An die Festplattenperformance denken die wenigstens. In den meisten Servern werden heute SATA oder SATA2 Festplatten benutzt. Aufgrund von Datensicherheit und Redundanz wahrscheinlich auch noch im RAID-Betrieb. Leider kommt es auch oft genug vor, dass man zwar eine SATA2 Festplatte hat, diese aber nur mit SATA angesprochen wird. Das sollte man ändern, um mehr Geschwindigkeit zu bekommen. Wer noch mehr Geschwindigkeit rausholen möchte sollte gleich zu SAS-Festplatten greifen. Die sind noch einen Tick schneller und auch sicherer.
Wenn man keinen Einfluss auf die Hardware-Konfiguration hat, dann muss man es eben mit Software-Tricks versuchen. Die meisten von ihnen beruhen auf die Nutzung von zusätzlichen Caches.
Bei MySQL gibt es gleich mehrere Möglichkeiten die Performance zu optimieren. Die wichtigsten Optimierungsvariablen in der my.cnf sind wohl key_buffer_size und table_cache. Optimale Werte für einen Server mit mehr als 512 MB Speicher wären zum Beispiel: key_buffer=64M; table_cache=256; sort_buffer=4M; read_buffer_size=1M. Bei einem vServer von 1&1 hat man die Werte so eingestellt: key_buffer = 16M; table_cache = 64; sort_buffer_size = 512K; read_buffer_size = 256K. Um die optimale Performance zu schaffen, sollte man mit den Werten etwas herumprobieren. Eine dritte Möglichkeit gibt es bei MySQL aber noch, den Query Cache. Hierfür muss man in seiner my.cnf die Variablen query_cache_size, query_cache_type und query_cache_limit eintragen und mit Werten versehen. Näheres dazu findet man im Netz und in der Doku. Ich benutze bei einigen Blogs die Werte query_cache_limit = 1M; query_cache_size = 32M; query_cache_type = 1. Bis jetzt laufen diese ganz gut damit.
Um die Performance von PHP zu steigern bieten sich mehrere Lösungen an. Es reicht nicht immer aus der PHP-Engine mehr Speicher zuzuweisen, sondern man muss auch die Möglichkeit von Caching in betracht ziehen. Die gängigen Lösungen hierfür sind wohl ZEND und memcached. Eine kleine Übersicht der PHP-Beschleuniger gibt es hier.
Mit diversen Plugins für WordPress kann man auch dort etwas Performance rausholen. Wichtige Plugins hierfür sind zum Beispiel WP-Super-Cache und, sofern nötig, WP-Widget-Cache. WP-Super-Cache kann eigentlich alles was man braucht. Ist das Plugin aktiviert und konfiguriert, so werden bei Aufruf eines Blogposts eine statische Kopie davon in einem Verzeichnis abgelegt. Ruft jetzt wieder jemand diesen Post auf, dann kommt dieser aus dem Cache (statische Kopie) von WP-Super-Cache. Das ganze funktioniert so gut, dass ich es eigentlich standardmäßig in jeden Blog installiere.
Die vorgestellten sind einige Möglichkeiten. Aber es gibt sicherlich noch einige mehr. Manchmal liegt die Performance des Blogs auch nicht am Server, PHP, MySQL oder WordPress, sondern kann auch an der DNS-Auflösung liegen oder an der Einbindung von sehr vielen externen Skripts oder Bildern liegen.

Cheat Sheets für Web Designer und Developer

Cheat Sheets finde ich immer gut. Gestern bin ich wieder über welche gestolpert: Cheat Sheets für Web-Developer und Cheat Sheets für Web-Designer. Hier gibt es noch welche!

Laconica: dezentrales twittern

Heute schau ich mir mal Laconica an. Laconica ist ein Twitter-Klon auf PHP und MySQL. Bin schon bei der Installtion, welche wirklich nicht einfach ist. Es müssen bestimmte Libaries insatlliert sein. Bin mal gespannt wie das so funktioniert. Suche schon lange nach einer Lösung im Intranet zu twittern.
Laconica ist aber auch keine unbekannte Software mehr. Seitdem Start von identi.ca sind weitere Server im Netz, die diese Software benutzen. Die Features von Laconica können sich aber auch schon sehen lassen:

The current release of Laconica has a basic microblog feature set, and new features will likely be added rapidly.

  • Updates using a Jabber client
  • OpenID authentication
  • Subscribing to notices by users on a remote service through OpenMicroBlogging
  • SMS updates and notifications
  • A Twitter-compatible API

Upcoming priority features:

  • More AJAX-y interface
  • Maps
  • Cross-posting to Twitter, Pownce, Jaiku, etc.
  • Pull messages from Twitter, Pownce, Jaiku, etc.
  • Facebook integration
  • Hashtags
  • Image, video, and audio notices
  • Automatic url-shortening
  • Multilingual interface (using Gettext) via: Wikipedia

Der große Nutzen ist, dass Nutzer verschiedener Laconica-Installationen miteinander komunizieren können, ohne auf dem gleichen Server zu sein. Es muss also nicht mehr alles über einen Server (Twitter) laufen, sondern kann über ein dezentrales Netzwerk gehen. Dann würde die sich die Last sicher gut verteilen lasssen. Na, ich probier das mal aus …

1&1 vServer neuinstallieren

Eigentlich wollte ich letzte Nacht meinen vServer bei 1&1 neuinstallieren. Wrum? Na ja, Suse 9.3 ist wirklich mehr aktuell und wird auch nicht mehr wirklich supportet. Leider geht bei 1&1 kein update :( man kann nur alles vom vServer sichern, neuinstallieren (Image) und anschließend wieder alles einrichten. Jetzt habe ich gerade mal geschaut was ich so alles installieren kann:

1&1 vServer OS Auswahl

Letztens gab es doch noch nicht so eine große Auswahl. Jetzt bin ich am überlegen was ich installieren werde. Suse hat auf dem vServer eigentlich gute Arbeit geleistet. Aber CentOS ist auchg nicht schlecht. Hatte ich zwar noch nie auf einem vServer, aber einige andere Server klappten problemlos. Muss ich mir wohl noch mal überlegen und die Versionen (PHP, MySQL, Apache, Kernel, etc.) vergleichen. Oder habt ihr eine Empfehlung? Zeil für mich ist es, mehr Performance aus dem Server zukitzeln und natürlich wieder up2date zu sein.

Hatte ich letztens schon auf einem anderen vServer bei 1&1 gesehen, dass kein SWAP mehr angezeigt wird. Jetzt habe ich das sogar auf meinem vServer:

SWAP beim 1&1 vServer

Hmm, ist das jetzt gut oder nicht? ;) Eigentlich stand da bis jetzt immer was. Ein Neustart hat auch nichts gebracht.

vServer brauch mehr RAM und neues Linux

In letzter Zeit habe ich immer wieder einige Probleme mit meinem 1&1 vServer. Auf diesem läuft z.B. dieses Blog und noch 2 weitere. Ich sollte wirklich mal darüber nachdenken auf einen vServer mit mehr RAM zu wechseln. Momentan sollen mir 128 MB (fest) zu stehen. Das reicht manchmal nicht aus. 256 MB sollten es mindestens sein. Apache und MySQL fressen da alles auf ;) PLESK habe ich auch schon deaktiviert, damit steht mir schon etwas mehr zu Verfügung.
Ob sich 1&1 auf einen Test einlassen würde? Ich würde nämlich vorher testen wollen ob es wirklich was bringt, bevor ich dann wechsle. Außerdem sollte ich mal überlegen, auf ein neues Image umzusteigen. Momentan läuft auf dem Server Suse 9.3. Ein Update auf 10.1 ist anscheinend nicht möglich. Also geht nur eine Neuinstallation :( Das bedeutet alles vom Server runter und Backups von WordPress & DBs machen. Na mal sehen vielleicht erledige ich das schon mal diese Woche.