Ein MacBook bzw. OSX ist ja ganz nett, aber wie wäre es mit ein paar persönlichen Anpassungen? Z.B. Ein neuer Hintergrund beim Login-Screen oder ein neues Bootlogo?

» weiterlesen…

Die Tage hatte ich mich wiedereinmal mit der Optimierung der „Render“-Geschwindigkeit von WordPress beschäftigt und musste schnell feststellen, dass die einfache Anzeige der Zeit + Anzahl der SQL-Queries nicht wirklich das Optimum ist. Lässt sich z.B. mit folgendem Code direkt im Template umsetzen (wird nur bei nem Userlevel > 5 angezeigt):

<?php global $userdata;
get_currentuserinfo();

?>
<?php if ($userdata->user_level > 5) { ?>( <?php echo $wpdb->num_queries; ?>q, <?php timer_stop(1); ?>s ) <?php } ?>

Aber wie schon gesagt, man sieht hier nur einen allgemeinen Trend, nicht aber welcher Teil von WordPress (z.B. welches Plugin) denn z.B. eine Bremse ist. Einen ersten Ansatz liefert z.B. das Plugin Debug-Queries von bueltge.de, noch umfangreicher und leichter zu konfigurieren gibt es das Ganze als WordPress Plugin „WP Tuner„. Das Plugin ist damit insbesondere für Entwickler eine absolute Empfehlung. Die angezeigten Ergebnisse sind unterteilt in eine Geschwindigkeitsanalyse (unterteilt in: Seitengenerierungsgeschwindigkeit, Plugin/Theme-SQL-Geschwindigeit und SQL-Tabellengeschwindigkeit) und die SQL-Abfragenanalyse (Geschwindigkeit/“EXPLAIN“). Wer selbst noch etwas Hand an WordPress anlegt, kann noch weitere „Hooks“ zur Geschwindigkeitsanalyse hinzufügen.

Eine eher unscheinbare Einstellung die es in sich hat. Standardmässig werden bei MySQL (unter Debian) die InnoDB Datenbanken/Tabellen alle in einer Datei (ibdata1) gespeichert und aufgrund der Art und Weise der Speicherung wird auch nicht mehr benötigter Speicher nicht mehr freigegeben (z.B. bei mysqlcheck -o). Aufgrund meines bisherigen Unwissens hatte sich die Datei auf über 4GB aufgebläht und ist bei einem Crash nun leider in Mitleidenschaft gezogen worden. MySQL hat daraufhin jegliche Mitarbeit verweigert und ich hatte mich auf die Suche gemacht, was es denn mit der Fehlermeldung auf sich hat und bin dabei über „innodb_file_per_table“ gestolpert. Hat zwar nicht geholfen die Daten zu retten, aber erspart mir vll. in Zukunft das eine oder andere Problem.

Damit nicht mehr alle Tabellen in einer Datei gespeichert werden, muss die Konfiguration (my.cnf) um „innodb_file_per_table“ erweitert werden. Einen Haken hat die Sache allerdings, die Änderung gilt nur für neue Tabellen. Die bisherigen Tabellen werden auch weiterhin in ibdata1 gespeichert. Der Versuch mit ALTER TABLE <table> ENGINE=InnoDB; hat bei mir leider nicht funktioniert. Und so blieb mir nur der Umweg, alle Datenbanken zu sichen, zu löschen und nochmal von vorne Anzufangen (mysql_install_db) und die Backups zurück zu spielen. Aufgrund der Datenmenge zieht sich das Ganze allerdings sehr in die Länge :(

Bei meinen „Recherchen“ bin ich auch noch über „MySQL Tuner“ gestolpert. Und muss sagen, auch das Tool gefällt mir. Bisher hatte ich auf tuning_primer.sh gesetzt, werde in Zukunft aber auch den MySQL Tuner befragen.

Nunja, wie heisst es doch so schön, Unwissenheit schützt vor Strafe nicht. Es ist mir allerdings unbegreiflich, weshalb die Einstellung nicht standardmässig auf einzelne Dateien gesetzt ist. Vorteile dieser Methode sind mir aktuell auch noch unbekannt. Werde aber versuchen mich noch weiter Schlau zu machen, aber vll. hat ja jemand ein paar Info’s?

Dann kann man mit dem Server nicht mehr viel anfangen… So geschehen auch heute morgen. Die Probleme hatte ich schonmal mit dem Server, und daraufhin die MySQL-Server-Einstellungen „optimiert“, aber anscheinend war das noch nicht ausreichend. Die Empfehlungen von „tuning-primer.sh“ habe ich in der Zwischenzeit eingearbeitet. Aber so langsam gehen mir die Ideen aus… Hat jemand Tipps?