For my international visitors: First real english blog post on blogcraft, caused by reasons. ;o)

Some days ago I was mentioned on Google+ by Marie Axelsson, a community blogger and first line support on flattr.

She wrote a short article about some projects and works of some guys like me who need some spotlight. (Read the full article on Google+, it’s public.)

I thank her for this mention; she wrote that she like my plugin (fork) StatPress SEOlution, a statistics plugin for WordPress.

First of all, everybody has to thank the origin author of Statpress, although this plugin is abandoned (also no author infos anymore, so I can’t name him or her). Without this work I couldn’t develop my fork of it.

Next to say: also my plugin is outdated and discontinued now! Keep that in mind, please!

What does it mean? You can still use it. If it’s working you’ll fine, if not, don’t blame me, please!

I promise to publish a new statistics plugin this year. Sounds like this is a lot of time, but three month of spare time development it something like nothing, trust me.

I have some other development work in my personal pipeline which got higher priorities, but I’ll try to give the WordPress statistics plugin a chance now, because I see some user love for Statpress SEOlution the last two years.

Unless some (not all) other developers of statistic plugins I try to keep the new plugin for free and open source. But maybe ofter some time of success I’ll introduce also a light and a pro version, maybe —if I like it myself ;o)— I also create a tiny service. (This will be for users who can’t have a big database caused by their webhosting packages. Also saw some issues in performance caused by huge databases, and statistics mostly need a lot of data, so the databases sometimes grow very fast!)

I have big plans, or let’s say big ideas and visions. :o)

To help me retaining these ideas you can donate further on. It’s not a waste of money, it’s giving love and trust and thanks. It’s giving a coffee (or tea or Club-Mate) for a developer, a elixir of life!

So flattr is a nice tool for giving such help.

Some words to flattr

I like flattr, I like the idea, the concept and the current realization. In general.

But on the other hand I see a “problem” (or let’s call it issue) which is not only an issue of the flattr service itself. It’s a “community usage situation” (and the flattr system of the past).

Big and already well-known projects, services and personalities or institutions can get a mentionable value of flattr. Unknown and tiny projects won’t have a lot of the flattr ecosystem.

Out of my developers situation I can say that I got 10 times and more by direct paypal donations than by flattr donations.

I can’t say if these thankful users did better know paypal, didn’t know flattr, preferred one system or not. I gave both opportunities, there was only one winner so far.

What does this mean and how I will handle it in future?

Caused by Marie’s mention I’ll try to give both donation systems as choice, no matter what the past said.

flattr added more possibilities to add mean which is great because with the old paypal only solution you lost money twice (fees for both services). And also in Germany (not only) users want to donate without giving too much money to third parties, especially if they are disliked. I think most users love to give direct support.

[TL;DR] Many words, short conclusion

First: I’ll try to release a new statistics plugin for WordPress until the end of this year (2011)!

Second: I will use flattr also in future! I love you guys and girls behind this service! Really!

Third: I will kill these GoogleAds here! They break design and are the worst monetarization tool for tiny projects! (I have approx. 16 EUR after more than a year and need 70 EUR to get a payout! And the last month income was unbelievable 4 cents!!! Hooray!)

Bonus: I will create a new blog design for blogcraft! I need a new and fresh and clean and minimalized one!

asaaki on blogcraft, 2011. | Statpress SEOlution, statistics plugin for WordPress and flattr (Permalink) | 2 Kommentare | Add to del.icio.us
Post tags: donation, english post, flattr, paypal, plugin, statistics, statistik, statpress, wordpress

Was die Leichtigkeit betrifft: Ich wünsche mir einfach nur, dass es mal wieder weniger RAM verbraucht, denn ein gepimptes WordPress verschlingt bei mir ohne PHP-Caching und -Optimierung gut und gerne mal 50 bis 70 MiB RAM!^[01] Das war früher nicht so, zumal Webhoster auch gern das Limit bei 32 oder gar noch weniger MiB RAM ansetzten. Und ja, WordPress selbst konsumiert das meiste davon selbst, aber auch ein Redesign der Plugin-Maschinerie würde hier sicher noch Einsparungen bringen.

Zurück zur Auswertung der WordPress-Versionen:

Als Untersuchungsgrundlage benutze ich nur die englischen Archive im ZIP-Format. Zudem liste ich hier nicht alle Versionen auf, sondern ausgewählte Meilensteine bzw. Bugfix-Releases.

Schritt 1 — Wie groß sind die Archive?

Folgendes wurde dabei zu Tage gefördert:

MiB = 126.976 Byte (IEC-Präfixe zur Basis 2; Umrechnungsfaktor: 1024)

                         Datei      Größe  Steigerung
-----------------------------------------------------
       wordpress-0.71-gold.zip  0.220 MiB     --.-- %
     wordpress-1.0.1-miles.zip  0.265 MiB     20.69 %
   wordpress-1.5-strayhorn.zip  0.338 MiB     27.61 %
           wordpress-1.5.2.zip  0.349 MiB      3.06 %
             wordpress-2.0.zip  0.576 MiB     65.21 %
          wordpress-2.0.11.zip  0.611 MiB      6.11 %
             wordpress-2.1.zip  0.810 MiB     32.53 %
             wordpress-2.2.zip  0.931 MiB     14.99 %
             wordpress-2.3.zip  0.993 MiB      6.68 %
             wordpress-2.5.zip  1.304 MiB     31.30 %
             wordpress-2.6.zip  1.442 MiB     10.51 %
             wordpress-2.7.zip  1.764 MiB     22.36 %
             wordpress-2.8.zip  2.240 MiB     26.98 %
             wordpress-2.9.zip  2.399 MiB      7.09 %
             wordpress-3.0.zip  2.828 MiB     17.88 %
             wordpress-3.1.zip  2.953 MiB      4.42 %
           wordpress-3.1.2.zip  2.953 MiB      0.01 %
-----------------------------------------------------
Steigerung von Version 0.71 zu 3.1.2:       1344.68 %

Wie man gut erkennen kann, gab es teilweise erhebliche Steigerungen in der Archivgröße, das wird sich auch sicherlich in der entpackten Ordnergröße widerspiegeln, aber dazu gleich mehr.^[02]

Spannend finde ich hierbei einfach mal, das sich von der ersten Version bis zur aktuellen eine Vervielfachung um mehr als das 13-fache stattgefunden hat.

Hinweis zu den Größenangaben: Ich rechne grundsätzlich nur mit dem Faktor 1024 (IEC-Präfix, Basis 2), da dies auch alle Betriebssysteme tun, mit dem Faktor 1000 (SI-Präfix, Basis 10) rechnet eigentlich nur die Wirtschaft, die uns damit gern verwirrt. Mi steht dabei für Mebi-, was das Äquivalent zum SI-Präfix Mega- ist. Aber das ist ja eigentlich auch ein völlig anderes Thema …

Schritt 2 — Wie groß sind die Versionen im ausgepackten Zustand?

e-Größe gibt in der Liste die entpackte Größe an:

                        Archiv    e-Größe   Steigerung
------------------------------------------------------
       wordpress-0.71-gold.zip  0.603 MiB      --.-- %
     wordpress-1.0.1-miles.zip  0.863 MiB      42.95 %
   wordpress-1.5-strayhorn.zip  1.021 MiB      18.35 %
           wordpress-1.5.2.zip  1.053 MiB       3.14 %
             wordpress-2.0.zip  1.653 MiB      57.03 %
          wordpress-2.0.11.zip  1.765 MiB       6.75 %
             wordpress-2.1.zip  2.337 MiB      32.40 %
             wordpress-2.2.zip  2.756 MiB      17.93 %
             wordpress-2.3.zip  2.953 MiB       7.14 %
             wordpress-2.5.zip  3.987 MiB      35.04 %
             wordpress-2.6.zip  4.360 MiB       9.36 %
             wordpress-2.7.zip  5.383 MiB      23.44 %
             wordpress-2.8.zip  6.840 MiB      27.07 %
             wordpress-2.9.zip  7.293 MiB       6.62 %
             wordpress-3.0.zip  7.925 MiB       8.67 %
             wordpress-3.1.zip  8.236 MiB       3.92 %
           wordpress-3.1.2.zip  8.237 MiB       0.02 %
------------------------------------------------------
Steigerung von Version 0.71 zu 3.1.2:        1365.07 %

Interessant ist hier auch schon einmal das Endergebnis: nahezu die selbe Steigerungsrate wie bei den gepackten Archiven, mit nur einer minimalen Abweichung; also fast das 14-fache von der ersten bis zur aktuellen Version.

Wie man erkennen kann, sind die Kompressionsraten in ähnlichen Bereichen, manchmal konnte mehr oder weniger gut komprimiert werden, aber an der generellen Steigerung über die Zeit verändern diese ziemlich wenig. Im Schnitt sind die zip-Archive entpackt rund 3× so groß. Die tar.gz-Archive sind übrigens nur unwesentlich kleiner als die zip-Pedants, also viel mehr Kompression ist aus dem PHP-Quellcode wohl nicht herauszuholen.

Ich habe zur Sicherheit einmal auch das erste und letzte Archiv entpackt und deren Größe mit dem Unix-Befehl du überprüft, bis auf eine kaum spürbare Abweichung stimmen die Zahlen direkt aus den Archiven (der tatsächlich verbrauchte Plattenplatz hängt unter anderem auch vom verwendeten Filesystem ab).

Fazit

Letztlich bleibt, dass WordPress sich im Größenumfang immer nur erweitert. Jede Nachfolgeversion, egal ob Hauptversion (0.x, 1.x, 2.x, 3.x), Minor-Level (zweite Stelle) oder gar Patch-Level (dritte Stelle; Bugfix-Releases), wurde immer nur größer und größer. Der bisher langlebigste Zweig 2.x hat dabei den höchsten Zuwachs erlebt, von anfänglich mal rund 1,8 MiB auf letztlich 7,3 MiB, stolze 5,5 MiB mehr, oder als Faktor ausgedrückt rund 4 Mal so groß.

Bei der Rate dieses Zweiges würde uns am Ende vom 3.x-Zweig eine 32 MiB große Installation erwarten und in Version 4 würde dann die 100-MiB-Marke dann auch endlich durchbrochen.

Was man bei der ganzen Rechnerei nicht vergessen darf: das ist nur eine blanke Installation von Dateien! Keine Datenbank-Größe mitgerechnet (hätte mir zum Testen jetzt dann doch zu viel Zeit in Anspruch genommen), keine Plugins oder eigene Themes, keine hochgeladenen Dateien.

Allein der Speicherplatzverbrauch von blogcraft.de liegt aktuell bei 312 MiB (bin ich gerade selbst erstaunt), die Datenbank umfasst dank Statistik-Plugin auch einige zig Megabyte, wobei ich die entsprechenden Tabellen auch einmal von Zeit zu Zeit leere, da MySQL+Wordpress auf kleinen System irgendwie gerne lahmt, wenn die Datenbank zu groß wird.

Wer keine Statistiken irgendwelcher Art sammelt oder irgendwas mitloggt, der kann die Datenbankgröße aber in aller Regel vernachlässigen, da Texte im Vergleich zu Bildern z. B. viel weniger Platz in Anspruch nehmen.

Fotoblogger sind hier also im Nachteil, die interessieren sich dann aber auch nicht mehr für den Verbrauch einer Blanko-Wordpress-Installation. ;o)

asaaki on blogcraft, 2011. | WordPress, Versionen und Größen (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: 0.71, archiv, Größe, Speicher, Verbrauch, wordpress, Wordpress 3.1.2

Permalauts (0.7.0) ist nun mit WordPress 3.1 kompatibel!

Bitte dringend aktualisieren, wer bereits mit der aktuellen WordPress-Version arbeitet!

Die WordPress-Entwickler haben irgend etwas geändert, aber die Schuld liegt natürlich bei uns Plugin-Schreibern, weil wir ja die nicht dokumentierte Veränderung nicht bemerkt haben und eh schon die ganze Zeit falsch gecodet haben … jaja, ganz toll …

asaaki on blogcraft, 2011. | WP Permalauts Update (v0.7.0) (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: 0.7.0, permalautiert, permalautize, permalauts, plugin, update, wordpress, wp permalauts, WPL

Ich bin ansonsten immer ein Freund der Linkliebe und solange die dahinterstehende Seite seriös anmutet, werde ich kaum Probleme bei ernsthaft gemeinten Kommentaren bzw. Pingbacks haben.

Aber jene, die nur ihre SEO-Pseudo-WP-Projekte nun auch auf dem Rücken der WordPress-Gemeinschaft aufbauen wollen, jene Menschen kann ich nicht gutheißen.

Wir haben schon eine starke Community, die sich bereits auf (wenigen) einschlägigen Seiten rumtreibt, und das ist auch gut so — zu viele solcher Anlaufpunkte wären unter Umständen auch wieder dem Erfolg abträglich, gerade Neulinge in WordPress werden es zu schätzen wissen, dass sie gezielt finden können, was sie brauchen. Irgendwelche dubiosen WordPress-Wikis und WordPress-Communities, die auch einfach nicht mehr gebraucht werden, sind sinnlos und verschwendete Zeit eurerseits, zumal ihr uns auch keine nennenswerten Inhalte liefert, sondern nur billig scrapt, aggregiert und sonstwie Informationen zusammentragt, hinter der keine Leistung eurerseits steckt.

Wenn ihr jetzt noch jeden WordPress-Plugin- oder -Theme-Entwickler mit euren Spam-Kommentaren bzw. (besonders nervtötenden) Pingbacks zu Tode langweilt, wird das echt kein Spaß mehr sein, sich mit dem ansonsten recht guten System WordPress zu beschäftigen.

Investiert doch lieber eure Zeit in der schon bestehenden Gemeinschaft und tut Gutes! Und erstellt gefälligst eigene Inhalte, denn auch in der SEO-Welt ist der Leitspruch Content is King! immer noch gültig!

Vielen Dank!

Ein von euch genervter Kleinentwickler

asaaki on blogcraft, 2011. | Liebe WordPress-Projekte-Spammer, (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: community, entwickler, gemeinschaft, nervend, pingback, projekte, seo, spam, wordpress

Bitte dringend aktualisieren, wenn auch bei dir die vorherige Version nicht einwandfrei funktionierte!

asaaki on blogcraft, 2011. | WP Permalauts Update (v0.6.0.304) (Permalink) | 2 Kommentare | Add to del.icio.us
Post tags: 0.6.0.304, permalautiert, permalautize, permalauts, plugin, update, wordpress, wp permalauts, WPL

Das Plugin WP Permalauts habe ich soeben aktualisiert, Versionsnummer lautet 0.5.0.304.

Wer es bereits installiert hat, wird sicher innerhalb der kommenden 12 bis 24 Stunden von seinem WordPress darüber informiert werden. Wer es nicht installiert hat, schaut einfach mal hier oder auf der wordpress.org-Pluginseite nach.

Änderungen: Nun ist es auch möglich, die Kategorien und Schlagwort-Permalinks durch Permalauts anpassen zu lassen, damit auch eben jene URLs mit schöneren Umlaute-Umformungen daherkommen.

Zudem habe ich auch die Einstellungsseite für das Plugin erweitert und jeder kann nun einstellen, welche Permalinks angepasst werden sollen, um abwärtskompatibel zu bleiben, wird nach einem Update weiterhin nur auf Posts und Pages die Säuberung angewandt. Natürlich wird empfohlen, alles durch Permalauts verschönern zu lassen. Also einmal zu den Einstellungen gehen und entsprechend den eigenen Wünschen die Option auswählen und speichern.

Und dann werde ich noch eine Minisite für das Plugin einrichten und aufbauen, alles unter http://permalauts.de – diese Macke habe ich mir bei den Rubyisten abgeschaut, die auch für jede noch so kleine Gem gern mal eine Minisite aufsetzen, was ich aber so gar nicht mal schlecht finde, da man oftmals schon fast ohne Suchmaschine zu den tollen Projekten findet.

asaaki on blogcraft, 2011. | WP Permalauts Update (v0.5.0.304) (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: 0.5.0.304, minisite, permalauts, plugin, update, wordpress, wp permalauts

Vorab: Automattic ist die Firma, die das Hosting für WordPress sowie für das offizielle Plugin- und Theme-Verzeichnis bereitstellt, natürlich ist das auch die Firma, die die Entwicklung vorantreibt und koordiniert.

Nun zur Problematik mit dem Datenhunger: Zweimal am Tag fragt jede WordPress-Instanz (egal ob Single oder Multisite) die Server von wordpress.org, ob es neue Versionen für WordPress, Plugins und Themes gibt. Seit neuestem gibt es nun im Pluginverzeichnis auch etwas mehr an statistischen Daten, die aber bei mir und anderen Fragen aufgeworfen und ein mulmiges Gefühl hinterlassen haben (siehe oben verlinkten Beitrag). Da Automattic diese Server bereitstellt, erhalten sie unheimlich viel Einblick in die aktuelle WordPress-Landschaft, was nachfolgend kurz beleuchtet wird …

Während man zwar durch ein Plugin auch die Aktualisierungsabfrage komplett deaktivieren kann (z. B. hiermit), hat man aktuell keine Möglichkeit, die Datenflut für die Abfragen selbst einzudämmen. Unsere Blogs funken nicht einfach nur nach Hause, sie machen sich ganz schön nackig dabei!

Wenn man sich mal die wp-includes/update.php um die Zeile 58 anschaut, dann wird einem bereits schnell klar, dass ohnehin regelmäßig viel zu viele Daten an wordpress.org übertragen werden. (Dies ist nur der API-Call für den WP-Core!)

Aber die ganze Datei birgt weitere interessante Offenbarungen.

Spannender wird es nämlich dann bei Plugins/Themes, wo man im Quellcode nicht sofort erkennt, was für Daten da übertragen werden. Nach kurzer Nachforschung vermute ich aber (korrekterweise), dass auch hier unheimlich viele Daten übermittelt werden (siehe Datei wp-admin/includes/plugin.php, function get_plugin_data(), die definitiv auch durch wp_update_plugins ebenfalls mit aufgerufen wird).

Dank PHPXref (Ref für WordPress) oder einer guten IDE kann man schon mal schnell die ganzen Querverknüpfungen aufspüren, jedoch muss man für genaue Daten und deren Fluss mal eine Entwicklungsumgebung bedienen und den Debugger anwerfen, da die Kommunikation eben nicht transparent im Code hinterlegt ist. Der Kommentarblock aber verrät schon vieles:

  38   * Plugin data returned array contains the following:
  39   *        'Name' - Name of the plugin, must be unique.
  40   *        'Title' - Title of the plugin and the link to the plugin's web site.
  41   *        'Description' - Description of what the plugin does and/or notes
  42   *        from the author.
  43   *        'Author' - The author's name
  44   *        'AuthorURI' - The authors web site address.
  45   *        'Version' - The plugin version number.
  46   *        'PluginURI' - Plugin web site address.
  47   *        'TextDomain' - Plugin's text domain for localization.
  48   *        'DomainPath' - Plugin's relative directory path to .mo files.
  49   *        'Network' - Boolean. Whether the plugin can only be activated network wide.

Verknüpft mit Plugin-Status, WordPress-Version und der Quell-URL/IP weiß Automattic also, welche Plugins ich wann und wo (aktiv) benutze.

Wer mag, kann ja mal einen kompletten und ausführlichen Trace vollziehen, ich hoffe, dabei wird dann niemandem schlecht. Mir ist’s aber schon beim Gedanken daran …

Also werden alle 12 Stunden aktuelle Daten an api.wordpress.org gesendet, wie meine Plugin- und Theme-Zusammenstellung ist, auch die WordPress-Version inklusive einiger Laufzeit-Umgebungsdaten wie PHP-, MySQL-Version und noch so einige für den Update-Vorgang irrelevante Daten.

Ich befürchte, Automattic weiß schon viel zu lange viel zu viel über unsere WordPress-Installationen und die verwendeten/aktiven Plugins. Und dass sie nun mit uns Plugin-Entwicklern endlich diese Daten im gewissen Umfang teilen, ist dann sicherlich nur ein Gnadenakt!

<ironie>
Ich verbeuge mich demütigst und erfurchtsvoll!
</ironie>

Fraglich ist eigentlich, warum man den Versionscheck nicht der jeweiligen WordPress-Instanz überlässt statt dem API-Server alle Infos zu schicken. Aus meiner Sicht bedarf es ja nur des eindeutigen Plugin/Theme-Namen bzw. eine informationsfreie/datenarme Anfrage für die zuletzt aktuelle WordPress-Version (ggf. ist der Sprachcode in der Anfrage noch zulässig).

Wenn ich das so recht bedenke, muss man hier eigentlich ein Plugin für die anonymisierte Aktualisierung entwickeln, auch eine Art Update-Proxy-Dienst fiele mir da spontan ein …

asaaki on blogcraft, 2010. | [WordPress] Automattics Datenhunger (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: anonym, API, api.wordpress.org, Automattic, proxy, update, wordpress, wordpress.org, wp_update_plugins, wp_update_themes, wp_version_check

Dabei ist mir aber etwas unangenehm aufgefallen: Wenn XCache aktiv ist, hindert das ganze Gecache von WordPress-Variablen, Plugins korrekt zu installieren und zu aktivieren.

Also Installation geht noch, aber die Aktivierung nicht mehr und die Plugins tauchen auch erst einmal nicht in der Liste auf. Was hilft? Im XCache-Admin den var-Cache leeren. Aber so sollte das ja nicht ablaufen.

Jetzt habe ich die object-cache.php etwas umgeschrieben. Ab sofort wird das WP-Admin-Backend nicht mehr von XCache bedient und nur das WordPress-interne Caching darf greifen.

Ich biete die Alternativen hier als ZIP-Datei an, enthalten sind 2 Versionen: XCache und eAccelerator.

Einfach die entsprechende Datei aus dem jeweiligen Ordner kopieren und mit der im wp-content-Ordner ersetzen). Bei XCache bitte nicht vergessen, die Admin-Daten in der Datei einzutragen.

[ZIP] wordpress_object-cache.zip

Nachfolgend kurz erläutert, was passiert:

// 0.6.1.1 mod
$wp_admin = FALSE;
if ( strpos($_SERVER['REQUEST_URI'], 'wp-admin') !== false)
	    $wp_admin = TRUE;

// + 0.6.1.1 mod
// do not use any caching for admin panel!
if ( !$wp_admin || !is_admin() ) {

[... URSPRÜNGLICHER CACHE-CODE FÜR XCache/eAccelerator]

} else {
	include_once(ABSPATH . WPINC . '/cache.php'); // do NOT remove this line!
} // If (not admin)

Wie ihr seht, habe ich nur eine Art Admin-Wrapper drumherumgepackt; wenn die aufgerufene Seite nicht im wp-admin-Kontext abläuft, darf xcache/eAccelerator laufen, ansonsten eben nicht (das abschließende includen der WP-internen cache.php ist nötig, sonst seht ihr nur ein weißes Backend).

Bei meinen Tests funktionierte dann die Neuinstallation mit anschließender Aktivierung eines Plugins einwandfrei.

Ich hoffe, dass es anderen Verzweifelten ebenfalls hilft.

asaaki on blogcraft, 2010. | [FIX] WordPress object-cache.php mit XCache/eAccelerator (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: eAccelerator, fix, object-cache.php, wordpress, XCache

Gestern kam ich ja auf die wahnwitzige Idee, den zugrunde liegenden Ubuntu-Server von 9.04 auf 10.04 LTS zu aktualisieren. Zur Aktualisierungsmaßnahme gehörte dann aber auch, dass ich von dem für mich etwas sperrig anmutenden Zend-Server weg und wieder auf eine schlankere PHP-Basis umschwenken wollte. Dies tat ich auch. Dabei installierte ich PHP-FPM (http://php-fpm.org/), welches sich mit Ubuntu 10.04 auch wesentlich einfacher einrichten ließ (habe ich schon auf einem anderen Server erfolgreich erprobt). Der Vorteil bei FPM ist, dass damit umständliche CGI-Serverumgebungen vermieden werden und die PHP-Prozesse gekapselt laufen (also kein mod_php oder sonstwie tief in den Webserver verankerte Lösungen).

Wer selbst ein Setup mit nginx und PHP-FPM auf Ubuntu 10.04 LTS aufsetzen will, sollte sich folgende Anleitung zu Gemüte führen und diesen Kommentar berücksichtigen, welcher die beschriebene Vorgehensweise wesentlich vereinfacht.

Kurzanleitung:

1. PHP-ppa von brianmercer dem Repo hinzufügen [∞]
2. apt-get update
3. apt-get install php5-cli php5-common php5-suhosin
4. apt-get install php5-fpm php5-cgi
5. restart von nginx und php5-fpm
6. fertig!

Ggf. noch weitere PHP-Module nachinstallieren und php-fpm feinjustieren. PHP-FPM kann zwar selbst mehrere Gruppen verwalten (die man dann z. B. unter verschiedenen Ports oder Sockets anbietet), aber ich hab mich auf einem anderen System dazu entschlossen, init.d-Skript und Konfiguration zu splitten und mehrere unabhängige Instanzen aufzusetzen — es ist sicherlich nur eine Pseudo-Failsafe-Lösung, aber wenigstens wird nicht gleich die ganze CGI-Umgebung abgeschossen, falls ein FPM komplett abschmiert. (Wer jetzt noch mit mehreren phys./log. Servern und SAN arbeitet, kann hier sicherlich echte Failsafe-Lösungen aufsetzen; aber wer hat schon das Geld dafür?)

Nachdem ich dann alles gefixt und zum Laufen bekommen habe, ist mir dann doch aufgefallen, dass der Zend-Community-Server offensichtlich wirklich gut optimiert und die WordPress-Instanzen somit effektiv wenig RAM verbrauchten.

Mit PHP5 und FPM kam ich bei blogcraft und den vielen, vielen Plugins auf über 80 MiB RAM-Verbrauch, nach Deaktivierung und Deinstallation wirklich nicht benötigter Plugins lag ich immer noch im Bereich von 70 bis 75 MiB RAM. Also musste doch ein PHP-Cache her. Den hatte ich bereits schon installiert, aber noch nie benutzt, es war XCache, welches auch im Ubuntu-Repo zu finden ist (php5-xcache; Projektseite: http://xcache.lighttpd.net/). Diese Erweiterung für PHP muss man definitiv auch noch konfigurieren, da die Default-Einstellungen nicht zu gebrauchen sind, außerdem sollte man sowieso gleich den Admin-Zugang einrichten, damit man sich von der Arbeitweise des XCaches überzeugen kann.

Auch dies gestaltete sich wesentlich einfacher als gedacht, und die Speichernutzung reduzierte sich damit schon einmal um weitere Bytes, dennoch lag der Verbrauch immer noch bei rund 60 bis 66 MiB, was mir immer noch viel zu viel erschien. Aber man sollte XCache auch ein bisschen Zeit geben, da anfangs nur der Opcache für WordPress greift und die ersten PHP-Dateien überhaupt in dem RAM zwischengespeichert werden muss (wobei der Code wohl zudem noch in Maschinen(?)-Code übersetzt wird, was man beim XCacheAdmin gut daran erkennen kann, wenn in der Compile-Spalte ein yes steht). Letzlich kam ich noch auf einen Wert um die 40 bis 48 MiB.

Jetzt macht es aber im Falle von WordPress nicht nur Sinn, den reinen PHP-Code zu cachen, sondern auch häufig genutzte Variablen-Inhalte (die sich teilweise auch kaum ändern, z. B. Optionen), hierzu muss man aber WordPress selbst erst einmal beibringen, den XCache zu nutzen, denn dieser mischt sich bei Variablen eben nicht automatisch ein (sinnvollerweise!).

Hierfür gibt es nun auch ein “Plugin”, welches man nachinstallieren kann, leider nicht im WordPress-Plugin-Verzeichnis und leider auch nur in einer vielleicht etwas überalterten Fassung, aber immer noch lauffähig, wie mir scheint. Die Leute von neosmart haben sowohl für XCache als auch andere PHP-Caches/-Acceleratoren die nötigen object-cache.php Dateien geschrieben, die man einfach in /<wordpress>/wp-content/ ablegt.

Download: http://neosmart.net/blog/2007/xcache-and-eaccelerator-plugins-for-wordpress/

Eventuell hilft es, wenn man in der wp-config.php auch die Konstante define(‘WP_CACHE’, true) einträgt, da ich nicht glaube, dass WordPress von allein den Object-Cache aktiviert und nutzt.

Wenn man nun einen Blick in die XCache-Statistiken wirft, wird man sehen, dass nun auch der var-Cache endlich gefüllt wird.

Und nun kommen wir dann zur abschließenden Betrachtung des RAM-Verbrauchs: im Admin-Bereich zeigt sich, dass dieser nun auf rund 20 bis 22 MiB gesunken ist.

Fazit: Nach Plugin-Entschlackung und PHP-Caching eine Reduktion um den Faktor 3 bis 4!!!

Ich habe zwar kein Vorher-Nachher-Test mit ApacheBench durchgeführt, aber zumindest der Langzeit-Test im Nachhinhein ließ mich dann doch beruhigt schlafen:

ab -n 100000 -c 5 http://mannaz.cc/

Concurrency Level:      5
Time taken for tests:   6683.970 seconds
Complete requests:      100000
Failed requests:        3
   (Connect: 0, Receive: 0, Length: 3, Exceptions: 0)
Write errors:           0
Total transferred:      3989386433 bytes
HTML transferred:       3933317996 bytes
Requests per second:    14.96 [#/sec] (mean)
Time per request:       334.198 [ms] (mean)
Time per request:       66.840 [ms] (mean, across all concurrent requests)
Transfer rate:          582.87 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   238  334  69.2    332    1502
Waiting:      238  334  69.2    332    1502
Total:        238  334  69.2    332    1502

Percentage of the requests served within a certain time (ms)
  50%    332
  66%    375
  75%    399
  80%    413
  90%    428
  95%    431
  98%    435
  99%    439
 100%   1502 (longest request)

Einige Schlussbemerkungen:

Wählt den XCache-Speicher nicht zu klein!

Wer einen eigenen dedizierten Server gemietet hat, sollte genügend Ressourcen verfügbar haben, den opcode- und den var-Cache entsprechend großzügig zu gestalten. Hierbei sollte man etwas testen; gute Ergebnisse erzielte ich erst dann, als der Cache soviel fasste, dass er nicht zu 100% ausgelastet wurde.

Dabei musste ich aber mehr als nur eine WordPress-Instanz in die Kalkulation einbeziehen. Der spannende Part bleibt dabei vorerst nur der opcache, der dann sozusagen den kompletten WordPress-Code UND die Plugins fassen können sollte, ohne zu ächzen.

Schaut euch einfach an, was ihr so grundsätzlich an freien RAM habt und spendiert dem Cache einfach eine gute Portion davon. Je mehr PHP-Anwendungen ihr auf dem Server laufen habt, desto mehr Code muss zwischengespeichert werden, das zieht RAM, klar, aber es macht sich am Ende in der Leistung und Geschwindigkeit bemerkbar! Bei einem Hetzner EQ4 mit 8 GiB RAM, der vielleicht sonst eh nur idled und kaum RAM verbrät, kann man den Cache also auch mal überdimensioniert riesig gestalten. Nach einigen Tagen einfach mal im XCacheAdmin nachschauen, wie viel letztlich wirklich verbraucht wird und dann ggf. nachjustieren, falls der RAM an anderen Ecken fehlt.

WordPress-Caching-Plugins: diese könnt ihr zusätzlich installieren. Beispielsweise, um statische HTML-Seiten generieren zu lassen, die den Server somit noch weniger belasten, auch gibt es einen MySQL-Query-Speicher, der die Abfragen-Anzahl minimieren sollte und damit ebenfalls den Server schont (siehe: http://wordpress.org/extend/plugins/db-cache-reloaded/; von mir noch nicht getestet).

Und immer mal von Zeit zu Zeit ein Auge auf den tatsächlichen Verbrauch werfen, nach Flaschenhälsen schauen, nachjustieren und ggf. andere Lösungen suchen. Für PHP-Caches gibt es nebst XCache auch noch den eAccelerator, APC (welcher bei PHP 6 dann in den Kern aufgenommen werden soll) und weitere Lösungen. Auch ist der Zend-Server sicher eine Option, mir gefiel sie aber nicht so sonderlich, wobei Apache-Nutzer sicherlich durch die transparente Einbindung profitieren, da für sie kein Mehraufwand in der Webserver-Konfiguration ansteht.

Wer nicht zu den glücklichen Server-Mietern oder -Besitzern gehört: Schaut doch einfach mal, ob euer Hoster dennoch eine PHP-Cache-Lösung anbietet, selbst testen könnt ihr das z. B. mit der phpinfo()-Ausgabe.

asaaki on blogcraft, 2010. | PHP, php-fpm und xcache (Permalink) | Ein Kommentar | Add to del.icio.us
Post tags: 10.04, 9.04, apache, APC, cache, CGI, eAccelerator, LTS, mod_php, nginx, object-cache.php, PHP, php-fpm, ram, server, ubuntu, wordpress, WP_CACHE, XCache, zend

Eine der wesentlichsten Änderungen ist übrigens, dass die Single-Installation und WordPress μ (WPMU, Multi-User Variante) nun wirklich miteinander verschmolzen sind. Das erinnert an die Zeiten, wo Microsoft ihre Desktop- und Server-Schiene von Windows zusammengeführt hatte.

Ab sofort lädt man sich also nur noch eine Version von WordPress herunter und kann dann bei der Installation angeben, ob man lieber ein Einzelblog oder eine Mehrbenutzer-Umgebung à la wordpress.com erstellen möchte.

Wer seine aktuelle Installation aktualisiert, bekommt übrigens davon nix mit, die vorhandene Umgebung bleibt so, wie sie ist. Ein nachträgliches Umschalten ist eben sowenig vorgesehen.

Weitere Neuerung ist für Neulinge von Interesse: die Entwickler haben nach vielen Jahren nun auch das Standard-Theme geändert; das gute alte Kubrick hat ausgedient und an seine Stelle tritt nun ein Theme namens Twenty Ten.

Nebst kleinerer Änderungen am Admin-Interface sind die weiteren Neuerungen eher technischer Natur und meistens nur für Entwickler interessant. Spannend wird es nebenbei nun auch, wie kompatibel die alten Plugins sind bzw. wie schnell neue Versionen nachziehen, die z. B. dann auch von der neuen API Gebrauch machen, die einige Annehmlichkeiten zur Individualisierung bringen. So soll es nun leichter sein, Hintergründe, Menüs und Shortlinks anzupassen. Das werde ich mir die Tage genauer anschauen und hoffen, dass dann u. a. auch die Entwicklung für WP Statscraft schneller voranschreitet.

Im Allgemeinen wäre es daher auch ratsam, einige Tage mit dem Upgrade auf Version 3.0 zu warten, denn erwartungsgemäß verstecken sich einige Fehler in größeren Versionssprüngen, die dann noch gefixt werden müssen. Ich freue mich dann also schon auf Version 3.0.1 und 3.0.2 und so weiter und so fort … ;o)

Zum Abschluss noch das von wordpress.org zur Verfügung gestellte Video zu WordPress 3.0 – die Einführung (englisch):

(Kleiner Tipp: Wenn möglich, das Video in HD-Qualität anschauen.)

asaaki on blogcraft, 2010. | Neuer Meilenstein: WordPress 3.0! (Permalink) | Ein Kommentar | Add to del.icio.us
Post tags: 3.0, wordpress, Wordpress 3.0, Wordpress 3.0.1, Wordpress 3.0.2, wordpress mu, wp statscraft, WPMU