Zum Beispiel wenn ich mit Flup spiele und statt des threaded Servers einen forked Server nehmen will. Und feststelle, das der dann aber die Funktion socketpair benötigt. Die aber dummerweise nur ab Python 2.4 verfügbar ist, welches zwar auf Debian Sarge da ist, aber dafür gibts in der Debian Sarge für Python 2.4 keinen Psycopg - welcher wiederum Voraussetzung für Django und PostgreSQL ist, weshalb ich mich überhaupt ja nur mit FastCGI beschäftige. PsycoPG selber installieren macht keinen Spaß, da man dafür nicht nur die PostgreSQL Header braucht, die normal installiert werden, sondern auch ein paar interne Header - also im Prinzip einen Build-Tree. Und dann braucht man noch die egenix-mx-base Header, die man nur für Python 2.3 kriegt, also müsste man das auch selber installieren. Backports aus der nächsten Debian geht auch nicht, da die gerade auf PostgreSQL 8.0 umbauen und Sarge ja noch 7.4 benutzt und ich nicht gleich das ganze System upgraden wollte. Und so dreht man sich im Kreis und kommt sich leicht verarscht vor vor lauter Abhängigkeiten und Versionskonflikten.
Und was macht man also als Lösung, weil der threaded Server dummerweise nur Segfaults im Psycopg produziert? Man nimmt den threaded Server, verbietet ihm das threaden und startet ihn über den spawn-fcgi vom lighttpd, oder direkt vom lighttpd. Was aber irgendwie auch wieder dämlich ist, da dann immer pro FCGI-Server 3 Threads rumgammeln, von denen 2 nur in der Prozessliste stehen und nix zu tun haben. Und das alles nur weil mod python2 (was für Django gebraucht wird) Apache2 voraussetzt, der wiederum mod perl2 voraussetzt, welches inkompatibel zum alten mod perl ist, weshalb bei mir eine ganze Reihe von meinen Sites nicht mehr laufen würden, würde ich auf Apache2 umstellen. Was ich eh nicht will, weil Apache2 mit mod python arschlangsam ist. Und schon wieder verarscht worden. Ich hätte mir echt einen sinnvolleren Beruf suchen sollen.
Wer nix kapiert hat: macht nix, ist Technik, ist nicht wichtig, wollte das einfach nur mal gesagt haben.
Higher-Order Perl ist ein Buch (zur Zeit Papier, aber soll demnächst frei im Netz lesbar sein) das sich mit higher order functions und Perl beschäftigt - könnte ganz interessant sein, Perl bietet da eine ganze Menge Features versteckt unter all den geschweiften Klammern und anderen Sonderzeichen ...
Diese Dokumentation ist für einen grösseren Kreis als nur .de gedacht, daher das ganze in Neuwestfälisch Englisch. Sorry. Update: I maintain the actually descriptions now in my trac system. See the FCGI+lighty description for Django. There are different ways to run Django on your machine. One way is only for development: use the django-admin.py runserver command as documented in the tutorial. The builtin server isn't good for production use, though. The other option is running it with mod_python. This is currently the preferred method to run Django. This posting is here to document a third way: running Django behind lighttpd with FCGI.
First you need to install the needed packages. Fetch them from their respective download address and install them or use preinstalled packages if your system provides those. You will need the following stuff:
- [Django][2] selbst - derzeit aus dem SVN. Folgen Sie den Setup-Anweisungen oder verwenden Sie
python setup.py install.
- [Flup][3] - ein Paket mit verschiedenen Möglichkeiten, WSGI-Anwendungen auszuführen. Ich verwende den threaded WSGIServer in dieser Dokumentation.
- [lighttpd][4] selbstverständlich. Sie benötigen mindestens die FastCGI-, die Rewrite- und die Accesslog-Module, diese sind in der Regel mit dem System kompiliert.
Nach der Installation von ligthttpd müssen Sie eine lighttpd-Konfigurationsdatei erstellen. Die hier angegebene Konfigurationsdatei ist an meine eigenen Pfade angepasst - Sie müssen diese an Ihre eigene Situation anpassen. Diese Konfigurationsdatei aktiviert einen Server auf Port 8000 auf localhost - genau wie der runserver-Befehl dies tun würde. Aber dieser Server ist ein Server für die Produktion mit mehreren FCGI-Prozessen und einer sehr schnellen Medienauslieferung.
# lighttpd-Konfigurationsdatei
#
############ Optionen, die Sie wirklich beachten müssen ####################
server.modules = ( "mod_rewrite", "mod_fastcgi", "mod_accesslog" )
server.document-root = "/home/gb/public_html/"
server.indexfiles = ( "index.html", "index.htm", "default.htm" )
diese Einstellungen binden den Server an dieselbe IP und denselben Port wie runserver
server.errorlog = "/home/gb/log/lighttpd-error.log"
accesslog.filename = "/home/gb/log/lighttpd-access.log"
fastcgi.server = (
"/myproject-admin.fcgi" => (
"admin" => (
"socket" => "/tmp/myproject-admin.socket",
"bin-path" => "/home/gb/public_html/myproject-admin.fcgi",
"min-procs" => 1,
"max-procs" => 1
)
),
"/myproject.fcgi" => (
"polls" => (
"socket" => "/tmp/myproject.socket",
"bin-path" => "/home/gb/public_html/myproject.fcgi"
)
)
)
url.rewrite = (
"^(/admin/.*)$" => "/myproject-admin.fcgi$1",
"^(/polls/.*)$" => "/myproject.fcgi$1"
)
Diese Konfigurationsdatei startet nur einen FCGI-Handler für Ihre Admin-Angelegenheiten und die Standardanzahl von Handlern (jeder davon mehrthreadig!) für Ihre eigene Website. Sie können diese Einstellungen mit den üblichen ligthttpd FCGI-Einstellungen feinabstimmen, sogar externe FCGI-Erzeugung und Auslagerung von FCGI-Prozessen auf einen verteilten FCGI-Cluster nutzen! Admin-Medien-Dateien müssen in Ihr lighttpd-Dokumentenverzeichnis.
Die Konfiguration funktioniert, indem alle Standard-URLs so übersetzt werden, dass sie vom FCGI-Skript für jede Einstellungsdatei behandelt werden - um weitere Anwendungen zum System hinzuzufügen, würden Sie nur die Umschreiberegel für die /polls/-Zeile duplizieren und diese in choices oder was auch immer Ihr Modul heißt ändern. Der nächste Schritt wäre die Erstellung der .fcgi-Skripte. Hier sind die beiden, die ich verwende:
#!/bin/sh
# dies ist myproject.fcgi - legen Sie es in Ihr Docroot
export DJANGOSETTINGSMODULE=myprojects.settings.main
/home/gb/bin/django-fcgi.py
#!/bin/sh
# dies ist myproject-admin.fcgi - legen Sie es in Ihr Docroot
export DJANGOSETTINGSMODULE=myprojects.settings.admin
/home/gb/bin/django-fcgi.py
Diese beiden Dateien nutzen nur ein django-fcgi.py-Skript. Dies ist nicht Teil der Django-Distribution (noch nicht - vielleicht werden sie es einbeziehen) und der Quellcode ist hier gegeben:
#!/usr/bin/python2.3
def main():
from flup.server.fcgi import WSGIServer
from django.core.handlers.wsgi import WSGIHandler
WSGIServer(WSGIHandler()).run()
if name == 'main':
main()
Wie Sie sehen, ist es eher einfach. Es verwendet den threaded WSGIServer aus dem fcgi-Modul, aber Sie könnten genauso leicht den geforkten Server verwenden - aber da lighttpd bereits Preforking durchführt, denke ich, dass es nicht viel Sinn hat, auf der FCGI-Ebene zu forken. Dieses Skript sollte sich irgendwo in Ihrem Pfad befinden oder einfach mit vollständig qualifiziertem Pfad wie ich es tue referenziert werden. Jetzt haben Sie alle Teile zusammen. Ich habe meine lighttpd-Konfiguration in /home/gb/etc/lighttpd.conf, die .fcgi-Skripte in /home/gb/public_html und das django-fcgi.py in /home/gb/bin. Dann kann ich das ganze mit /usr/local/sbin/lighttpd -f etc/lighttpd.conf starten. Dies startet den Server, preforkt alle FCGI-Handler und trennt sich vom tty, um ein richtiger Daemon zu werden. Das Schöne daran: Dies wird nicht unter einem speziellen Systemkonto, sondern unter Ihrem normalen Benutzerkonto ausgeführt, sodass Ihre eigenen Dateibeschränkungen gelten. lighttpd+FCGI ist recht leistungsfähig und sollte Ihnen eine sehr schöne und sehr schnelle Option zum Ausführen von Django-Anwendungen bieten. Probleme:
Unter hoher Last stürzen einige FCGI-Prozesse ab. Ich habe zunächst die fcgi-Bibliothek verdächtigt, aber nach etwas Herumspielen (Core-Debugging) stellte sich heraus, dass es tatsächlich der psycopg auf meinem System ist, der abstürzt. Sie könnten also mehr Glück haben (es sei denn, Sie laufen auch Debian Sarge)
Die Leistung hinter einem Front-Apache ist nicht das, was ich erwartet hätte. Ein lighttpd mit Front-Apache und 5 Backend-FCGI-Prozessen erreicht nur 36 Anfragen pro Sekunde auf meinem Rechner, während django-admin.py runserver 45 Anfragen pro Sekunde erreicht! (immer noch schneller als mod_python über apache2: nur 27 Anfragen pro Sekunde) Updates:
Die Trennung der beiden FCGI-Skripte funktionierte nicht richtig. Jetzt passe ich nicht nur auf die .fcgi-Erweiterung, sondern auf den Skriptnamen an, so dass /admin/ wirklich das myproject-admin.fcgi verwendet und /polls/ wirklich das myproject.fcgi verwendet.
Ich habe [ein anderes Dokument online][6], das mehr Details zur Lastverteilung enthält