Ähnliche Beiträge
- Einschränken der Daten-typen im WordPress Upload
- Trenne Logik von der Ausgabe, mittels Hooks in WordPress
- Optionen aus WordPress an JavaScripts übergeben #1
- WordPress, WPCron und die richtige Zeit
- XML zu Array mit PHP
- Einstellungen setzen bei WordPress Multisite
Journal
- Trend. Meiner.
- WordPress mehrsprachig nutzen – ein Lösungsvorschlag
- Besser die Wahrheit?
- Einschränken der Daten-typen im WordPress Upload
- Trenne Logik von der Ausgabe, mittels Hooks in WordPress
Projekte
Abonniere die neusten Artikel via Sidebar
ein-/ausblenden
eAccelerator für WordPress
Anzeige
Der eAccelerator kann auf Webservern zum Einsatz kommen, wird als Modul implementiert, ist Open Source und dient als Beschleuniger, Optimierer und Cache für PHP-Seiten. Mit Hilfe von phpinfo kann kann man schnell feststellen, ob das Modul aktiv ist - wenn ja, dann lohnt die Einbindung von WordPress. Dies ist recht einfach und dazu einige Hinweise.
Um mit WordPress den eAccelerator zu nutzen, muss der Standard Cache von WP ersetzt werden. Dazu gibt es eine Erweiterung, die ich ein wenig ergänzt habe. Die Ergänzung in der Syntax habe ich hinzugefügt, da ich im Backend von WordPress den eigenen Cache nutzen möchte, also Standard WordPress. Der Grund dafür sind diverse AJAX-Themen und dass die Aktualisierung zu gering ist. Das wirkt sich beispielsweise aus; wenn man Kommentare frei schaltet, dann wird die Zahl der ausstehenden Kommentare nicht aktualisiert. Ebenso gibt es an anderen Stellen diese Zeitspanne und daher nehme ich das Backend nicht mit in den Cache.
Nun aber zu einigen Werten, so dass man sich ein Bild machen kann, was die Nutzung des eAccelerator bei mir bewirkt hat.
Auf der Startseite bin ich ohne Optimierung mit Hilfe von Plugins oder sonstigen Geheimtricks auf 21 Queries gekommen. Nach Nutzung des eAccelerator bewege ich mich mit 8 Queries auf der Startseite und die Speicherauslastung geht von rund 18MByte auf rund 10MByte. Einfache Einblicke in den Speicher gibt beispielsweise das Plugin TPC Memory Usage und die Queries lese ich mit dem Plugin Debug Queries. Die Speichernutzung könnte man noch Steigern, in dem man zusätzlich zum eAccelerator den Zend Optimizer einsetzt. Nachlesen kann man das in diesem Beitrag WordPress memory usage reduced from 14MB to 1.4MB.
Der Cache von WordPress lässt sich einfach ersetzen, in dem an im Ordner wp-content eine Datei mir dem Namen ablegt, welche dann anstatt der WordPress eigenen cache.php gezogen wird.
if ( file_exists(WP_CONTENT_DIR . '/object-cache.php') ) {
require_once (WP_CONTENT_DIR . '/object-cache.php');
$_wp_using_ext_object_cache = true;
} else {
require_once (ABSPATH . WPINC . '/cache.php');
$_wp_using_ext_object_cache = false;
}
Diesen Weg geht auch die oben genannte Erweiterung, die ich ein wenig verändert habe, so dass im Admin-Bereich von WordPress der Cache von WordPress genutzt wird. Wer das ebenfalls nutzen möchte, der nutzt bitte den Code im folgenden und speichert ihn in einer Datei mit Namen object-cache.php. Die Original-Version, die auch gepflegt wird, findet ihr auf der Seite der Erweiterung von NeoSmart Technologies. Die bieten im übrigen auch Lösungen für den APC und XCache in Verbindung mit WordPress an.
<?php
/*
Name: eAccelerator for WordPress
Description: eAccelerator backend for the WP Object Cache, exlude the WP Backend.
Version: 0.6.1
URI: http://neosmart.net/dl.php?id=13
Author: Computer Guru
Author URI: http://neosmart.net/blog/
* Install this file to /wp-content/object-cache.php
* If on Windows, restart IIS after installing for best results
* 0.6.1 Small modification for wp-admin by Frank Bueltge - http://bueltge.de/
Thanks to Ryan Boren for his original memcached code.
*/
if ( strpos($_SERVER['REQUEST_URI'], 'wp-admin') !== false)
$wp_admin = TRUE;
// Gracefully revert to default cache if eAccelerator is not installed
if ( !function_exists('eaccelerator_get') || $wp_admin )
include_once(ABSPATH . WPINC . '/cache.php');
else {
//echo $_SERVER['REQUEST_URI'];
function wp_cache_add($key, $data, $flag = '', $expire = 0) {
return wp_cache_set($key, $data, $flag, $expire);
}
function wp_cache_close() {
return true;
}
function wp_cache_delete($id, $flag = '') {
global $wp_object_cache;
return $wp_object_cache->delete($id, $flag);
}
function wp_cache_flush() {
global $wp_object_cache;
return $wp_object_cache->flush();
}
function wp_cache_get($id, $flag = '') {
global $wp_object_cache;
return $wp_object_cache->get($id, $flag);
}
function wp_cache_init() {
global $wp_object_cache;
$wp_object_cache = new WP_Object_Cache();
}
function wp_cache_replace($key, $data, $flag = '', $expire = 0) {
return wp_cache_set($key, $data, $flag, $expire);
}
function wp_cache_set($key, $data, $flag = '', $expire = 0) {
global $wp_object_cache;
return $wp_object_cache->set($key, $data, $flag, $expire);
}
class WP_Object_Cache {
var $global_groups = array ('users', 'userlogins', 'usermeta');
var $cache = array();
function delete($id, $group = 'default') {
$key = $this->key($id, $group);
$result = eaccelerator_rm($key);
if ( $result )
unset($this->cache[$key]);
return $result;
}
function flush() {
eaccelerator_clear();
$this->cache = array ();
return true;
}
function get($id, $group = 'default') {
$key = $this->key($id, $group);
if ( isset($this->cache[$key]) )
$value = $this->cache[$key];
else
$value = eaccelerator_get($key);
$value = maybe_unserialize($value);
if ( NULL === $value )
$value = false;
$this->cache[$key] = $value;
return $value;
}
function set($id, $data, $group = 'default', $expire = 0) {
$key = $this->key($id, $group);
if ( is_resource($data) )
return false;
$data = maybe_serialize($data);
$result = eaccelerator_put($key, $data, $expire);
if ( $result )
$this->cache[$key] = $data;
return $result;
}
function key($key, $group) {
global $blog_id;
if ( empty($group) )
$group = 'default';
if (false !== array_search($group, $this->global_groups))
$prefix = '';
else
$prefix = $blog_id . ':';
return md5(ABSPATH . "$prefix$group:$key");
}
function stats() {
// Note that this is the total eAccelerator stats, not just WP but also any other apps using eAccelerator var storage
$eaccelerator_info = eaccelerator_info();
echo "<p>\n";
echo "<strong>Cached Variables:</strong> {$eaccelerator_info['cachedKeys']}<br/>\n";
echo "<strong>Cached Scripts: </strong> {$eaccelerator_info['cachedScripts']}<br/>\n";
echo "</p>\n";
if ( !empty($this->cache) ) {
echo "<pre>\n\r";
print_r($this->cache);
echo "</pre>\n\r";
}
}
function WP_Object_Cache() {
// Empty Constructor
}
}
} //End Else
?>
38 Kommentare zu „eAccelerator für WordPress“
Kommentar schreiben
Kommentar-Hilfe
händischer Spam:
Beachte die Kommentarregeln, jede Form von versuchtem Spam wird gelöscht. Warum und wieso steht in einem meiner Beiträge.
Bezug auf Textstellen:
Du kannst direkt bezug auf Textstellen im Beitrag nehmen. Dazu muss lediglich der Bereich im Artikel markiert werden; daraufhin erscheint ein Button, der den markierten Text in das Kommentarfeld übernimmt und als Zitat auszeichnet. Die Funktion ist nur bei aktivem JavaScript nutzbar.
xHTML:
Du kannst folgende Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <pre> <em> <strong> <strike> <ul> <ul> <li>
Achte darauf, wenn du Code im Kommentar hinterlegen willst, dann muss der Code maskiert sein. Dann wird er nicht interpretiert. Der Code muss mit Hilfe von HTML-Entities dargestellt werden, d.h. dass man z.B. < als < und > als > einfügt.
E-Mail-Benachrichtigung bei neuen Kommentaren ?
Wenn der Haken in der Checkbox gesetzt ist, dann wirst du über neue Kommentare vie E-Mail informiert. Der Versand erfolgt nur, wenn du die URL in der Bestätigungs-E-Mail genutzt hast oder schon Abonnent hier im Blog bist.
Kommentar erscheint nicht:
Alle Kommentare werden manuell geprüft, freigegeben und nach Möglichkeit beantwortet. Bitte um etwas Geduld und Nachsicht.
Identifikationsbilder (Avatare):
Auf Gravatar.com kann man sich mit seiner E-Mail-Adresse registrieren und ein Bild hochladen, dann erscheint dieses Gravatar hier und in vielen weiteren Blogs.
Spamschutz:
Das Kommentarformular ist mit einem Spamschutz ausgerüstet. Solltest du diesen Artikel ohne JavaScript besuchen und kommentieren wollen, so muss du die Frage beantworten und das jeweilige Wort in das Textfeld eingeben.
Das Weblog wird angetrieben von
9. September 2009 um 19:11
Läuft der interne wp-cache Mechanismus tatsächlich immer mit?
Gibt es keine wp-config.php Zeile mit der man den cache auf false setzt? Denn dann wäre ein code interessant der den wp-cache völlig abschaltet und zwar für den Redaktions- als auch den Produktions-Bereich.
Den eaccelerator und so weiter halte bei den heutigen Prozessoren ehrlich gesagt für überflüssig. Was nütze mir ein Prozessor der 10000 hits pro Sekunde verarbeiten kann, wenn ich nur 12 am Tag ausliefere und ich denke das betrifft 92% aller blogs.
Wer nutzt denn noch einen Pentium III?
9. September 2009 um 19:27
Hallo Frank,
sag mal, weißt Du ob eAccelerator bei all-inkl.com standardmäßig installiert ist? Ich habe die object-cache.php mit Deinem Code angelegt, merke aber bislang keinen Unterschied.
LG aus Berlin!
9. September 2009 um 20:12
@Daniel: der sollte nicht aktiv sein, alternativ nutze phpinfo und schaue in die Konfiguration.
9. September 2009 um 20:15
@dieter: läuft immer mit; sehe aber auch nicht, warum gerade in Produktions- und Redaktionsbereich kein Cache laufen sollte. Hier ist er doch besonders gefragt. Es gibt eine ganze Reihe von Blogs, die mehr als 12 am Tag ausliefern. Und Geschwindigkeit beim Besucher ist es immer wert.
9. September 2009 um 22:12
Bei mir brachte die reine Aktivierung des eAccelerators anstelle des ZendOptimizers in den PHP Einstellungen meines Hoster Hetzner schon sichtbares im Speicherverbrauch, statt ca. 43% sind es nun ca 11,4% bei 50MB RAM, das mit dem Cache hab ich zwar in der wp-config so drin und auch die "object-cache.php" im content Ordner mit dem Code erstellt aber bemerkbar macht sich bis jetzt noch nix, schön wäre sowas als richtiges WP-Plugin wo man eine kleine Statistik mit drin hat.
Gruß Sven
9. September 2009 um 23:04
@Sven: das ist korrekt, die reine Aktivierung cacht ja PHP. Aber der Cache von WP sollte ersetzt werden, er ist hier besser aufgehoben. Die Erweiterung hat eine Statistik, Funktion
stats(). Als Plugin geht das nicht, der Cache von WP lässt sich immer nur mit dieser genannten Methode ersetzen. Man könnte nur das Plugin für Inhalte im Backend etc. nutzen.10. September 2009 um 09:53
@Frank Danke, nun ist man wieder ein Stück schlauer, mit dem Thema Caching werde ich mich mal etwas mehr beschäftigen, der Speicherverbrauch ist ja nun schon gesenkt, jetzt gehts an den Output..
10. September 2009 um 13:09
PS: in einem aktuellen Beitrag gibt es einen Vergleich von diversen Modulen unter WordPress - wunderbar übersichtlich in einem Schema zu erkennen, Sprache ist nebensächlich
11. September 2009 um 15:44
Diese Aussage gilt aber nur, wenn man einen eigenen Server hat. Jeder der ein V-Server oder Webspace hat, muss sich den Prozessor (die Prozessoren) mit vielen anderen Benutzern teilen. Da macht es viel Sinn zu sparen.
11. September 2009 um 16:14
Danke für den Artikel Frank. Jetzt habe ich morgen, wenn es regnen sollte, was zu tun
12. September 2009 um 13:15
Als erstes: Danke!
Werde ich nun auch mal testen...
Aber damit ich alles verstehe... In welche datei steht (von Haus aus?!) die oben als erstes genannte "if file_exists" Abfrage?
14. September 2009 um 08:34
@Marc: immer wp-settings.php, im Root der Installation.
14. September 2009 um 15:26
... bedeutet, dass mir - insofern ich kein e-acc laufen habe - die Erweiterung nichts bringt? Sehe ich das richtig?
14. September 2009 um 22:31
@Daniel: ja, ohne das Modul wird die Erweiterung nicht aktiv.
22. September 2009 um 18:32
Hallo,
in dem Beitrag heißt es: "Um mit WordPress den eAccelerator zu nutzen, muss der Standard Cache von WP ersetzt werden."
Dumme Frage: Wieso muss der Standard Cache ersetzt werden? Sorry, irgendwie will mir das nicht einleuchten. :s
22. September 2009 um 20:31
@Bernd: Du hast recht, muss nicht. Will man aber mit WP den eAccelerator nutzen, intern, dann muss der eigene Cache von WP ersetzt werden, der läuft sonst im Standard, was er immer tut.
22. September 2009 um 21:07
Vielen Dank für den Artikel, hatte erst neulich bei einem Blog ein Problem mit zu groß gewordener Cache. Werd ich demnächst dann mal ausprobieren.
15. Oktober 2009 um 22:13
Hm, habe wohl ein Problem...
Verwende den Object-Cache wie oben gezeigt, aber mein Backend wird wohl doch ein wenig zuviel gecacht?!
z.B. bekomme ich keine Plugin-aktualisierungen mehr angezeigt.
Bin gerade per Zufall auf Plugins und war ganz überrascht, dass ein halbes Dutzend Updates vorliegen
Any ideas?
15. Oktober 2009 um 23:00
PS: Gerade nochmal getestet, Object-cache gelöscht:
Ein Refresh und neben dem "Plugins" Link in der Navi erscheint sofort die rote Zahl.
Mit dem Cache - nichts.
Also muss ja diese Anzahl der Aktualisierungen irgendwie ausserhalb des "wp-admin" Ausschlusses eingelesen werden?! Seltsam, irgendwie...
16. Oktober 2009 um 12:01
@Marc: ja, in dem Fall cacht der eAccelerator alles.
16. Oktober 2009 um 13:00
...kann man da vielleicht noch etwas, ausser wp-admin, aus dem Cache ausschliessen? Idee?
16. Oktober 2009 um 13:09
@Marc: habe ich schon versucht, ohne Erfolg. Ich vermute es liegt an der Methode Cache löschen, die bei mir nicht sauber klappt. Das wiederum liegt am eAccelelerator und nicht an WP.
16. Oktober 2009 um 19:38
Alles klar, danke Dir
Ich probiere jetzt mal den 0.9.6 RC von eAccelerator, vielleicht ist dort auch was anders, besser...
27. Oktober 2009 um 20:17
Halb offtopic
Frank, hast du schonmal W3 Total Cache getestet?
27. Oktober 2009 um 21:48
MArc: ja, das Plugin ist aus meiner Sicht eines der besten Plugins, die einen Cache via Plugin anbieten.
27. Oktober 2009 um 21:58
....ich habe es gerade auf einem Testblog im Einsatz.
Ist es denn sinvoll, dann noch zusätzlich diesen EA-Cache zu nutzen?
28. Oktober 2009 um 09:27
@Marc: das sind zwei paar Schuhe, den eA steuert man via RAM und damit kann schon mehr raus geholt werden. Die Plugin-Lösung ist eher dafür, wenn man den Server nicht gut kennt und man sich rein aus WP um das Thema kümmern möchte.
28. Oktober 2009 um 15:21
Bei W3 Total gefällt mir aktuell der Cache der DB-Queries via Memcached-Daemon... Das drückt die Queries richtig in den Keller.
Den Object-Cache via eA habe ich einfach auch mal dringelassen... keine Ahnung, ob die sich in die Quere kommen. Für den Moment sieht es aber gut aus!
Oh, und diese memcache-php-extension ist ja auch Ram und nicht Disk?!
28. Oktober 2009 um 16:02
@Marc: ja, aber muss Memcache dann nicht auf dem Server vorliegen; bei diversen Hostern geht immer nur eines APC; eA oder Memcache.
28. Oktober 2009 um 20:06
Ok, das stimmt natürlich...
Ich bin ein Spielkind mit Server, ich installiere was ich will
28. Oktober 2009 um 20:14
Dann wäre ein Vergleich zw. APC und eAccelerator natürlich toll
2. November 2009 um 00:12
Aktuell fahre ich wieder nur EA als object-cache, aber in einer verbesserten (?) Verison.
Zumindest wenn man der Beschreibung glauben soll, lach...
Vielleicht auch für dich mal einen Blick wert?
27. Oktober 2010 um 12:44
Ich weiß, der Artikel ist schon uralt, aber grundsätzlich arbeitet die object-cache.php ja immer noch mit der aktuellen WP-Version (ich benutze die xcache-Variante).
Kleine Frage: Woher kommt denn $wp_admin? Ich kenne nur die is_admin()-Funktion und habe diese stattdessen eingebaut.
27. Oktober 2010 um 17:21
Die Variable wird ja in den ersten Zeilen gesetzt. Im Grunde wie is_admin(), wobei die später als TRUE gesetzt wird.
27. Oktober 2010 um 20:21
Huch, da war ich etwas blind.
Was mir nebenbei (zumindest bei der xcache-Variante) aufgefallen ist, dass man neuerdings im Backend dennoch Probleme hat; frisch installierte Plugins lassen sich nicht gleich aktivieren und tauchen auch erstmal nicht in der Liste auf. (Fehlermeldung, dass das Plugin keinen validen Header hätte ...)
Mein Workaround ist, im Adminbereich das "externe" Caching komplett zu deaktivieren (und nur das WP-interne zu nutzen); da finde ich die letzte Performance-Schraube auch sehr übertrieben, es sollte ja eben doch eher sicher und ohne Fallstricke ablaufen. (Deine Variante funktionierte leider nicht bei mir.)
Kurz: Ich habe die if-Abfragen gesplittet und die wp-admin-Abfrage höher priorisiert.
Skripte und Erläuterung hier: [FIX] WordPress object-cache.php mit XCache/eAccelerator
Der Code mag dadurch zwar seltsam anmuten, aber er funktioniert seltsamerweise.
28. Oktober 2010 um 10:50
Ich lasse aktuell APC und Memcached laufen, so dass ich nicht testen kann. Aber warum nicht, die Idee war ja älter und jede Verbesserung ist willkommen. Ist gibt im Plugin-Verzeichnis auch einige Sachen dazu, eventuell hilft das noch.
28. Oktober 2010 um 12:23
Dann hab ich noch eine Frage (dann lass ich diesen "alten" Artikel aber auch in Ruhe ;o).
Ist APC mittlerweile mit xcache oder eAccelerator ebenbürtig? Bei XCache gefällt mir z. B. auch das Admin-Backend, um sich ein Bild vom Cache zu machen und ihn zu verwalten.
Im Plugin-Verzeichnis habe ich übrigens keine vernünftigen Plugins gefunden, die mit XCache oder eAccelerator arbeiten. Und bei XCache gefällt mir einfach, dass er sowohl einen opcode- als auch einen var-Cache anbietet, damit sind dann viele WordPress-eigene Caching-Plugins sogar überflüssig.
Mit memcached hab ich auch schon versucht, rumzuspielen, aber weiß nicht so recht, ob das noch wesentlich mehr rausholt, als ein nativer PHP-Cache.
28. Oktober 2010 um 13:20
Kann ich nicht sagen, da ich keinen eigenen Server habe. Wir haben aber in der Erfahrung den besten Erfolg mittels APC. Ich kenne quasi das backend dazu nicht, nutze einfach die Funktionen um flush o.ä. aufzurufen. Den APC kann man ebenso in WordPress einbinden und damit den WP eigenen Cache ersetzen, was zum Beispiel hier im Live-Blog passiert.