Il y a très longtemps, j'ai écrit une web-spider que j'ai multithreadée pour permettre aux requêtes simultanées de se produire en même temps. C'était dans ma jeunesse Python, dans les jours avant que je connaissais le GIL et les malheurs associés qu'il crée pour le code multithread (IE, la plupart du temps, les choses finissent par être sérialisées!) ...
Je voudrais retravailler ce code pour le rendre plus robuste et mieux performer. Il y a essentiellement deux façons de le faire: je pourrais utiliser le nouveau module de multitraitement dans 2.6+ ou je pourrais opter pour un modèle basé sur un réacteur / événement d'une certaine sorte. Je préfère faire plus tard, car il est beaucoup plus simple et moins sujet aux erreurs.
La question porte donc sur le cadre le mieux adapté à mes besoins. Voici une liste des options que je connais jusqu'à présent:
- Twisted : Le grand-père des frameworks de réacteurs Python: semble complexe et un peu gonflé cependant. Courbe d'apprentissage abrupte pour une petite tâche.
- Eventlet : Des gars du lindenlab . Cadre basé sur Greenlet et orienté vers ce type de tâches. J'ai cependant regardé le code et ce n'est pas trop joli: non compatible pep8, parsemé d'impressions (pourquoi les gens font ça dans un framework!?), L'API semble un peu incohérente.
- PyEv : Immature, il ne semble pas que quiconque l'utilise actuellement, bien qu'il soit basé sur libevent, il a donc un solide backend.
- asyncore : Du stdlib: über bas niveau, il semble que beaucoup de travail de base soit nécessaire pour faire décoller quelque chose.
- tornade : Bien qu'il s'agisse d'un produit orienté serveur conçu pour desservir des sites Web dynamiques, il dispose d'un client HTTP asynchrone et d'un simple ioloop . On dirait que cela pourrait faire le travail, mais pas ce à quoi il était destiné. [edit: ne fonctionne pas sur Windows malheureusement, ce qui compte pour moi - c'est une exigence pour moi de prendre en charge cette plate-forme boiteuse]
Y a-t-il quelque chose que j'ai manqué du tout? Il doit sûrement y avoir une bibliothèque qui correspond au bonbon d'une bibliothèque de réseau asynchrone simplifiée!
[edit: merci à intgr pour son pointeur sur cette page . Si vous faites défiler vers le bas, vous verrez qu'il y a une très belle liste de projets qui visent à aborder cette tâche d'une manière ou d'une autre. Il semble en fait que les choses aient effectivement évolué depuis la création de Twisted: les gens semblent désormais privilégier une solution basée sur la co-routine plutôt qu'une solution traditionnelle orientée réacteur / callback. Les avantages de cette approche sont un code plus clair et plus direct: j'ai certainement trouvé dans le passé, surtout lorsque vous travaillez avec boost.asioen C ++, ce code basé sur le rappel peut conduire à des conceptions difficiles à suivre et relativement obscures à l'œil non averti. L'utilisation de co-routines vous permet d'écrire du code qui semble au moins un peu plus synchrone. Je suppose que maintenant ma tâche est de déterminer laquelle de ces nombreuses bibliothèques j'aime le look et d'essayer! Heureux d'avoir demandé maintenant ...]
[modifier: peut-être d'intérêt pour quiconque a suivi ou est tombé sur cette question ou se soucie de ce sujet dans tous les sens: j'ai trouvé un très bon résumé de l'état actuel des outils disponibles pour ce travail]
select
pour le multiplexage d'E / S. Mais vous devriez pouvoir en tirer une performance décente avec tornado-pyuv . 2. Il y a maintenant asyncio dans Python 3.3+ et son trollius backport qui permet d'exécuter n'importe quelle application Tornado dans sa boucle d'événement (Twisted sera bientôt supporté).