Un bon serveur web multithread en python?

Question

Je recherche un serveur Web python multithread au lieu d’être multi-processus (comme dans le cas de mod_python pour apache). Je veux qu'il soit multithread parce que je veux avoir un cache d'objets en mémoire qui sera utilisé par divers threads http. Mon serveur Web effectue beaucoup de choses coûteuses et calcule des tableaux de grande taille qui doivent être mis en cache dans la mémoire pour une utilisation ultérieure afin d'éviter les calculs. Ceci n'est pas possible dans un environnement de serveur Web multi-processus. Stocker ces informations dans memcache n’est pas non plus une bonne idée, car les baies sont volumineuses et les stocker dans memcache entraînerait la désérialisation des données provenant de memcache, en plus des frais généraux supplémentaires engendrés par IPC.

J'ai implémenté un serveur Web simple en utilisant BaseHttpServer, il donne de bonnes performances mais reste bloqué au bout de quelques heures. J'ai besoin d'un serveur Web plus mûr. Est-il possible de configurer apache pour utiliser mod_python sous un modèle de thread afin que je puisse faire de la mise en cache d'objets?

Answer 1

CherryPy . Caractéristiques répertoriées sur le site Web:

• Serveur Web rapide, en pool de threads WSGI, conforme à HTTP / 1.1. En général, CherryPy ne prend que 1 à 2 ms par page!
• Prise en charge de tout autre serveur Web ou adaptateur compatible WSGI, y compris Apache, IIS, lighttpd, mod_python, FastCGI, SCGI et mod_wsgi
• Facile à exécuter plusieurs serveurs HTTP (par exemple sur plusieurs ports) à la fois
• Un système de configuration puissant pour les développeurs et les déployeurs
• Un système de plug-in flexible
• Outils intégrés pour la mise en cache, le codage, les sessions, les autorisations, le contenu statique, etc.
• Un adaptateur natif mod_python
• Une suite de tests complète
• échangeable et personnalisable ... tout.
• Prise en charge intégrée du profilage, de la couverture et des tests.

Answer 2

Envisagez de reconsidérer votre conception. Maintenir autant d’état sur votre serveur Web est probablement une mauvaise idée. Le multi-processus est une bien meilleure solution pour la stabilité.

Existe-t-il un autre moyen de partager l’état entre processus distincts? Qu'en est-il d'un service? Base de données? Indice?

Il semble improbable que la meilleure conception ou architecture de votre application repose sur le maintien d'un vaste éventail de données en mémoire et sur le recours à un processus multi-thread unique pour répondre à toutes vos demandes.

Answer 3

Twisted peut servir de serveur Web. Bien que non multithread lui-même, un conteneur WSGI multithread multithread (non encore publié) est présent dans le tronc actuel. Vous pouvez extraire le référentiel SVN puis exécuter:

twistd web --wsgi=your.wsgi.application

Answer 4

Il est difficile de donner une réponse définitive sans savoir sur quel type de site vous travaillez et quel type de charge vous attendez. Une performance inférieure à la seconde peut être une exigence sérieuse ou non. Si vous avez vraiment besoin de sauvegarder cette dernière milliseconde, vous devez absolument garder vos tableaux en mémoire. Cependant, comme d'autres l'ont suggéré, il est fort probable que vous ne le fassiez pas et que vous puissiez vous débrouiller avec autre chose. Votre modèle d'utilisation des données dans le tableau peut affecter les types de choix que vous faites. Vous n’avez probablement pas besoin d’accéder en une fois à l’ensemble des données du tableau, vous pouvez donc les diviser en morceaux plus petits et les mettre dans le cache au lieu d’un seul gros morceau. Selon la fréquence à laquelle les données de votre tableau doivent être mises à jour, vous pouvez choisir entre une base de données locale, memcached (berkley, sqlite, une petite installation de mysql, etc.) ou une base de données distante. Je dirais memcached pour les mises à jour assez fréquentes. Une base de données locale pour quelque chose dans la fréquence horaire et à distance pour la fréquence quotidienne. Une chose à considérer est aussi ce qui se passe après une cache manquante. Si 50 clients obtiennent tout à coup une cache manquante et décident en même temps de commencer à régénérer ces tableaux coûteux, votre ou vos boîtes seront rapidement ramenées à 8086. Vous devez donc considérer comment vous allez gérer cela. De nombreux articles traitent de la façon de récupérer des informations manquantes dans la mémoire cache. J'espère que cela vous sera utile.

Answer 5

Non multithread, mais twisted pourrait répondre à vos besoins.

Answer 6

Vous pouvez également utiliser un cache distribué accessible à partir de chaque processus, memcached , par exemple. cela me vient à l'esprit.

Answer 7

web.py m'a rendu heureux par le passé. Envisagez de le vérifier.

Mais il semble qu'une refonte architecturale pourrait être la solution appropriée, bien que plus onéreuse.

Answer 8

Vous avez peut-être un problème avec votre implémentation dans Python avec BaseHttpServer . Il n’ya aucune raison de "rester bloqué", et la mise en œuvre d’un serveur threadé simple utilisant BaseHttpServer et threading ne devrait pas être difficile.

Voir également http://pymotw.com/2/BaseHTTPServer/ index.html # module-BaseHTTPServer sur la mise en œuvre d'un serveur multi-thread simple avec HTTPServer et ThreadingMixIn

Answer 9

J'utilise CherryPy à la fois personnellement et professionnellement, et j'en suis extrêmement heureux. Je fais même le genre de chose que vous décrivez, comme avoir des caches d'objets globaux, exécuter d'autres threads en arrière-plan, etc. Et cela s'intègre bien à Apache; Exécutez simplement CherryPy en tant que serveur autonome lié à localhost, puis utilisez les mod_proxy et mod_rewrite d'Apache pour que Apache transmette vos demandes à CherryPy de manière transparente.

Le site Web CherryPy est http://cherrypy.org/

.

Answer 10

J'ai eu le même problème récemment. A savoir: nous avons écrit un serveur simple en utilisant BaseHTTPServer et avons constaté que le fait qu’il ne soit pas multi-thread était un gros inconvénient.

Ma solution consistait à porter le serveur sur Pylons ( http://pylonshq.com/ ). Le portage était assez facile et l'un des avantages était qu'il était très facile de créer une interface graphique à l'aide de pylônes. J'ai donc pu afficher une page de statut en plus de ce qui est fondamentalement un processus démon.

Je résumerais les pylônes de la manière suivante:

• similaire à Ruby on Rails en ce sens qu'il est très facile de déployer des applications Web
• c'est le langage de gabarit par défaut, Mako, il est très agréable de travailler avec
• il utilise un système de routage des URL très pratique
• pour nous, les performances ne sont pas un problème, je ne peux donc pas garantir que Pylons fonctionnerait correctement pour vos besoins
• vous pouvez l’utiliser avec Apache & amp; Lighthttpd, bien que je n’ai pas essayé cela

Nous utilisons également une application avec Twisted et nous en sommes satisfaits. Les performances de Twisted sont bonnes, mais je trouve le modèle de programmation à thread unique / différé à thread de Twisted assez complexe. Cela présente de nombreux avantages, mais ce ne serait pas mon choix pour une application simple.

Bonne chance.

Answer 11

Juste pour signaler quelque chose de différent des suspects habituels ...

Il y a quelques années, alors que j'utilisais Zope 2.x, j'ai lu des articles sur Medusa , car il s’agissait du serveur Web utilisé pour la plate-forme. Ils ont annoncé qu'il fonctionnait bien sous une charge importante et qu'il peut vous fournir les fonctionnalités que vous avez demandées.