Mit der Version 0.8.0 sollten nun auch die Nutzer von Windows Live Writer glücklicher sein, für alle anderen hat das Update keinerlei Auswirkungen.

Glückwünsche, Fehlermeldungen und Spenden-Möglichkeiten hier auf diesem Blog unter WordPress-Plugins / WP Permalauts.

Ein frohes neues Jahr allen Bloggern!

asaaki on blogcraft, 2012. | WP Permalauts v0.8.0 (Permalink) | Ein Kommentar | Add to del.icio.us
Post tags: blogsoftware, permalauts, plugin, update, windows live writer, wlw

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

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

Auch wenn die Anwendung natürlich noch immer in keinster Weise nutzbar ist, weil noch viele, viele Baustellen zu beackern sind und einige Applikationsdesigns erst während der Arbeit entstehen und auch mal wieder verworfen werden müssen (weil es durch einige Rahmenbedingungen doch nicht passt/funktioniert). Falls ich nachfolgend etwas falsch darstellen sollte, bitte ich dies zu verzeihen, viele Erweiterungen (RubyGems) lerne ich gerade erst kennen, und manchmal entscheidet auch eher die einfache und intuitive Bedienbarkeit. So manche Gem mag sehr gut sein, ist aber viel zu sperrig oder schwer nachzuvollziehen. Sicher wird es auch in meiner Railsanwendung Pressure Designentscheidungen geben, die bei anderen Entwicklern möglicherweise Kopfschütteln verursacht. Das muss ich in Kauf nehmen.

Gehe ich doch einfach mal auf einige Details ein (Wissen über Rails und einige RubyGems wird vorausgesetzt):

Datenbank und MongoDB

Eine NoSQL-Datenbank wie z. B. MongoDB zu nutzen, bringt manchmal gewisse Nachteile mit sich. Dies liegt zumeist daran, dass viele Erweiterungen, die selbst gern Daten in einer Datenbank hinterlegen wollen, einfach gern auf das klassische relationale Modell und deren Schnittstelle in Rails zurückgreifen. Nun versucht Mongoid ziemlich viel vom Stammhalter ActiveRecord zu imitieren, aber manchmal ist eben nicht alles 1:1 übertragbar.

So werden Assoziationen zwischen Dokumenten anders gehandhabt. Mit Mongoid ist es nämlich möglich, simple Referenzen wie auch Einbettungen zu nutzen. In Bildern gesprochen: Ich kann zwei Papier-Blätter mit einem Bindfaden aneinander binden (Referenzmodell), ich kann aber auch sagen, dass das eine Blatt gleichzeitig auch als Schublade für untergeordnete Blätter fungiert (Embedded-Modell).

Das gibt es bei den SQL-basierten Systemen ja nicht, da gibt es ja nur Tabellen, die sich hin und her verknüpfen, joinen und was weiß ich. Natürlich gibt es auch Erweiterungen, die einen Baum aufschlagen lassen (dass Trees in SQL-DBs nicht unbedingt trivial sind, hab ich schon in allerlei Beiträgen im Netz gesehen); wenn man Postgres benutzt, sollte durch die Objektorientiertheit dieser Datenbank auch das Problem gelöst sein (glaube ich jedenfalls). Aber es ist irgendwie alles nicht dasselbe wie bei Mongoid.

Achja, MongoDB kennt natürlich überhaupt keine echten Referenzen. Dieses wird letztendlich ja nur durch den Mapper Mongoid aufgelöst. In der Realität sieht es nur so aus, dass in einem MongoDB-Dokument einfach weitere Felder eingefügt werden, die als Referenz genutzt werden. Dadurch, dass man aber die interne ObjectId des Dokuments (die auch nicht vom Typ String ist!) abspeichert, könnte auch MongoDB selbst eine Logik enthalten, Referenzen von sich aus aufzulösen. Nur wie, wenn die Datenbank ja nicht weiß, was du als Nutzer wirklich an Infos brauchst. In MySQL hab ich ja auch immer selbst die JOINs schreiben müssen, weil die Datenbank das ja nicht erahnen kann. Was MySQL aber z. B. durchaus kann, ist das Behandeln von referenzierten Datensätzen; Stichwörter sind hier wohl FOREIGN KEY und die damit verbundenen Möglichkeiten, z. B. abhängige Datensätze zu löschen, wenn das Elternelement gelöscht wurde.

In Mongoid wurde das halt anwendungsseitig implementiert, mir soll’s recht sein. Als Rails-Entwickler sieht man die genutzte Datenbank ohnehin recht selten. Ich schaue zwar mit MongoVUE dennoch gern rein, um mich von angeblichen Aktionen selbst zu überzeugen, aber nötig ist es nicht unbedingt. Was noch ein spannendes Feld werden könnte, ist die MapReduce-Funktionalität, die dann doch aufzwingt, sich mehr mit MongoDB zu beschäftigen. Vorteil aber: wer einigermaßen fit in Javascript ist, wird kaum Probleme haben, die Funktionen für den MapReduce-Vorgang zu schreiben.

Natürlich muss ich also bei der Nutzung von Rails-Erweiterungen immer mal einen Blick auf eventuell genutzte Datenbank-Adapter werfen. Aber in letzter Zeit scheinen schon viele nette Dinge auch für MongoDB/Mongoid-gesteuerte Rails-Apps umgeschrieben.

So ist die Nutzung von Devise (eine Erweiterung/RubyGem für Nutzer- und Sessionverwaltung) auch mit Mongoid problemlos möglich. Anfangs wollte ich das weit verbreitete oder zumindest sehr populäre Authlogic benutzen, stellte aber fest, dass es sich nicht so schön integrieren ließ, irgendwo war da etwas, was mir nicht passte. Zu Devise gesellt sich noch CanCan als Kontrolleur für Berechtigungen (für Rollen-basiertes Accountsystem). Dieses Duo scheint gut erprobt und funktionstüchtig, warum also nicht gleich mitbenutzen, logisch.

Damit funktioniert schon einmal etwas sehr Essentielles im System, denn ohne eine Sicherungsebene wie Benutzeraccounts kann man wohl kaum ein Blog-/Redaktionssystem aufsetzen. Feinheiten, die ich noch implementieren muss, ist das Umschalten der Anmeldemöglichkeit, sowie für Admins die allgemeine Benutzerverwaltung, immerhin dürfen die ja auch andere Benutzern Rechte geben und nehmen, ggf. Accounts anlegen, löschen oder sperren.

Rails 3, Routing und CRUD/REST

Hach, was werden viele Rails-Entwickler sich freuen, wenn sie ganz einfach die Routen für ihre Controller und Actions anlegen müssen. Rails 3 macht das alles viel einfacher, solange man sich mit RESTful Web Services zufrieden gibt. Nun ist das Blöde an so einem Blog, dass auch URLs eher sprechend sein sollen, aber sicher nicht nach einer kruden Form wie example.com/posts/123 und example.com/pages/7. Sicher, die Adressen sind kurz, aber man merkt sie sich kaum. Außerdem ist es auch SEO-Sicht auch nicht so schön, jedenfalls vermuten viele Optimierer, dass Keywords auch in der URL vorhanden sein sollten. Wahrheitsgehalt hin oder her, in einem Blog soll die URL “schön” aussehen. Und dem will ich gerecht werden.

Immerhin ist es bei WordPress-Blogs ebenfalls sehr üblich, die Permalinkstruktur anzupassen und meist die Titelzeite auch als URL-Bestandteil mitzuverwenden. Darum wird Pressure dies ebenfalls, und zwar von Haus aus, verpasst bekommen. Damit darf man sich aber von den HTTP-Verben verabschieden, denn die kann man bei Posts und Pages wohl kaum verwenden. Schlimmer noch wird es, wenn man Ressourcen verschachteln muss, immerhin hat so ein Beitrag auch mal Kommentare, und will man die dann nach der REST-Regel so ansprechen müssen?

example.com/posts/123/comments/4

Ich denke, wir sind uns alle einig, das sieht nun dann doch schon ziemlich hässlich aus. Aber: nicht überall werde ich wohlgeformte URLs verwenden, im Hinterzimmer, also der Verwaltungsebene, kann und werde ich dann doch von REST/CRUD und HTTP-Verben Gebrauch machen, da muss ja in der Adresszeile nix schön aussehen, auch eine Suchmaschine sollte wohl kaum irgendwelche Admin-URLs zu Gesicht bekommen. (Schlimm wär’s, wenn doch!)

Postbote

Das Anzeigen von Beiträgen geht ebenfalls schon ganz gut. Okay, ist auch grundsätzlich keine schwere Sache. Doch auch hier steckt der Teufel im Detail. So musste ich mich ja mit Sprachversionen auseinandersetzen, denn ich will Pressure durchweg international (besser: multi-lingual) halten, und damit umfasse ich auch das Erstellen von Beiträgen in verschiedenen Sprachen. Diese müssen ja dann auch passend zur gerade aktiven Sprache korrekt ausgeliefert werden, wer das Blog in Deutsch betrachtet, will ja keine englischen Einträge lesen.

Was noch gemacht werden muss, ist das Interpretieren und Parsen von Dokumenten. Meine Überlegung hier: jeder Nutzer soll zwischen verschiedenen Möglichkeiten auswählen können, wie er einen Beitrag verfasst, sprich: welche Syntax zur Formatierung zum Einsatz kommt. Klassische Fälle wären natives HTML und Richtext-Editoren wie beispielsweise TinyMCE. Aber ich empfinde auch HAML sehr gut zum Strukturieren von Texten, daher soll auch dies verwendbar sein (meine Views werden übrigens auch durch HAML erstellt und nicht mit dem sonst üblichen ERb). Aber auch Markdown oder Textile wären weitere Optionen, genauso wie Wikitext-Syntax, die besonders die Wikipedianer sicher im Schlaf beherrschen. Und: man solle alle angebotenen Parser nebeneinander verwenden können (dazu gibt es einfach ein weiteres Feld im Dokument, in welchem dann der zu verwendene Parser steht). Also ein Blogpost in Wikitext, ein nächster in HAML, der dritte in simplen HTML und der vierte mit Markdown formatiert … Freiheit für alle! ;o)

Zudem habe ich noch neuen Input zwecks Chunks (wiederverwendbare Bausteine) und Templates (Vorlagen) für Beiträge bekommen. Soweit ich das richtig verstanden habe, wäre es schön, wenn man Textbausteine hinterlegen und auch Beitragstemplates definieren kann.

Dies wird sich insofern schwierig gestalten, dass es durch die freie Syntaxwahl auch schnell unübersichtlich werden kann. Hoffentlich fällt mir hier ein guter Kompromiss ein. Aktuell tendiere ich nun doch in die Richtung, nicht zu viele verschiedene Syntax-Parser zuzulassen. (Kann ja später als Modul nachgereicht werden.)

Auf keinen Fall will ich ein zu komplexes System a la TYPO3 in Ruby/Rails nachbauen, es soll leicht und flexibel bleiben, aber dennoch viele Freiheiten bieten. Klingt ein wenig nach der eierlegenden Wollmilchsau. Wir werden sehen.

asaaki on blogcraft, 2010. | Pressure — Statusreport #00001 (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: blog, cancan, cms, datenbank, devise, mongodb, mongoid, pressure, rails, routing, ruby, rubygems

Und zwar will ich auf das Projektmanagment hinweisen, welches auch von außen einsehbar ist, nämlich unter http://redmine.dinarrr.com/projects/pressure. Statt das weit verbreitete Trac habe ich mich für Redmine entschieden, da es selbst auch eine Ruby/Rails-Anwendung ist. Es sieht zudem etwas schöner aus und lässt sich recht gut administrieren. Ein auch für mich wichtiges Feature ist ebenfalls implementiert: Durch Commits in ein zentrales git-Repository kann ich auch Ticket-Statūs ändern lassen (habe dafür einen separaten Ticket-Status generiert, der sich passenderweise “Commit-Lösung” nennt); das hat den Vorteil, auch Tickets damit abzuhandeln, ohne gleich ins redmine gehen und das entsprechende Ticket manuell bearbeiten zu müssen.

Unsaubererweise lasse ich redmine in deutsch laufen, während ich das Projekt selbst in englischer Sprache verwalte, daher müsste ich mein redmine eigentlich auch wieder auf Englisch einstellen.

Auch eine passende Domain für Pressure selbst habe ich registriert, die Entscheidung fiel auf pressure-cms.com, da pressure.TLD für den meisten Ländern oder den CNO-Bereich bereits vergeben war bzw. einige Topleveldomains einfach zu teuer sind.

Übrigens kann man sich auf der Projektseite bereits ein kleines Bild davon machen, was schon alles passiert ist. Ticket-Anregung nehme ich gern entgegen (z. B. hier in den Kommentaren oder als Mail an pressure-dev ÄT dinarr PUNKT com), einen Reporter-Account spendiere ich nur jenen, die ein ernsthaftes Interesse an Pressure haben (damit ist es dann möglich, mir direkt auf der Projektseite Tickets zu schreiben).

Es gibt zwar auch ein zentrales git-Repository, aber aktuell belasse ich es privat (sprich: niemand außer mir kann sich den aktuellen Entwicklungsstand via git herunterladen).

Dies soweit von der Pressure-Front.

asaaki on blogcraft, 2010. | Pressure — Projekt und Entwicklung (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: entwicklung, git, managment, pressure, projekt, redmine, trac