Ein guter Multithread-Python-Webserver?

Question

Ich suche nach einem Python-Webserver, der Multithread ist statt Multi-Prozess (wie im Falle von mod_python für Apache). Ich möchte, dass es Multithread ist, weil ich einen im Speicherobjekt-Cache haben möchte, der von verschiedenen http-Threads verwendet wird. Mein Webserver macht eine Menge teures Zeug und berechnet einige große Arrays, die im Speicher zwischengespeichert werden müssen, damit sie später erneut berechnet werden können. Dies ist in einer Webserverumgebung mit mehreren Prozessen nicht möglich. Das Speichern dieser Informationen in Memcache ist auch keine gute Idee, da die Arrays groß sind und das Speichern in Memcache zur Deserialisierung von Daten führen würde, die von Memcache kommen, abgesehen von dem zusätzlichen Overhead von IPC.

Ich implementierte einen einfachen Webserver mit BaseHttpServer, es gibt gute Leistung, aber es bleibt nach ein paar Stunden stecken. Ich brauche einen etwas ausgereifteren Webserver. Ist es möglich, Apache zu konfigurieren, um mod_python unter einem Thread-Modell zu verwenden, so dass ich einige Objekte zwischenspeichern kann?

Answer 1

CherryPy. Funktionen, wie von der Website aufgeführt:

• Eine schnelle, HTTP/1.1-konforme WSGI-Thread-Pool-Webserver. Normalerweise benötigt CherryPy selbst nur 1-2ms pro Seite!
• Unterstützung für andere WSGI-fähigen Webserver oder Adapter, einschließlich Apache, IIS, lighttpd, mod_python, FastCGI, SCGI und mod_wsgi
• Einfach mehrere HTTP-Server (zB auf mehrere Ports) auf einmal
• A laufen gleichermaßen leistungsfähigen Konfigurationssystem für Entwickler und Anwender
• Ein flexibles Plugin-System
• Integrierte Tools für Caching, Codierung, Sitzungen, Autorisierung, statische Inhalte, und viele mehr
• Eine native mod_python Adapter
• A komplette Testsuite
• Austauschbar und anpassbar ... alles.
• Integrierte Profilerstellung, Abdeckung und Testunterstützung.

Answer 2

Nicht Multithread, aber twisted könnte Ihre Bedürfnisse erfüllen.

Answer 3

Vielleicht haben Sie ein Problem mit Ihrer Implementierung in Python mit BaseHttpServer. Es gibt keinen Grund dafür, dass es "hängen bleibt", und die Implementierung eines einfachen Thread-Servers mit BaseHttpServer und threading sollte nicht schwierig sein.

Auch finden http://pymotw.com/2/BaseHTTPServer/index.html#module-BaseHTTPServer über einen einfachen Multi-Threaded-Server mit HTTPServer Implementierung und ThreadingMixIn

Answer 4

ich CherryPy verwenden sowohl persönlich als auch professionell, und ich bin sehr zufrieden mit ihm. Ich mache sogar die Art von Dingen, die du beschreibst, wie globale Objekt-Caches, andere Threads im Hintergrund usw. Und es lässt sich gut in Apache integrieren; Führen Sie CherryPy einfach als eigenständigen Server aus, der an localhost gebunden ist, und verwenden Sie Apache mod_proxy und mod_rewrite, damit Apache Ihre Anforderungen transparent an CherryPy weiterleitet.

Die CherryPy Website ist http://cherrypy.org/

Answer 5

Sie stattdessen einen verteilten Cache, der zugänglich ist, von jedem Prozess verwenden könnte, memcached wobei das Beispiel, das in den Sinn kommt.

Answer 6

Überdenken Sie Ihr Design. Es ist wahrscheinlich eine schlechte Idee, diesen Zustand auf Ihrem Webserver zu halten. Multi-Prozess ist ein viel besserer Weg für Stabilität.

Gibt es eine andere Möglichkeit, Status zwischen separaten Prozessen zu teilen? Was ist mit einer Dienstleistung? Datenbank? Index?

Es ist unwahrscheinlich, dass die Verwaltung einer großen Datenmenge im Speicher und die Verwendung eines einzigen Multithread-Prozesses für alle Ihre Anfragen das beste Design oder die beste Architektur für Ihre App ist.

Answer 7

Nur etwas anders als die üblichen Verdächtigen, darauf hinzuweisen ...

Vor einigen Jahren, während ich Zope 2.x wurde ich über Medusa lesen, wie es der Web-Server für die Plattform verwendet wurde. Sie beworben, dass es unter starker Belastung gut funktioniert, und es kann Ihnen die Funktionalität bieten, die Sie gefragt haben.

Answer 8

Es ist schwer, eine definitive Antwort zu geben, ohne zu wissen, an welcher Art von Website Sie arbeiten und welche Art von Belastung Sie erwarten. Die Leistung in der zweiten Sekunde kann eine ernsthafte Anforderung sein oder nicht. Wenn Sie wirklich diese letzte Millisekunde speichern müssen, müssen Sie Ihre Arrays unbedingt im Speicher behalten. Wie andere jedoch vorgeschlagen haben, ist es mehr als wahrscheinlich, dass Sie mit etwas anderem nicht zurechtkommen. Ihr Verwendungsmuster der Daten in dem Array kann beeinflussen, welche Arten von Entscheidungen Sie treffen. Sie benötigen wahrscheinlich nicht auf einmal Zugriff auf die gesamte Datenmenge des Arrays, so dass Sie Ihre Daten in kleinere Blöcke aufteilen und diese Blöcke in den Cache stellen können, anstatt den einen großen Knoten zu verwenden. Abhängig davon, wie oft Ihre Array-Daten aktualisiert werden müssen, können Sie zwischen memcached, lokaler db (berkley, sqlite, kleine mysql-Installation usw.) oder einer entfernten Datenbank wählen. Ich würde sagen, Memcached für ziemlich häufige Updates. Eine lokale db für etwas in der Häufigkeit von stündlich und remote für die Häufigkeit von täglich. Zu beachten ist auch, was nach einem Cache-Miss passiert. Wenn 50 Clients plötzlich einen Cache-Fehler bekommen und alle gleichzeitig entscheiden, diese teuren Arrays zu regenerieren, werden Ihre Boxen schnell auf 8086 reduziert. Sie müssen also berücksichtigen, wie Sie damit umgehen. Viele Artikel da draußen decken auf, wie man sich von Cache-Misses erholt. Ich hoffe, das ist hilfreich.

Answer 9

Twisted kann als ein solcher Webserver dienen. Obwohl es nicht Multithread ist, gibt es einen (noch nicht freigegebenen) Multithread-WSGI-Container, der in der aktuellen Trunk vorhanden ist. Sie können das SVN-Repository auschecken und dann ausführen:

twistd web --wsgi=your.wsgi.application 

Answer 10

Ich hatte eigentlich das gleiche Problem in letzter Zeit. Nämlich: Wir haben einen einfachen Server mit BaseHTTPServer geschrieben und festgestellt, dass die Tatsache, dass es kein Multithread ist, ein großer Nachteil war.

Meine Lösung war, den Server auf Pylons (http://pylonshq.com/) zu portieren. Der Port war ziemlich einfach und ein Vorteil war, dass es sehr einfach ist, eine GUI mit Pylons zu erstellen, so dass ich eine Statusseite über einen Daemon-Prozess werfen konnte.

Ich würde zusammenfassen Pylons auf diese Weise:

• es ist ähnlich wie Ruby on Rails, dass es zielt darauf ab, sehr einfach zu sein Web-Anwendungen zu implementieren
• es Standard-Template-Sprache, Mako, ist sehr schön zu arbeiten mit
• es verwendet ein System Urls von Routing, die
• für uns Leistung sehr praktisch ist, ist kein Problem, so kann ich nicht garantieren, dass Pylone ausreichend für Ihre Bedürfnisse
• durchführen würde können Sie Verwenden Sie es mit Apache & Lighthttpd, obwohl ich es nicht versucht habe

Wir führen auch eine App mit Twisted und sind damit zufrieden. Twisted hat eine gute Leistung, aber ich finde Twisted's Singlethread/Defer-to-Thread Programmiermodell ziemlich kompliziert. Es hat viele Vorteile, wäre aber nicht meine Wahl für eine einfache App.

Viel Glück.

Answer 11

web.py hat mich in der Vergangenheit glücklich gemacht. Überprüfe es.

Aber es klingt wie ein architektonisches Redesign könnte die richtige, wenn auch teurere Lösung sein.