Wordpress on steroidsWordcamp Switzerland

Philip HetjensBlogwerk AG

7. Mai 2011

Übersicht

- Was kann man machen

- Was bringt‘s

- Wie geht’s genau

Was kann man machen?

Anatomie eines Wordpress-Requests I

DB

Internet

Client

PHP-Dateien

PHPWebserv

er

Anatomie eines Wordpress-Requests II

DB

Internet

Client

PHP-Dateien

PHPWebserv

er

Opcode-

Cache

Anatomie eines Wordpress-Requests III

DB

Internet

Client

PHP-Dateien

PHPWebserv

er

Object-Cache

Opcode-

Cache

Anatomie eines Wordpress-Requests III

DB

Internet

Client

PHP-Dateien

PHPWebserv

erHTML-Cache

Object-Cache

Opcode-

Cache

Was bringt‘s?

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

- Ubuntu Lucid 10.04 (64 Bit, alle Patches installiert)

- Lighttpd 1.4.x + PHP 5.3.x

- Separater Datenbankserver (gleicher Instanztyp)

Performance-Tests

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

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

eAcceleratorPerformance-Test

DB

Internet

Client

PHP-Dateien

PHPWebserv

erHTML-Cache

Object-Cache

Opcode-

Cache

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

MySQL/memcachedPerformance-Test

DB

Internet

Client

PHP-Dateien

PHPWebserv

erHTML-Cache

Object-Cache

Opcode-

Cache

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 object cache <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

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

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

WP-Super-CachePerformance-Test

DB

Internet

Client

PHP-Dateien

PHPWebserv

erHTML-Cache

Object-Cache

Opcode-

Cache

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

Wie geht‘s genau?

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

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

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

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

Fragen? Danke!