Nachdem vor ein paar Tagen der Release Candidate 2 von Gallery2 herausgekommen ist, habe ich mal auf diese Version aktualisiert. Die alten URLs werden wohl nicht mehr funktionieren, aber dafür ist es jetzt recht hübsch ins Blog integriert.
Test (Album einbinden):
P.S.: Ja ich weiß, dass eine Fotogalerie ohne Fotos langweilig ist ;-)
Hab ganz vergessen das wieder zu aktivieren. Das alte Plugin war ein selbst zusammengeschustertes. Das oben verlinkte hat zusätzlich eine Option „nofollow“ erst nach X Tagen zu entfernen. Auf einen Tag eingestellt gibt es einem die Möglichkeit eventuell durchgeschlüpften Spam noch zu löschen bevor er wirken kann. Perfekt!
P.S.: Alle die nicht wissen was das bedeutet mögen das hier bitte ignorieren oder einen spaßigen Kommentar dazu schreiben über den ich mich freuen kann ;-)
Falls es jemand wie ich verpasst hat. Vor ein paar Tagen gab es ein Update von WordPress. Scheinbar sehr unauffällig, denn ich hab es nicht mitbekommen. Es stopft ein Loch im XMLRPC-Interface (geeky!) und ich habe so eben darauf aktualisiert. Wenn euch irgendwelche Bugs auffallen, dann wüsste ich gerne bescheid.
Danke
P.S.: Haben wir gerade eine Art Sommerloch, das sich mit Wasser aus Regenwolken füllt?
Mal sehen, ob man tatsächlich mit einem Blogtool Beiträge über das XMLRPC-Interface schreiben kann :-)
Nachtrag: Scheint zu funktionieren (mit w.bloggar)
Nachtrag 2: Man kann sogar mit einem anderen Tool (Ecto) den Eintrag nochmal überarbeiten … schick ;-)
Schon komisch. Da fährt der „Chef“ von WordPress.org, Matt Mullenweg, für eine Woche in der Weltgeschichte herum und genau in dem Moment wird entdeckt, dass auf WordPress.org tausende von Werbeseiten liegen um Suchergebnisse für bestimmte Wörter zu verändern bzw. auf bestimmte Seiten zu lenken. Und das offensichtlich für Geld.
Nun regt sich also die ganze Welt (Bloggerwelt) darüber auf, dass jemand, der sich für den Kampf gegen Spam einsetzt (nofollow Links), selbst spamt (die genannten Dummyartikel).
Mehr darüber hier, hier, hier und hier.
Matt Mullenwegs erster Kommentar dazu: hier
Und so sah es etwa aus:
Spannend … auch wenn hier wohl gilt „sie waren jung und brauchten das Geld“ oder so … ein Spendenaufruf hätte es aber vielleicht auch getan?
Angeregt durch die Schlammschlacht auf Plasmas Blog, habe ich die letzte Stunde damit verbracht WordPress bzw. unsere PHP-Installation allgemein ein bisschen zu beschleunigen.
Ergebnis: Statt über einer ganzen Sekunde braucht eine Seite im Durchschnitt nur noch 200 Millisekunden bis sie angezeigt wird (auf einem AMD Duron 1300 MHz mit 512 MB RAM, Apache 2.x, PHP 4.3.x, MySQL 4.x unter Linux mit einem 2.4-er Kernel). Und das – wohl gemerkt – ohne die Benutzung eines Caches, der die Ausgaben von WordPress zwischenspeichert (wie es z.B. das mitgelieferte Staticize Plugin macht)
WordPress baut alle Seiten dynamisch aus einer Datenbank auf. Von daher liegt es nahe hier zuerst anzusetzen. MySQL hat ab Version 4.0.1 einen Querycache eingebaut, der nicht aktiviert war. Um ihn zu aktivieren einfach folgendes in die Datei /etc/my.cnf in die Sektion „mysqld“ eintragen:
[mysqld]
…
query_cache_limit = 2M
query_cache_type = 1
query_cache_size = 32M
…
Das und ein Neustart der Datenbank bewirken, dass Anfragen die ein Ergebnis haben, das kleiner als 2 MB groß ist, in einem Cache von 32 MB gespeichert werden.
Das wirkte schon mal Wunder. Um die Zeit weiter zu drücken, sollte man in den WordPress Optionen einstellen, dass eine bestimmte Anzahl von Artikeln angezeigt werden soll und nicht ein Zeitraum. Das senkte die Zeit die die Abfragen benötigten von ca. 300 ms auf nun ca. 30 ms. Da der Löwenanteil der Zeit aber offensichtlich wo anders verbraten wird wurde, muss noch mehr optimiert werden.
Wenn nur ein Drittel der Zeit für die Datenbank abfragen draufgehen, dann scheint wohl PHP den Rest zu verschlingen. Also habe ich erstmal den Zend Optimizer installiert. Dieser soll den Code optimieren und so für eine schnellere Ausführzeit sorgen. Tat er auch, aber das war mir nicht genug.
WordPress besteht aus einigen 100 KB PHP-Code. Nicht alles wird bei jedem Seitenaufruf geladen, aber es ist doch eine beträchtliche Menge, die da jedes mal interpretiert/kompiliert wird. Auf meiner Suche nach weiteren Verbesserungen bin ich dann beim Turck MMCache hängengeblieben. Damit läuft die Ausführung von PHP-skripten ähnlich ab wie etwa bei JSP. Der Code wird beim ersten Ausführen (nach einer Änderung an der Datei) einmal kompiliert und danach nur noch das Kompilat, welches im RAM liegt, ausgeführt. Das hat die Zeit dann fast halbiert. Prima!
Doch WordPress nahm sich immer noch fast 400 ms an Zeit :-(
Oben habe ich ja bereits auf eine Einstellungsmöglichkeit hingewiesen um die Datenbank etwas weniger zu belasten. Hier nun ein weiterer Tipp.
WordPress ist ziemlich langsam, wenn man eine andere Sprache als den Standard (Englisch) einstellt. Zum Test habe ich die entsprechende Zeile aus der Datei wp-config.php entfernt und siehe da, es lief doch deutlich schneller.
Im WordPress Supportforum habe ich dann auch schnell eine Lösung dafür gefunden. Scheinbar wird in der Version 1.5 eine ältere Version von PHP gettext verwendet. Folgt man der Anleitung aus dem Forum (neue Version drüber installieren und eine Änderung an wp-includes\wp-l10n.php) wird WordPress auch in Deutscher Sprache schneller. Besagte 200 ms waren erreicht :-)
Durch einige wenige Ein- und Umstellungen kann man eine PHP-Anwendung – und diesem Fall alle auf diesem Server laufende – deutlich beschleunigen, ohne dass man darauf achten muss, was die Anwendungen speziell so machen.
P.S.: Am Ende hat mich doch interessiert wieviel das oben genannte Staticize Plugin noch herausholen kann. Nach Aktivierung wurden die Seiten in ungefähr 30-150 ms ausgeliefert (siehe HTML-Kommentar am Ende des Quelltextes). Damit kann man ruhig auch mal auf Slashdot.org verlinkt werden ohne dass der Server in die Knie geht :twisted:
Update:
Mit Staticize Reloaded konnte man leider keine Kommentare mehr zu einem Artikel hinzufügen, da der verwendete Spamfilter (WP-Hashcash) nicht damit kompatibel ist. Auf der Homepage des Plugins steht zwar eine Anleitung wie man es trotzdem anstellen kann, dass beides miteinander funktioniert, aber die funktioniert nicht. Vorerst ist also der zusätzliche Spamschutz ausgeschaltet. Mal sehen wie sich WordPress ohne macht :-)
Es sieht so aus, als ob es am Dienstag so weit sein wird: WordPress 1.5 kommt raus, endlich ;-)
Gratulation an das gesamte Entwicklerteam. Ohne WordPress wäre diese Seite nicht, was sie heute ist. Danke!
Jetzt läuft hier die Alphaversion von WordPress 1.3 mit dem Theme „Kubrick“. Leider sahen meine eigenen Designversuche (alle!) schrecklich aus, weshalb ich jetzt erst einmal dieses Standarddesign so stehen lasse und es erst in den nächsten Tagen anpasse :-)
Hat irgendwer etwas dagegen, dass dieses Blog ein klein wenig minimalistischer wird? Gut ;-)
1 comment approved
47 comments deleted
Meine Güte …
Langsam wird es nervig. Heute bereits über 30 Comment Spams in meinem Blog und es nimmt kein Ende. Die Kommentare kommen direkt, also ohne vorherigem Herunterladen des Formulars, und von verschiedenen IP-Adressen. In der Mailingliste von WordPress hat heute jemand geschrieben, dass er bereits 120 Spams hatte und er hat auch gleich ein Plugin mit verbesserten Spamfiltern bereitgestellt. Funktioniert allerdings nur mit der CVS-Version von WordPress. Wenn das so weiter geht, dann läuft hier ab morgen Version 1.3 mit diesem Plugin … grrr