SQLite <-> fastCGI/modPython peristente Variablen...

[jens]

Ich hab ein kleines "Download"-WebApp geschrieben: http://pylucid.python-hosting.com/brows ... ts/PyDown/

Ich möchte dort eine Bandbreitenbeschränkung einbauen. Grundsätzlich kann ich die aktuelle Download-Geschwindigkeit einfach drosseln:

Code: Alles auswählen

        def send_data(buffer):
            while 1:
                data = buffer.read(2048)
                if not data:
                    return
                yield data
                time.sleep(0.1)

        self.request.send_response(send_data(buffer))

Durch die kombination der Werte bei buffer.read() und time.sleep() wird die Download-Geschwindigkeit auf ein max. Wert begrenzt. (In dem Fall max 20KB/sec)

Nun kann ich also pro request die Geschwindigkeit begrenzen, ich möchte aber die Over-All-Geschwindigkeit kontrollieren.

Das kann ich erst, wenn ich bei jedem Download weiß, wieviel Downloads gerade gleichzeitig laufen...

Also theoretisch würde es reichen eine Variable hoch (wenn Download startet) und runter (wenn beendet) zu zählen... Nur, wie mach ich das?

Eine Variante, die mir spontan einfällt: in einem Verzeichnis, pro Download eine Datei erstellen und nach dem Download wieder löschen. Durch die anzahl der Dateien weiß ich, wieviel Downloads gerade gleichzeitig laufen... Aber das ist sicher nur eine frickel-cgi-only-Lösungsansatz

Nun könnte vielleicht SQLite nehmen. Nur was passiert bei gleichzeitigem Zugriff auf die Daten? Normalerweise ist eine DB genau dafür gedacht, oder?
Allerdings müßte es mit fastCGI/modPython doch ganz einfach gehen, ohne DB, oder???

[henning]

Dein Code baut ja hoffentlich auf WSGI auf, daher wäre es wohl ratsam, die speziellen features von mod_python/fast_cgi & co gegenüber cgi nicht direkt auszunutzen.
Die Beste Möglichkeit dir mir einfällt, wäre auch, die Datenbankanbindung zu nutzen, erst recht, wenn du eh schon eine hast.
Und ja grade für "konkurrierenden" Zugriff auf die selben Daten sind Datenbank gebaut worden ,-)

Eine andere Möglichkeit, die mir durch den Kopf schwirrt, ist die ganze download-geschichte in ein einzelnes python-file auszulagern, welches irgendwie nicht als child von deinem wemserver sondern "standalone" läuft und threads/forks für jeden download laufen hat.

Das könnte dann Klasse die Bandbreite regeln etc...

Allerdings stehst du vor dem Problem, dass das ding unabhängig vom request durchlaufen/gestartet werden soll und vor allem rausfinden können muss, ob nicht ne Instanz davon schon läuft und wenn ja muss man der Anweisungen geben.

Meine praktischen Erfahrungen mit multi-threading, forken, pipes etc... halten sich in Grenzen, aber so wie ich das sehe müsste sich das halbwegs portabel realisieren lassen.

Letztere Lösung wäre wahrscheinlich Leistungsfähiger (z.B. genauer, was den traffic angeht) sowie performanter, aber die Lösung mit der DB-Anbindung ist wahrscheinlich wesentlich schneller zu implementieren.

[jens]

Zur Info: Das Ding ist WSGI konform und nutztz colubrid, jinja und optional den fastCGI-Server von flup...

Ich denke dann werde ich es evtl. mal mit SQLite Probieren...