Nachdem ich das Thema Webserver-Optimierung client- und serverseitig bereits abgeschlossen hatte, stieß ich vor einigen Tagen auf eine etwas ältere Liste von Hinweisen und eine damit verlinkte, noch ältere Liste von Jacob Kaplan-Moss himself. Beide Listen haben eine Gemeinsamkeit mit der offiziellen Django-Dokumentation:
Django doesn't serve media files itself; it leaves that job to whichever Web server you choose. We recommend using a separate Web server – i.e., one that's not also running Django – for serving media.
Obwohl mein Server für fast alle Seiten nur noch eine statische (CSS-)Datei ausliefern muss, die auch noch komprimiert und minimiert ist, komme ich ins Grübeln.
Die schlechte Idee, Apache als Django-Server und als Reverse Proxy für lighttpd einzusetzen, hatte schon jemand ausprobiert und verworfen. Zum Glück hatte er auch einen besseren Vorschlag: nginx als Media-Server und Reverse Proxy, Apache als Django-Server im Hintergrund.
Für die Installation von nginx unter Mac OS X findet sich schnell eine Anleitung, die allerdings um die Option --with-http_gzip_static_module ergänzt werden muss. Meinem CentOS-Server verabreiche ich via yum zunächst eine nginx-Version aus dem EPEL, bis sich herausstellt, dass nginx 0.6.x die Direktive proxy_cache nicht versteht. Folglich muss ich nginx 0.7.67 von Hand kompilieren. Die Bühne ist bereitet. Was wird gespielt?
Eine neue Fassung des Stücks Speed, Speed, Speed:
gzip -9 file.tex), so dass nginx bei der Auslieferung keine zusätzliche Arbeit hat.gzip_proxied any; ersetzt Djangos GZipMiddleware) und anschließend für 24 Stunden im Dateisystem abgelegt (proxy_cache_valid 1d; ersetzt das datenbankbasierte @cache_page für einzelne Views).ExpiresByType text/html "access plus 1 day") sowie die statischen Dateien (NginxHttpHeadersModule: expires 7d;) ruhig ein wenig im eigenen Cache aufbewahren können.Lediglich bei Formularen muss ich einen kleinen Kompromiss eingehen: Djangos Cross Site Request Forgery Protection verträgt sich nicht mit einem externen Cache.
Das Ergebnis ist ausgesprochen befriedigend: Laut Apache Benchmark wird eine umfangreiche Seite in 3,631 Millisekunden ausgeliefert, und PageSpeed gibt mir 99 von 100 Punkten (wenn ich die langsamen Google-Anzeigen deaktiviere). Dabei wirkt der Server sogar noch ganz entspannt.
Wenn man übrigens vergisst, die automatische Aktualisierung von nginx durch yum auszuschließen –
# /etc/yum.conf [main] ... exclude=nginx*
– dann ist das Ergebnis von yum update nicht so erfreulich wie sonst.