Dieser Workshop konzentriert sich auf WordPress-spezifische Möglichkeiten, und zeigt welche und wie wir bei der Blogwerk AG Performanceoptimierungen an unseren Blogs vorgenommen haben. Wichtige Themen dabei sind der Object-Cache mit verschiedenen Caching-Backends, Full-Site-Cachinglösungen, wie WP Super Cache und PHP-Optimierungen.

1. Wordpress on steroids WordcampSwitzerland Philip Hetjens Blogwerk AG 7. Mai 2011

2. Übersicht Was kann man machen Was bringt‘s Wie geht’s genau

3. Was kann man machen?

4. Anatomie eines Wordpress-Requests I PHP-Dateien PHP Webserver DB Internet Client

5. Anatomie eines Wordpress-Requests II PHP-Dateien Opcode-Cache PHP Webserver DB Internet Client

6. Anatomie eines Wordpress-Requests III PHP-Dateien Opcode-Cache PHP Webserver DB Object-Cache Internet Client

7. Anatomie eines Wordpress-Requests III PHP-Dateien Opcode-Cache PHP Webserver HTML-Cache DB Object-Cache Internet Client

8. Was bringt‘s?

9. Ausgangslage Amazon EC2 Large Instance (m1.large) 7,5 GB Speicher, 4 EC2 Compute Units (2 virtuelle Kerne mit jeweils 2 EC2 Compute Units), 850 GB lokaler Instanzspeicher, 64-Bit-Plattform «Eine EC2 Compute Unit bietet die entsprechende CPU-Kapazität eines 1,0-1,2 GHz Opteron oder Xeon Prozessors von 2007. Dies entspricht außerdem einem 1,7 GHz Xeon Prozessor Anfang 2006» Webserver-Root auf Elastic Block Storage UbuntuLucid 10.04 (64 Bit, alle Patches installiert) Lighttpd 1.4.x + PHP 5.3.x Separater Datenbankserver (gleicher Instanztyp) Performance-Tests

10. Ausgangslage Daten Von neuerdings.com Artikel: 7679 Kommentare: 28819 Test: ab -n 100 -c 10 http://neuerdings.com/ aus dem gleichen Netzwerk Gzip-Komprimierung nicht getestet Performance-Tests

11. Lighttpd + PHP 5.3 als fast-CGI Noch keine Optimierungen Standardinstallation, nur Änderung der Werte "PHP_FCGI_CHILDREN" => 18 "PHP_FCGI_MAX_REQUESTS" => 1000 50% 5646 66% 5905 75% 6113 80% 6217 90% 6821 95% 7174 98% 7528 99% 7815 100% 7815 Performance-Test

12. eAccelerator Performance-Test PHP-Dateien Opcode-Cache PHP Webserver HTML-Cache DB Object-Cache Internet Client

13. eAccelerator Hat zwei Module: Opcache-Cache und Data-Cache Vergleichbar: XCache, APC Nur Benutzung der Opcode-Caching-Funktionen (wg. CGI/unterschiedlicher Prozesse) 50% 4454 66% 4725 75% 5031 80% 5214 90% 5642 95% 5901 98% 6085 99% 6152 100% 6152 Performance-Test

14. MySQL/memcached Performance-Test PHP-Dateien Opcode-Cache PHP Webserver HTML-Cache DB Object-Cache Internet Client

15. MySQL/memcached Funktion in Wordpress Viele berechnete Ergebnisse aus Datenbankabfragen werden zwischengespeichert (z.B. Options oder User) Einfache API innerhalb von Wordpress, um auch von Plugins benutzt werden können Google: wordpress objectcache <cache-interface> (eaccelerator, memcached, xcache, usw.) Datei einfach wp-content/object-cache.php benennen Zwischenspeicherung von rund 130 Werten (bei uns) pro Aufruf Dramatische Reduzierung der Datenbankanfragen Performance-Test

16. MySQL Für ein Kundenprojekt entwickelt Speichert die object-cache-Daten in einer separaten MySQL-Tabelle Idee: Nicht bei den Datenbankabfragen selbst punkten, sondern beim Berechnen und Zusammenführen der Daten auf PHP-Ebene 50% 7148 66% 7569 75% 7902 80% 8118 90% 9021 95% 9268 98% 9825 99% 10084 100% 10084 Performance-Test Hat nicht funktioniert.HAHA

17. memcached Viel eingesetzter flüchtiger Key-/Value-Store Das Debian-Paket heisst: php5-memcache (nicht php5-memcached) Die Last auf dem Webserver verdoppelt sich 50% 3931 66% 4318 75% 4516 80% 4677 90% 4915 95% 5337 98% 5426 99% 5728 100% 5728 Performance-Test

18. WP-Super-Cache Performance-Test PHP-Dateien Opcode-Cache PHP Webserver HTML-Cache DB Object-Cache Internet Client

19. WP-Super-Cache Gegen einen Reverse-Proxy entschieden Der Einsatz eines WP-Plugins ist für uns besser zur Steuerung von Updates der Seite Requests gehen komplett an Wordpress vorbei 50% 136 66% 141 75% 144 80% 148 90% 155 95% 166 98% 170 99% 173 100% 173 Performance-Test #hust

20. Wie geht‘s genau?

21. MySQL Kann nicht viel dazu sagen Sind umgestiegen von einem eigenen DB-Server zu Amazon RDS weitestgehend in Standard-Installation Wordpress bei uns nun auf InnoDB rund 20% weniger CPU-Last auf dem DB-Server sonst kein merkbarer Unterschied Optimierungen

22. Nutzung von object-cache in eigenen Plugins Trennung von Datenbeschaffung und Ausgabe function get_gallery2($parent) { $result = wp_cache_get('gallery_'.$parent,''); if (false == $result) { $result = get_gallery($parent); wp_cache_add('gallery_'.$parent,$result,'',900); } return $result; } Optimierungen

23. Nutzung von Amazon S3 zum Bilder speichern Social Media Kit-Logik Wollten Wordpress-Logik erhalten, deswegen Verschiebung auf Serverlevel Nur Anpassung des Upload-Path in Wordpress /wp-content/uploads/<static-Domain>/request-timestamp/bild.jpg Script mit inotifywait-Schleife Regelmässig aufräumen! Optimierungen

24. Generelle Tipps Weniger HTTP-Requests (CSS, Bilder, JavaScript kombinieren) Expiration-Headers und E-Tags GZIP-Kompression Nicht so viele DNS-Abfragen Verkleinern von CSS, JavaScript, HTML und Bildern Keine Doppelten Scripts Ja, ich weiss, wir halten uns auch nicht immer dran ;-) Optimierungen

25. Fragen? Danke!