Meilleur (ou approprié) serveur WSGI pour ce script Python? - Python

Question

Je n'arrive pas à décider comment utiliser quelques scripts Python.

Le problème est que la fonctionnalité de base pourrait être généralisée par ceci:

do_something() 
time.sleep(3) 
do_something() 

---

J'ai essayé différents serveurs WSGI, mais ils ont tous été de me donner des limitations de concurrence, comme je dois spécifiez le nombre de threads à utiliser, etc. Je souhaite seulement que les ressources sur le serveur soient utilisées efficacement et libéralement.

---

---

Toutes les idées?

Answer 1

Avez-vous vérifié tornade avec ses demandes asynchrones non bloquantes?

http://www.tornadoweb.org/

Je n'ai jamais utilisé bien mais voici un exemple de doc:

class MainHandler(tornado.web.RequestHandler): 
    @tornado.web.asynchronous 
    def get(self): 
     http = tornado.httpclient.AsyncHTTPClient() 
     http.fetch("http://friendfeed-api.com/v2/feed/bret", 
        callback=self.async_callback(self.on_response)) 

    def on_response(self, response): 
     if response.error: raise tornado.web.HTTPError(500) 
     json = tornado.escape.json_decode(response.body) 
     self.write("Fetched " + str(len(json["entries"])) + " entries " 
        "from the FriendFeed API") 
     self.finish() 

Answer 2

Qu'en est-il du serveur CherryPy WSGI?

Que signifie sleep? Êtes-vous vraiment en train d'écrire une application web?

Answer 3

Vous trouverez peut-être Spawning un bon ajustement. Il dispose de plusieurs options de déploiement, dont l'une est asynchrone quelque peu transparente (implémentée par Eventlet). Donc, si vous faites littéralement time.sleep(3) ça ira. Tout ce que vous pouvez faire n'est pas géré de manière transparente, vous devez donc faire attention à Eventlet et à son fonctionnement. Les sockets sont, par exemple, si vous lisez d'un socket (et que le socket bloque) il n'arrêtera pas le serveur ou ne consommera pas un thread. Mais si vous faites du gros travail CPU qui bloquera toutes les demandes. Alors ... c'est un peu compliqué. Spawning a d'autres options de déploiement qui pourraient fonctionner pour vous aussi.

Vous pourriez être en mesure d'utiliser WaitForIt, mais il a quelques pièges. Il génère des threads pour les requêtes de longue durée et fournit des retours de navigateur. Par conséquent, si vous créez un frontend très simple pour les processus backend de longue durée, cela peut être utile. Il agit en tant que middleware WSGI.

Answer 4

Ainsi, le client peut être bloqué en attendant une réponse pendant 3 secondes, mais pas OK pour le serveur? Cela semble ... étrange. Si vous préférez et non que le client soit ligoté pendant 3 secondes, un mécanisme commun consiste à faire en sorte que la requête initiale renvoie "202 Accepted" ASAP avec une URL vers un moniteur d'état. Ensuite, le serveur peut générer un nouveau thread ou sous-processus pour la tâche, et le client peut faire d'autres choses, puis interroger l'URL d'état pour savoir quand la tâche est terminée.