Ich bin 35 Jahre alt und seit 10 Jahren selbständiger Webentwickler. Mein Fokus liegt dabei auf der Erstellung, Beratung und Optimierung in den Bereichen High Performance, Usability und Sicherheit in den gängigsten Internetsprachen: PHP, HTML, Javascript und CSS.

Nach langem Arbeiten an einem Projekt fängt der ambitionierte Entwickler an, zu testen, wie sich seine dynamische Internetseite unter Last verhält. Da ja jeder von uns von Millionen Besuchern träumt, will man natürlich auch wissen, wie sich Millionen von Besucher anfühlen und ob unser „kleines Kunstwerk“ davon genau so begeistert wäre wie wir. Dynamische Webseiten sind toll, allerdings hat der gemeine Internetserver ein großes Problem damit. Die Erzeugung ist meist sehr aufwendig. Daten müssen aus Datenbanken geholt werden, Berechnungen wollen berechnet werden und Blogeinträge müssen wie Blogeinträge aussehen.

Seit Jahren hat sich eine simple Technik etabliert, die diese gequälten Webserver entlastet. Jeder fortgeschrittene Entwickler kennt und liebt sie, weil sie so schön einfach und universal einsetzbar ist: *trommelwirbel* Das Caching *tusch*. Da aber Caching an sich ein uralter Hut ist, will ich Euch zeigen, wie Ihr evtl. Eure Performance mit minimalen Änderungen mehr als verdoppeln könnt.

Am Anfang war der Benchmark

Nehmen wir als Beispiel eine ganz normale WordPress Installation mit dem üblichem Inhalt. WordPress ist umfangreich, es ist komfortabel, es ist leicht verständlich und es ist langsam. Da aber in den wenigstens Blogs sekündlich neue Beiträge und/oder Kommentare geschrieben werden, dafür aber häufige Aufrufe nicht unüblich sind, drängt sich uns hier das Caching geradezu auf. Natürlich gibt es einige gute Plugins dafür, die die verschiedenen Möglichkeiten des Cachings wunderbar abdecken. Aber um die soll es heute zur Abwechslung einmal nicht gehen. Ich will Euch ja nicht mit den „ollen Kamellen“ langweilen.

Um die Geschwindigkeit zu testen brauchen wir natürlich Hilfe in Form eines wunderbaren Programm Namens Apachebench. Dieses ist ein sehr einfach gehaltenes, aber mächtiges Kommandozeilenprogramm. Es macht im Prinzip nichts anderes als eine vorgegebene Seite immer wieder und wieder abzurufen. Dabei merkt es sich Start und Endzeitpunkt und berechnet daraus die Geschwindigkeit, mit der unsere Anfragen beantwortet wurden. Da wir immer noch mit dynamischen Daten arbeiten, starten wir einen ersten vorsichtigen Test. Wir rufen die index.php unserer WordPress Installation zunächst 1000 Mal (-n1000) auf mit je 4 parallelen Zugriffen (-c4). Ich habe 4 gewählt, weil mein Testsystem vier Prozessorkerne hat. So ist ständig jeder Prozessorkern beschäftigt. Die gesamten Daten des Testsystems findet Ihr am Ende des Artikels. Ich gebe bei der Ausgabe von Apachebench immer nur die wichtigen Daten an. Die gesamte Ausgabe ist natürlich umfangreicher.

ab -n1000 -c4 http://phpgangsta.x-blogs.org/

Server Software:        Cherokee
Server Hostname:        phpgangsta.x-blogs.org
Server Port:            80

Document Path:          /
Document Length:        18612 bytes

Concurrency Level:      4
Time taken for tests:   16.623 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      18990000 bytes
HTML transferred:       18612000 bytes
Requests per second:    60.16 [#/sec] (mean)
Time per request:       66.490 [ms] (mean)
Time per request:       16.623 [ms] (mean, across all concurrent requests)
Transfer rate:          1115.65 [Kbytes/sec] received

Was soll man da sagen? Glückwunsch, es ist langsam!

Machen wir es schneller

Wie es schon zu erwarten war, kommen wir mit unserem Standard WordPress nicht weit. Neben der lausigen Geschwindigkeit von 60 Zugriffen pro Sekunde waren während des gesamten Tests auch alle Prozessorkerne bis zum Anschlag ausgelastet. So macht also Bloggen für Millionen Leser keinen Spaß. Einfachste Lösungmöglichkeit – wir besorgen uns eines der o. g. Plugins, doch da lernen wir ja nichts draus, richtig? Wir wollen selber cachen und ausserdem können wir das bestimmt auch viel besser.

Als persistenten Speicher nehme ich APC. Dieses Zusatzmodul ist auf vielen PHP Webservern schon installiert, denn die Hauptaufgabe von APC ist es, PHP Code zu kompiliert und diesen im Arbeitsspeicher zu halten. So werden unsere PHP Scripte dramatisch beschleunigt. Alternativ funktionieren natürlich auch Memcache, alle Datenbanken oder einfache Dateien, in denen wir unsere Daten ablegen. Jede Variante hat seine Vor- und Nachteile. Memcache ist immer dann interessant, wenn man Daten auf mehrere Server verteilen muss, genau so wie Datenbanken, die aber überdimensioniert sind und einen hohen Overhead erzeugen. Dateien funktionieren auch ohne zusätzliche Installationen, sind aber recht langsam. APC ist von den genannten die schnellste Methode.

Da wir hier kein WordPress-Tutorial, sondern ein Performancetutorial machen, tun wir genau das, was man niemals tun sollte. Wir schreiben der Einfachheit halber in die Kerndateien von WordPress, in diesem Fall die index.php. Diese drängt sich geradezu auf, beschleunigt zu werden. Meine Modifizierung ist sehr einfach und stellt quasi ein Modell eines sehr sehr einfachen Caching dar. Keine Funktion, keine Klassen, Caching pur. Für die Praxis ist es damit natürlich nur eingeschränkt tauglich, denn es berücksichtigt ja in keinster Weise Änderungen durch neuen Beiträge oder Kommentare und unterscheidet auch nicht, ob ein Benutzer eingeloggt ist oder nicht. Das ganze System müsste um diese Abhängigkeiten erweitert werden. Trotzdem eignet es sich aber als Basis für Eure eigenen Experimente.

// CacheID
// Der Cache wird neu erstellt durch Änderung der vorstehenden Variable
$cacheid = 'cache' . md5($_SERVER['REQUEST_URI']);

// Sind Daten vorhanden?
if(apc_exists($cacheid) != false)
{
	// dann hole sie und zeige Sie auf der Seite und beende den Vorgang
	$output = apc_fetch($cacheid);
	echo $output;
	exit;
}

// Wir benötigen einen Ausgabepuffer
ob_start();

/** Loads the WordPress Environment and Template */
require('./wp-blog-header.php');

// Wir fangen die Ausgabe ab ...
$output = ob_get_contents();

// ... und vertrauen diese APC an
apc_store($cacheid, $output, 300);

Wiederholen wir den Test von oben. Die Performance sollte sich jetzt wesentlich verbessert haben. Die Daten werden einmal erzeugt und dann in den gemeinsamen Speicher von APC abgelegt. Weitere Aufrufe geben nur noch den Inhaltes des Caches wieder. Testen wir also noch einmal. Ab hier erhöhe ich die Anzahl der Abfragen (-n) auf 100.000, weil damit aussagekräftigere Werte entstehen.

ab -n100000 -c4 http://phpgangsta.x-blogs.org/

Concurrency Level:      4
Time taken for tests:   19.911 seconds
Complete requests:      100000
Requests per second:    5022.40 [#/sec] (mean)
Time per request:       0.796 [ms] (mean)
Time per request:       0.199 [ms] (mean, across all concurrent requests)

Okay, klarer Fall von Makro-Optimierung!

Machen wir es noch schneller

Bis hier hin dürften die meisten von uns schon einmal gekommen sein. Wir haben also die Geschwindigkeit unseres kleinen Blogs mit einfachsten Mitteln um den Faktor ~80 beschleunigt und könnten also Feierabend machen. Tun wir aber nicht, denn ein anderes großes Problem haben wir nämlich noch gar nicht bedacht. Eine Seite schnell zu generieren heißt nicht, dass sie auch schnell bei unserem Besucher ankommt. Dazu kommen noch mehr Faktoren. Eine der wichtigsten ist die Komprimierung des Textes vor der Ausgabe.

Wie man im ersten Test schon sah, ist unsere Startseite ungefähr 18 kb groß. Über GPRS oder unser gutes altes Kabelmodem wäre diese Seite satte 3 bis 4 Sekunden unterwegs. Das ist definitiv so lang, dass ein Benutzer genervt wegschalten könnte. Wenn wir Millionen Besucher haben möchten, dürfen wir aber auf dem Weg niemanden verlieren. Text-, bzw. html-Dateien sind gerade zu dafür erfunden worden, vor dem Versand komprimiert zu werden. Die Trafficersparnis beträgt meistens über 80%, da sich wiederholende Zeichen leicht zusammengepackt lassen. In PHP ist diese Funktion durch den ob_gzhandler auch sehr einfach umzusetzen. Also zurück zu unserer index.php und eine Zeile hinzufügen.

// Sind Daten vorhanden?
if(apc_exists($cacheid) != false)
{
	// Seiten vor der Ausgabe packen
	ob_start("ob_gzhandler");

	// dann hole sie und zeige Sie auf der Seite und beende den Vorgang
	$output = apc_fetch($cacheid);
	echo $output;
	exit;
}

Da Apachebench in der Standardkonfiguration dem Webserver nicht mitteilt, dass es auch mit der gepackten Version arbeiten kann, müssen wir unsere Befehlszeile etwas modifizieren. Mit dem Parameter -H können wir der abgefragten Internetseite zusätzliche Kopfdaten schicken und damit sagen, dass wir auch GZip sprechen und daher doch lieber das kleine Päckchen nehmen. Damit imitieren wir das Verhalten von richtigen Browsern. Diese sagen einer Internetseite mit jedem Aufruf, „Hallo, ich kann auch GZip“. Der ob_gzhandler erkennt dies und packt unsere Daten im Ausgabepuffer vor dem Versand. Die Größe der Datei sinkt – die Übertragung wird schneller. Doch was ist mit unserer Serverperformance?

ab -n 100000 -c 4 -H "Accept-Encoding: GZip" http://phpgangsta.x-blogs.org/

Document Length:        4844 bytes

Concurrency Level:      4
Time taken for tests:   41.272 seconds
Requests per second:    2422.94 [#/sec] (mean)
Time per request:       1.651 [ms] (mean)
Time per request:       0.413 [ms] (mean, across all concurrent requests)

Ein Testergebnis mit 8 Buchstaben: Resultat Verdammt! Positiv fällt uns natürlich sofort auf, dass die Seite auf ca. ein Viertel geschrumpft ist. Statt 3 bis 4 Sekunden würde ein Besucher mit kleiner Leitung nur noch weniger als 1 Sekunde warten. Eine wesentliche Verbesserung und kaum eine Chance, den Browser zu schliessen. Nur unsere wunderbare Performance hat sich dabei halbiert. Nichts mehr mit Millionen Besuchern, Frauen (oder Männern), Geld, Ruhm und noch mehr Frauen (oder Männern).

Die Reihenfolge macht’s

Preisfrage: Was würde passieren, wenn wir nicht die Ausgabe speichern und dann komprimieren, sondern erst komprimieren und dann speichern? An die Editoren! Zunächst einmal brauchen wir eine Funktion, die uns aus einer Textdatei eine GZip Datei macht. Mit der Funktion gzencode ist dies problemlos möglich. Unsere Datei muss dazu nur minimal geändert werden. Wir komprimieren die Ausgabe vor der Speicherung auf dem höchsten Faktor 9. Die Datei soll möglichst klein werden.

// und vertrauen diese APC an
apc_store($cacheid, gzencode($output, 9), 300);

Fehlt uns noch die Ausgabe. Diese bleibt an sich gleich, allerdings ersetzen wir unseren ob_gzhandler gegen den Content-Encoding header, den der Browser benötigt, um GZip Daten zu erkennen und entsprechend zu interpretieren. Ohne diese „Markierung“ würde er uns die Datei einfach im Fenster angezeigt werden, was bei komprimierten Dateien, sagen wir mal, schwierig zu lesen wäre. Wir wollen ja, dass unsere Millionen Leser auch wieder kommen. Denkt bitte auch daran die CacheID zu ändern oder 5 Minuten zu warten, sonst wird der alte Inhalt des Caches ausgegeben.

if(apc_exists($cacheid) != false)
{
	header('Content-Encoding: GZip');
	$output = apc_fetch($cacheid);
	echo $output;
	exit;
}
ob_start();

Alle Browser in freier Wildbahn unterstützen übrigens GZip-komprimierte Daten. Daher sollten auch standardmässig immer gepackte Daten ausgegeben werden. Für die wenigen Ausnahmen, bei denen dem nicht so ist, kann man folgenden Code verwenden. Dies erhöht zwar grundsätzlich die Serverauslastung, aber wie bereits erwähnt, dass ist die absolute Ausnahme.

if(!isset($_SERVER["HTTP_ACCEPT_ENCODING"]) || strpos($_SERVER["HTTP_ACCEPT_ENCODING"], 'gzip') === false)
{
	echo gzdecode($output);
	exit;
}

Unsere Daten werden nun komprimiert gespeichert und dann ohne weitere Bearbeitung, aber mit dem richtigen Kopfdaten an den Browser gereicht. Die Frage ist, wie verhält sich unser kleines Blog jetzt? Probieren wir es aus!

Concurrency Level:      4
Time taken for tests:   17.424 seconds
Complete requests:      100000
Requests per second:    5739.37 [#/sec] (mean)
Time per request:       0.697 [ms] (mean)
Time per request:       0.174 [ms] (mean, across all concurrent requests)

Concurrency Level:      10
Time taken for tests:   16.773 seconds
Complete requests:      100000
Requests per second:    5961.95 [#/sec] (mean)
Time per request:       1.677 [ms] (mean)
Time per request:       0.168 [ms] (mean, across all concurrent requests)

Concurrency Level:      100
Time taken for tests:   19.683 seconds
Complete requests:      100000
Requests per second:    5080.58 [#/sec] (mean)
Time per request:       19.683 [ms] (mean)
Time per request:       0.197 [ms] (mean, across all concurrent requests)

Concurrency Level:      1000
Time taken for tests:   24.064 seconds
Complete requests:      100000
Requests per second:    4155.55 [#/sec] (mean)
Time per request:       240.642 [ms] (mean)
Time per request:       0.241 [ms] (mean, across all concurrent requests)

Concurrency Level:      2000
Time taken for tests:   33.335 seconds
Complete requests:      100000
Requests per second:    2999.87 [#/sec] (mean)
Time per request:       666.696 [ms] (mean)
Time per request:       0.333 [ms] (mean, across all concurrent requests)

Wie man sieht, liegen die Anfragen pro Sekunde bei 2000 (!) parallelen Abfragen immer noch 20% über denen unserer ob_gzhandler Version. Im Normalbereich ca. 10 bis 20 % über denen ohne Komprimierung. Der Prozessor ist dabei übrigens noch weit weg von Totalauslastung. Dieses Verhalten ist auch vollkommen logisch. Kleineren Daten werden wesentlich schneller abgearbeitet. Sie werden schneller aus dem shared memory gelesen und verstopfen nicht unsere Netzwerkverbindung. Auch bei unrealistisch vielen parallelen Anfragen bricht die Performance messbar, aber nicht spürbar ein.

Fazit

Caching ist eine lohnenswerte Technik. Caching von komprimierten Daten ist eine noch viel lohnenswertere(re) Technik, vor allem im High Performancebereich oder auf Webservern, die eigentlich unterdimensioniert sind. Wenn Ihr diese Möglichkeit habt, nutzt sie und baut es in Euer bestehendes System ein.

Testsystem

Hardware:
- Intel Quad Core i5 CPU 750  @ 2.67GHz
- 6 GB Ram
- Software Raid 1

Software:
- Debian 6.0.3
- Cherokee Web Server 1.2.101
- PHP 5.3.8 (php-fpm)
- APC 3.1.9

Ähnliche Artikel:

1. PHP in_array() die Performance-Bremse

Das neue Plugin Smart Archives Reloaded erstellt eine coole Archiv-Seite, auf der alle Artikel nach Jahren und Monaten sortiert aufgelistet sind, und man so schnell die Artikel eines bestimmten Zeitraums finden kann. Es gibt vier Einstellungsmöglichkeiten bei der Präsentation der Liste, ich habe die Javascript-Variante genommen damit die Liste nicht so ewig lang wird, und sie ist auch die coolste von allen

Das Plugin Subscribe To Comments habe ich ausgetauscht gegen das neuere Subscribe To Comments Reloaded. Endlich ist es möglich ein Double-Opt-In Verfahren zu aktivieren, und auch das Management-Werkzeug im Admin-Bereich ist viel cooler, man kann viel mehr Dinge einstellen, Texte ändern und auch die Abonnements administrieren. Für die Benutzer gibt es nun die Möglichkeit sich benachrichtigen zu lassen ohne einen Kommentar hinterlassen zu müssen, finde ich auch super. Des weiteren ist die Administrierbarkeit des Benutzers schöner geworden.

Das Plugin 2 Click Social Media Buttons ist in Version 0.12 erschienen, und nun ist auch Flattr durch den 2-Klick-Schutz abgesichert, es sieht also einheitlich aus. Ich hadere noch etwas mit mir ob ich rechts in der Leiste den Flattr-Link rausnehmen sollte oder nicht, eigentlich müßte ich daraus konsequenterweise auch eine 2-Klick-Variante machen, aber mir fehlt die Lust

Da mich einige bei Google Plus nicht gefunden haben habe ich den Link in die rechte Leiste gepackt.

Da die WordPress-Plugin-Datenbank so riesig ist kann man unmöglich alle kennen, falls ihr gute Plugins kennt, selbst einsetzt oder mir empfehlt, immer her mit den Infos!

Ähnliche Artikel:

1. Blog URL Struktur geändert

http://www.phpgangsta.de/630

verfügbar waren. Das war primär dafür gemacht, dass ich diese kurzen URLs in Twitter nutzen kann, da ich Short-URL-Dienste hasse (man weiß nie was dahinter versteckt ist).

Nun habe ich die Struktur umgestellt auf /%postname% , sodass der selbe Artikel nun standardmäßig so verlinkt ist:

http://www.phpgangsta.de/taugt-zend_queue-etwas

ABER: Da ich die kurzen URLs nicht verlieren wollte (und die Links in Google/Twitter weiterhin funktionieren sollen) habe ich meine .htaccess noch angepasst, sodass ich nun beide Formate nutzen kann. In Twitter kann ich also weiterhin meine geliebten Kurz-URLs nutzen, im Blog wird allerdings der Postname genutzt. Meine .htaccess sieht nun so aus:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteRule ^([0-9]+)$ /?p=$1 [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Falls also in der URL nur Zahlen vorkommen, sende ich einen “301 Permanent Redirect” auf die URL ?p=<id> , diese URL wandelt WordPress dann nochmals um und leitet auf die URL mit dem Postnamen um. In Google sollten nun also bald die Artikel nur noch mit dem Postnamen erscheinen und die ID-URLs bald verschwinden. Ich bin gespannt, ob das so klappt.

Um nur einen 301 Redirect zu nutzen hätte ich ein kleines Script schreiben müssen, welches aus einer ID die Postname-URL herausfindet (Datenbank?) und dann redirected. Ob das einfach ist und vor allem bei zukünftigen WordPress-Updates noch funktioniert würde ich bezweifeln, und soweit ich weiß sind 2 Redirects kein Problem, oder hat jemand andere Informationen?

Jedenfalls funktioniert es nun so wie ich möchte, und Google werde ich in den nächsten Tagen mal beobachten.

Keine ähnlichen Artikel.

Ich verlasse mich da lieber auf die kleinen Tipps und Tricks, die man so liest, und die auch Sinn machen. Auch Google gibt Webmastern Tipps, um ihre Seiten gut indizierbar zu machen, und so einen guten Pagerank zu erhalten. Interessante Hintergrund-Informationen gibt es zB bei Google’s Webmaster Tools.

Ich möchte hier keine riesen Sammlung eröffnen, sondern nur das WordPress-Plugin “All in One SEO Pack” vorstellen. Dieses Plugin hilft dabei, auf jeder Seite unterschiedliche und vor allem passende Keywords und Descriptions setzen zu lassen (automatisch extrahiert aus dem Artikel-Text). Auch den Titel kann man auf jeder Seite anpassen lassen. Des weiteren unterstützt es die Möglichkeit, doppelte Inhalte unter verschiedenen URLs zu vermeiden mit dem “canonical”-Tag.

Damit sind die wichtigsten Dinge erstmal abgedeckt. Alle anderen Meta-Tags sind heutzutage relativ unwichtig geworden, jedenfalls liest man das oft.

Schaut es euch selbst an, ich finde es sehr hilfreich, und werde es auch vorerst dabei belassen.

So sehen die Optionen aus:

Keine ähnlichen Artikel.

Jetzt am Wochenende habe ich einen Podcast vom Chaos Computer Club: Chaosradio Folge 147 gehört, der mich nun zu Experimenten angespornt hat.

Ein Account ist schnell erstellt, eine Statusnachricht geschrieben, und ein paar Leuten folge ich auch bereits.

Heute habe ich mir das WordPress-Plugin TwitterSuite installiert, mit dem ich hoffe, automatische Tweets zu senden bei neuen Beiträgen, Last Tweets anzuzeigen und einigem mehr. Dieser Post ist auch dazu da, diese Funktionalität mal zu testen. Ich hoffe, dass es funktioniert

EDIT: Hmm, das ging wohl voll in die Hose. Habe wohl curl nicht installiert auf dem Server. *verschnauf* Hätte ja auch so einfach sein können.

Da ich jetzt weder Zeit noch Lust habe, probiere ich nun den twitter_updater.

EDIT2: Scheint zu funktionieren! *jubel*

Keine ähnlichen Artikel.

Danke dafür!

Keine ähnlichen Artikel.

• WP-Cumulus
• WP-Memory-Usage
• WP-ServerInfo
• SyntaxHighlighter Evolved

installiert. Gibt es sonst noch welche, die ich unbedingt kennen muss und nutzen sollte?

Was tut ihr gegen Spam in den Comments? Akismet wird ja bereits mitgeliefert, man muss es nur noch aktivieren. Welches Anti-Spam-Plugin bevorzugt ihr?

Ich habe ausserdem noch Probleme mit dem Einrücken des php Codes, irgendwie klappt das noch nicht so wie ich möchte. Hat jemand Erfahrung damit und einen Tip?

Und hier noch ein kurzer php-Code-Test:

<?
echo "bla";
class MyFirstClass {
public $name = null;
public function myTest() {
return "just a test";
}
}
?>

Test Ende.

Keine ähnlichen Artikel.