Meine Bemühungen, den Ressourcenbedarf meiner Websites im Griff zu behalten, waren bisher nur bedingt von Erfolg gekrönt: Auch mit optimierten Datenbankanfragen und Djangos Caching-Modul zeigt mir Virtuozzo in schöner Regelmäßigkeit, dass ich an meine Grenzen stoße respektive die black zone in Bezug auf den Parameter othersockbuf betrete.
In dieser dramatischen Lage erinnere ich mich an das Apache-Modul mod_wsgi, das vielerorts für seinen niedrigen Speicherbedarf gerühmt (und von den Django-Entwicklern empfohlen) wird. Im Gegensatz zu mod_python wird mod_wsgi von einem einzigen Menschen gepflegt, der darüber hinaus den Ehrgeiz zu haben scheint, jede Anfrage in jedem Forum persönlich zu beantworten und jeden Artikel selbst zu kommentieren. Sehr sympathisch.
Auch die Installation und Konfiguration von mod_wsgi ist erfreulich spannungsarm – wenn man davon absieht, dass unter CentOS der Parameter WSGISocketPrefix verwendet werden muss, um einen Socket erzeugen zu können, und mod_wsgi sich im empfohlenen daemon mode nicht mit mod_python verträgt.
Nach der Umstellung, dem Wechsel vom Prefork zum Worker MPM (wobei man die Parameter MaxClients und ThreadsPerChild sehr genau im Blick behalten muss), einigen kleineren Optimierungen in httpd-vhosts.conf –
WSGIDaemonProcess djangoproject user=nobody group=nobody threads=10 maximum-requests=3000 deadlock-timeout=30 inactivity-timeout=100 stack-size=524288
– gerate ich immerhin nur noch in die yellow zone für den Parameter numproc, weil jeder Apache-Prozess für jede Django-Applikation bis zu 10 Threads erzeugen darf. Lediglich der Ansturm mehrerer Suchmaschinenroboter zu sehr unchristlichen Zeiten (3.30 Uhr!) bringt meinen Server weiterhin an den Rand seiner Kräfte.
Damit kann ich leben. Ein Hoch auf mod_wsgi!