WordPress: W3 Total Cache gegen Varnish

In meiner kleinen Reihe “WordPress-Performancetuning” möchte ich nun noch das Plugin W3 Total Cache als Alternative für Varnish vorstellen. Schließlich hat nicht jeder Zugriff auf den Webserver und kann Zusatzsoftware installieren.

Die Feature-Liste von W3 Total Cache liest sich wie folgt:

  • Compatible with shared hosting, virtual private servers and dedicated servers / clusters
  • Transparent content delivery network (CDN) integration with Media Library, theme files and WordPress itself
  • Caching of (minified and compressed) pages and posts in memory or on disk
  • Caching of (minified and compressed) CSS and JavaScript in memory, on disk or on CDN
  • Caching of RSS (site, categories, tags, comments) feeds in memory or on disk
  • Caching of search results pages (i.e. URIs with query string variables) in memory or on disk
  • Caching of database objects in memory
  • Minification of posts and pages and RSS feeds
  • Minification (combine and remove comments / white space) of inline, embedded or 3rd party JavaScript (with automated updates)
  • Minification (combine and remove comments / white space) of inline, embedded or 3rd party CSS (with automated updates)
  • Browser caching of CSS, JavaScript and HTML using future expire headers and entity tags (ETag)
  • JavaScript grouping by template (home page, post page etc) with embed location management
  • Non-blocking JavaScript embedding
  • Import post attachments directly into the Media Library (and CDN)

Als “Storage” kommen entweder Memcache oder die Festplatte zum Einsatz.

Ich hab die beiden gerade nochmal gegeneinander antreten lassen:

Varnish, Apache, WordPress

Server Software: Apache/2.2.9
Server Hostname: nodomain.cc
Server Port: 80

Document Path: /
Document Length: 24190 bytes

Concurrency Level: 100
Time taken for tests: 17.603 seconds
Complete requests: 500
Failed requests: 0
Write errors: 0
Total transferred: 12290490 bytes
HTML transferred: 12095000 bytes
Requests per second: 28.40 [#/sec] (mean)
Time per request: 3520.601 [ms] (mean)
Time per request: 35.206 [ms] (mean, across all concurrent requests)
Transfer rate: 681.84 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 30 34 3.4 34 64
Processing: 157 3117 816.3 3446 3514
Waiting: 36 1662 995.9 1668 3392
Total: 191 3151 816.1 3480 3548

Percentage of the requests served within a certain time (ms)
50% 3480
66% 3500
75% 3511
80% 3515
90% 3527
95% 3537
98% 3541
99% 3544
100% 3548 (longest request)

Apache, WordPress mit W3 Total Cache Plugin

Beim W3 Total Cache Plugin ist folgendes aktiviert: Page Caching, Minifying, Database Caching, CDN

Server Software: Apache/2.2.9
Server Hostname: nodomain.cc
Server Port: 80

Document Path: /
Document Length: 22109 bytes

Concurrency Level: 100
Time taken for tests: 17.986 seconds
Complete requests: 500
Failed requests: 0
Write errors: 0
Total transferred: 11281716 bytes
HTML transferred: 11054500 bytes
Requests per second: 27.80 [#/sec] (mean)
Time per request: 3597.206 [ms] (mean)
Time per request: 35.972 [ms] (mean, across all concurrent requests)
Transfer rate: 612.55 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 29 34 3.5 33 63
Processing: 582 3148 694.0 3424 3532
Waiting: 454 2704 610.5 2836 3421
Total: 612 3182 693.9 3457 3564

Percentage of the requests served within a certain time (ms)
50% 3457
66% 3480
75% 3496
80% 3501
90% 3527
95% 3550
98% 3558
99% 3560
100% 3564 (longest request)

Wie man sieht, ist die reine PHP-Lösung W3 Total Cache ebenfalls in der Lage, die Performance von WordPress stark zu verbessern. Vielleicht ist dies ja eine Möglichkeit für manche meiner Leser, die keine eigene Software auf ihrem Shared-Hosting-Account installieren können.

Außerdem hat die Nutzung von W3 Total Cache den Vorteil, dass das Plugin selbstständig erkennt, wann ein Objekt im Cache ungültig wird (z.B. nach dem Editieren einer Seite) und dieses dann löscht.

Leave a Reply

Your email address will not be published. Required fields are marked *

9 comments

  1. Your benchmark looks flawed. You are probably testing the client, not the server side. But for most people this setup is “fast enough”, I guess.

    1. I don’t think it’s flawed. I tested the server from my computer which is on a 100mbit cable line. So this should be alright 😉
      Or did I get you wrong?

      1. If you look at your numbers you will see that there is hardly any difference between the two. They are probably both so fast that apache-bench will be “maxed out”. I know, because while we where stress testing Varnish we needed approximately 10 times as many servers to generate the load as we needed servers to handle to load. 🙂

        This, is mostly because noone has written a _really_ fast tool for stress testing web servers/proxies.

        Sorry for writing in English, but my German ist ganz gebrochen.

        1. Oh I understand. I’ll check that and start two or more instances at the same time, from more than one host.
          This is good information, thanks!

          (btw: I sometimes have thought about blogging only in English but I never did it because of personal lazyness ;-))

        2. I made another test with puzich.com (see comment below) and there we had 12 Requests/s with Apache and W3 Total Cache compared to about 44 Requests/s with Varnish, Apache and W3 Total Cache. That blog is running on a real server.
          The only thing that makes me wonder is that there are only 12 r/s with Apache.

          But it shows how amazingly Varnish can speed up WordPress – if you can deal with the drawbacks.

  2. Sehe ich das richtig, dass dein Blog mit Varnishd nicht wesentlich schneller ist, als mit dem W3C Cache?

    Und läuft bei dir gerade noch varnishd? Wie bekommst du es mit deiner Einstellung für varnishd aus dem vorherigen Artikel hin, wo doch keine Cookies zugelassen werden, dass meine Kommentardaten wie Name, eMail und Webadresse, aus den Cookies doch automatisch ausgefüllt sind?

    1. Auf meiner Kiste (VPS) ist es in der Tat so, dass Varnish nicht schneller ist. Wie das auf einer richtigen Maschine aussieht, kann ich leider momentan nicht testen. Ich vermute, dass der VPS netzwerkmäßig ans Limit kommt. Ich hatte nämlich noch Tests mit höherer Concurrency gemacht und habe entsprechende Socketfehler erhalten.

      Außerdem ist es richtig, dass Varnish momentan aus ist und W3 Total Cache aktiv ist. Deswegen funktioniert auch die Sache mit den Cookies wieder.

      Ich muss mal sehen, dass ich mir auf einem richtigen Rechner eine Testumgebung aufbaue 🙂

  3. Die Sache mit vps.net kann ich vielleicht aufklaeren.

    Normalerweise ist bei den vps.net-Maschinen ein fail2ban drauf, d.h. wenn du mit zu vielen Requests pro Sekunde kommst, wirst du direkt geblockt. Darauf muss man achten und ggf. mit mehr Maschinen gleichzeitig testen, z.B. per Aufruf durch “dsh”…