Schritte zur Optimierung von WordPress im Hinblick auf die Serverauslastung?
Welche Schritte kann ich neben der Installation von W3 Total Cache oder einem anderen Caching-Plugin unternehmen, um sicherzustellen, dass mein Design und meine Website so schnell wie möglich ausgeführt werden?.
Sie könnten WordPress auf Nginx installieren. Es gibt eine Reihe von Ressourcen, um zu helfen:
Einige Leistungsinformationen von diesem letzten Link (der etwas anders zu sein scheint als die anderen):
Also habe ich beschlossen, einen Proxy vor WordPress in den statischen Cache zu stellen, so weit wie möglich. Der gesamte nicht authentifizierte Datenverkehr wird direkt aus dem Nginx-Dateicache bereitgestellt, wobei einige Anforderungen (z. B. die Generierung von RSS-Feeds) von 6 Seiten/Sekunde bis über 7000 Seiten/Sekunde verarbeitet werden. Oof. Nginx kümmert sich auch um das Protokollieren und Gzippen, sodass die schwereren Back-End-Apaches das tun, was sie am besten können: Dynamische WordPress-Seiten werden nur bei Bedarf bereitgestellt.
...
Auf Nginx - es ist so effizient, dass es beängstigend ist. Ich habe noch nie gesehen, dass mehr als 10 bis 15 Megabyte RAM und ein bisschen CPU verbraucht werden, selbst unter unserer höchsten Last. Unsere Gangliendiagramme lügen nicht: Wir haben unseren Speicherbedarf halbiert, unseren ausgehenden Netzwerkdurchsatz verdoppelt und unsere Last vollständig ausgeglichen. Wir haben im Grunde keine Probleme gehabt, seit wir dies eingerichtet haben.
Legen Sie clientseitige Ablaufzeiten für Dinge wie CSS, Bilder, JavaScript usw. fest, die nicht für jeden Seitenaufruf erneut heruntergeladen werden müssen. Dies hat bei weitem den größten Unterschied bei den Ladezeiten meiner Website bewirkt. Der schnellste Download ist der Download, der niemals stattgefunden hat ...
# BEGIN Expire headers
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 7200 seconds"
ExpiresByType image/x-icon "access plus 2592000 seconds"
ExpiresByType image/jpeg "access plus 2592000 seconds"
ExpiresByType image/png "access plus 2592000 seconds"
ExpiresByType image/gif "access plus 2592000 seconds"
ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
ExpiresByType text/css "access plus 2592000 seconds"
ExpiresByType text/javascript "access plus 2592000 seconds"
ExpiresByType application/x-javascript "access plus 2592000 seconds"
ExpiresByType text/html "access plus 7200 seconds"
ExpiresByType application/xhtml+xml "access plus 7200 seconds"
</IfModule>
# END Expire headers
# BEGIN Cache-Control Headers
<IfModule mod_headers.c>
<FilesMatch "\\.(ico|jpe?g|png|gif|swf|gz)$">
Header set Cache-Control "max-age=2592000, public"
</FilesMatch>
<FilesMatch "\\.(css)$">
Header set Cache-Control "max-age=2592000, public"
</FilesMatch>
<FilesMatch "\\.(js)$">
Header set Cache-Control "max-age=2592000, private"
</FilesMatch>
<filesMatch "\\.(html|htm)$">
Header set Cache-Control "max-age=7200, public"
</filesMatch>
# Disable caching for scripts and other dynamic files
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
</IfModule>
# END Cache-Control Headers
Sie können alles, was Sie können, vor-gzipen (7-Zip ist ein gutes Werkzeug dafür) und es an derselben Stelle hochladen, an der Sie gerade gzipten. Ändern Sie die .htaccess-Datei, um die vor der Gzip-Übertragung gespeicherten Dateien wie folgt bereitzustellen. Die Einschränkung hier ist, dass Sie daran denken müssen, sie erneut zu komprimieren, wenn Sie Dinge aktualisieren. Dies reduziert den CPU-Aufwand, abgesehen vom Parsen von .htaccess.
RewriteEngine on
#Check to see if browser can accept gzip files. If so and we have it - serve it!
ReWriteCond %{HTTP:accept-encoding} gzip
RewriteCond %{HTTP_USER_AGENT} !Safari
#make sure there's no trailing .gz on the url
ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$
#check to see if a .gz version of the file exists.
RewriteCond %{REQUEST_FILENAME}.gz -f
#All conditions met so add .gz to URL filename (invisibly)
RewriteRule ^(.+) $1.gz [QSA,L]
Dies ist nur eine grobe Antwort. Es gibt viele Variationen zu diesem Thema. Ich habe darüber gebloggt und einige Verweise auf ausführlichere Artikel unter http://icanhazdot.net/2010/03/23/some-wordpress-stuff/ hinzugefügt. Lesen Sie das und, was noch wichtiger ist, die Referenzen, auf die ich verweise - sie sind gute Ressourcen.
Beachten Sie, dass Benutzer ihren Cache aktualisieren müssen, wenn Sie häufig basteln.
Ein Plugin, das ich auch sehr nützlich fand, ist wp-minify . Beachten Sie dabei, dass Sie seitenbezogene Elemente (Kontaktformular, Schieberegler für die Startseite usw.) ausschließen sollten, damit Sie nicht für jede Seite den gesamten Satz von CSS, JS usw. erneut herunterladen. Dies ist ein guter Weg, um CSS, JS usw. zu minimieren, zu kombinieren und zu komprimieren. Wp-minify spielt gut mit Supercache und auch mit Ablauf-Headern, die ich oben beschrieben habe.
Verwenden Sie Yslow in Firebug (Firefox) oder einem ähnlichen Programm, um Ihre http-Anforderungen zu überwachen und festzustellen, was komprimiert ist und was nicht. Schauen Sie sich auch die Ablauf-Header an. Sie werden bald sehen, was Sie verbessern können.
Minimieren Sie die Anzahl der Plugins, die Sie ausführen, auf das, was Sie wirklich benötigen. Beachten Sie insbesondere Plugins, die beim Laden jeder Seite JavaScript- und CSS-Code hinzufügen, auch wenn dieser Code nicht auf der Seite verwendet wird.
Wenn Sie Ihr eigenes Design von Grund auf neu erstellen, teilen Sie Ihr CSS so auf, dass Funktionen, die nur für bestimmte Seitenvorlagen oder Ansichtstypen (einzelne Posts, Archive, Kategorien usw.) erforderlich sind, nur bei Bedarf geladen werden.
Konfigurieren Sie W3TC für die Verwendung eines CDN (wie Amazon CloudFront oder eines der anderen von W3TC unterstützten).
Überprüfen Sie, ob die Minify-Optionen für Sie funktionieren (einige Plugins generieren js/css, die sich nicht gut minimieren lassen. Testen Sie daher Ihre Site, nachdem Sie die Minify-Funktion aktiviert haben).
Wenn Sie die vollständige Kontrolle über Ihren MySQL-Server haben, stellen Sie sicher, dass der query_cache aktiviert ist. Verwenden Sie ein MySQL-Optimierungsskript , um andere Möglichkeiten zur Optimierung Ihrer Datenbankkonfiguration zu finden.
Wenn die Verwendung eines CDN aus irgendeinem Grund problematisch ist, konfigurieren Sie mod_expires in Ihrem Apache-Setup. Stellen Sie die Ablaufzeiten so lange ein, wie es für statische Typen wie Bilder, CSS, Javascript, Video, Audio usw. angemessen ist.
Führen Sie memcached aus und verwenden Sie einen Objektcache , um die Anzahl der Datenbankabfragen zu verringern. Dadurch werden Daten aus der Datenbank und nicht Seiten zwischengespeichert. Ich bin mir nicht sicher, ob w3-total-cache dies bereits tut.
Stellen Sie sicher, dass Sie einen Opcode-Cache wie APC ausführen. (Es sind mehrere weitere verfügbar.)
Platzieren Sie Ihr Blog nicht nur wie wp-cache auf einem Host-Volume, auf dem die Eigenschaft "noatime" festgelegt ist. Andernfalls führen Sie SSH in Ihren Host ein (sofern Ihr Webhost dies bereitstellt) und führen Sie diesen Befehl regelmäßig alle paar Tage für Ihre Dateien aus:
chattr -R +A ~/*
Das ~/* bedeutet "meine Dateien unter meinem Home-Verzeichnis". Sie können diesen Pfad nach Belieben ändern. Sie können dies auch in einem Cron-Job in cpanel einrichten, wenn Ihr Webhost dies bereitstellt.
Weitere Informationen zur Eigenschaft atime finden Sie unter this . Dies beschleunigt die Leseleistung von Linux-Festplatten erheblich.
Manchmal wird Ihre Website von Spinnen gehämmert. Sie können ein Tool wie SpyderSpanker oder Chennai Central verwenden, um Spinnen herauszufiltern, die nicht dazu beitragen, mehr Page Rank auf Ihre Website zu bringen und sie lediglich zu verlangsamen, und dann gute Spinnen (wie Google, Bing usw.) zu drosseln, indem Sie sie zufällig senden HTTP 304 Nicht geänderte Nachrichten.
Eine andere Sache, die ich sehe, sind nur schlecht geschriebene Plugins. Wenn Sie lernen, wie Plugins erstellt werden, werden Sie feststellen, dass einige Plugins ineffizient codiert sind, oder Sie finden sogar Zeitbomben, z. B. eine Datenbanktabelle, die gefüllt und nie bereinigt wird und z. B. eingehende Verbindungsdaten speichert.
Neben allen anderen hier beschriebenen Lösungen können Sie auch eine WordPress-Webfarm für Ihr Blog erstellen, indem Sie sie auf mehreren Webknoten-PCs hosten, die alle eine Verbindung zu einer einzelnen Datenbank und einem einzelnen Datenträger für die Dateien herstellen (z. B. einem über NFS gemounteten Datenträger) ). Schauen Sie sich Ultra Monkey an, um herauszufinden, wie das alles funktioniert.
Ein paar Antworten aus meinem Kopf:
1) Minimieren Sie die Anzahl der HTTP-Anforderungen, die der Browser an Ihren Host senden muss, indem Sie, wo möglich/praktisch, JavaScript und CSS verketten.
2) Laden Sie so viel wie möglich von Ihren Images/Medien, die für Drittanbieter-CDNs bereitgestellt werden, herunter, insbesondere wenn Sie Shared Hosting verwenden.
3) Reduzieren Sie die Anzahl der auf der Startseite angezeigten Posts, um die gesamte Renderzeit zu verkürzen.
3a) Versuchen Sie, ein Thema zu verwenden, das einige der vorgestellten Beiträge auf der Titelseite und alle anderen, älteren Beiträge als Auszüge enthält.
Durch Zwischenspeichern des WordPress-Menüs erhalten Sie außerdem eine Leistungssteigerung. Besonders wenn Sie viele Seiten oder eine riesige Menüstruktur haben, sollte dies berücksichtigt werden.
Mach es in 2 einfachen Schritten. Erstellen Sie zunächst eine Funktion, die das Menü abruft oder erstellt, anstatt wp_nav_menu direkt aufzurufen.
function get_cached_menu( $menuargs ) {
if ( !isset( $menuargs['menu'] ) ) {
$theme_locations = get_nav_menu_locations();
$nav_menu_selected_id = $theme_locations[$menuargs['theme_location']];
$termslug = get_term_by( 'id', $nav_menu_selected_id, 'nav_menu' );
$transient = 'menu_' . $termslug->slug . '_transient';
} else {
$transient = 'menu_' . $menuargs['menu'] . '_transient';
}
if ( !get_transient( $transient ) ) { // check if the menu is already cached
$menuargs['echo'] = '0'; // set the output to return
$this_menu = wp_nav_menu( $menuargs ); // build the menu with the given $menuargs
echo $this_menu; // output the menu for this run
set_transient( $transient, $this_menu ); // set the transient, where the build HTML is saved
} else {
echo get_transient( $transient ); // just output the cached version
}
}
Ersetzen Sie in Ihrem Design den wp_nav_menus durch get_cached_menu. Jetzt haben Sie jedes Mal, wenn das Menü aufgerufen wird, eine Datenbankabfrage anstelle der gesamten Menüerstellung.
Menüs ändern sich nicht oft - aber Sie müssen sich auch in die Aktion wp_update_nav_menu einhängen, um die alten Übergänge zu löschen.
Mach es so:
add_action('wp_update_nav_menu', 'my_delete_menu_transients');
function my_delete_menu_transients($nav_menu_selected_id) {
$termslug = get_term_by( 'id', $nav_menu_selected_id, 'nav_menu' );
$transient = 'menu_' . $termslug->slug . '_transient';
delete_transient( $transient );
}
Das Menü wird beim nächsten Aufruf der Seite generiert. Verwenden Sie die zwischengespeicherte Version, bis das Menü erneut aktualisiert wird.
Aktualisierte Version
Vielen Dank an @helgatheviking für den Hinweis auf einen Fehler zwischen Slugs und IDs. Ich habe die Funktionen so aktualisiert, dass sie sowohl mit theme_position als auch mit menu funktionieren (für einen direkten Aufruf des Menüs).
Die Menüs werden immer mit dem Namen des Menüs gespeichert, nicht mit der Position im Thema.
Verwenden Sie eine Datenbankklasse, die für die Optimierung zugeschnitten ist. Wir haben gute Erfahrungen mit eigenem Code gemacht, um die Speichernutzung und die Geschwindigkeit des Datenbankzugriffs zu reduzieren. Darüber hinaus können Sie die Datenbankstruktur selbst durch einige kleine Änderungen optimieren, die ebenfalls viel bewirken.
Ein Teil des Datenbankklassencodes befindet sich im WordPress-Trac, er hat es nicht in den Core geschafft ( Ticket # 11799 und zugehöriges ).
Für eine stark frequentierte Site sollten Sie alle MySQL-Puffer auf den jetzt vorhandenen Inhalt abstimmen. Unabhängig von der WordPress-Version kann die Konfiguration der MySQL-Ebene berechnet werden .
Wenn Sie InnoDB-Daten haben, ohne innodb_file_per_table zu aktivieren, müssen Sie InnoDB bereinigen, indem Sie jede Tabelle in ihren eigenen physischen Tabellenbereich segmentieren . Es ist möglich, ordentliches MySQL-Tuning durchzuführen auch wenn Sie eine eingeschränkte Hardware haben . Es gibt viele Szenarien für solche InnoDB-Optimierungen .
IMHO können Sie keine guten Einstellungen für my.cnf planen, ohne die zu konfigurierende Datenmenge zu kennen. Sie müssten regelmäßig einen aktuellen Datensatz aus der Produktion in eine Staging-Umgebung laden, Optimierungen durchführen und die zu konfigurierenden Zahlen in der Datei my.cnf des Produktionsservers bereitstellen.
Ich habe kürzlich über dieses Thema bei WordCamp Houston gesprochen. Alle oben genannten Empfehlungen sind großartig, und es ist wichtig, sicherzustellen, dass alle Front-End-Funktionen vollständig optimiert sind. Dann können Sie mit der Bearbeitung der Caching- und Serverleistungsprobleme beginnen.
Durch progressives Rendern fühlen sich Ihre Seiten schneller an, da der Benutzer den Seiteninhalt sieht, bevor er vollständig geladen ist. Um dies zu tun, stellen Sie sicher, dass sich alle blockierenden Js ganz unten auf der Seite und CSS oben befinden.
Wenn Sie viele Social Media-Schaltflächen verwenden, können Sie die Skripte so anpassen, dass sie nach dem vollständigen Laden der Seite in einen Iframe geladen werden. Ich habe ein Tutorial dazu geschrieben, wie man es mit dem TweetMeMe Re-Tweet-Button macht (mittlerweile veraltet, da Twitter seinen eigenen Retweet-Button veröffentlicht hat), aber es kann immer noch auf andere Share-Buttons angewendet werden.
Um die Serverleistung zu verbessern, sollten Sie Nginx als Front-End-Proxy für statischen Inhalt in Betracht ziehen, wobei Apache das schwere Heben von PHP und MySQL behandelt.
sie können die globale Ausgabekomprimierung aktivieren . Dadurch wird alles automatisch gelöscht, wenn der Browser dies unterstützt. Dies reduziert die Größe der übertragenen Dateien drastisch, erhöht jedoch die CPU-Auslastung.
Da es noch niemand erwähnt hat, besteht einer der wichtigsten Schritte zur Verbesserung der Serverleistung in Verbindung mit einem LAMP-Setup darin, zu Apache-Worker-Thread und mod_fcgid zu wechseln.
Dadurch wurden 500 MB Speicher auf meinem virtuellen privaten Server freigegeben.
Anleitung zur Überprüfung des Plugins langsamer
Es gibt ein sehr einfaches Plugin mit dem Namen Ladezeit , das den Timer für die Fußzeile der Seite hinzufügt. Es sind eigentlich nur vier Codezeilen:
<?php
function ur_pageload_footer() {
printf(__('Page in %s seconds', 'pageload'), timer_stop());
}
add_action('wp_footer', 'ur_pageload_footer')
Dann:
- Erstellen Sie eine Tabelle
- Listen Sie alle aktiven Plugins auf und fügen Sie sie dort ein
- Aktualisieren Sie die Seite dreimal und notieren Sie sich die Ladezeit der Seite pro Umdrehung
- Gehen Sie die Plugins nacheinander durch und deaktivieren Sie sie
- Wiederholen Sie Schritt 3
- Beachten Sie die Reihenfolge, in der Sie die Plugins deaktiviert haben
Ihre Tabelle sollte ungefähr so aussehen
+-------+-------+-------+-------+--------+
| Run 1 | Run 2 | Run 3 | Order | Plugin |
Wenn sich also nach dem Deaktivieren eines Plugins die Seitenantwortzeit signifikant erhöht, können Sie sehen, ob Sie dieses Plugin vermeiden können.
Ich habe zwei Plugins gefunden, die zu 'erheblichen' Verlangsamungen geführt haben mqtranslate und (das ziemlich alte, aber gute) Multi-Level-Navigations-Plugin .