Je développe une application sur GAE à l'aide de Python 2.7, un appel AJAX demande certaines données d'une API, une demande unique pourrait prendre environ 200 ms, toutefois, lorsque j'ouvre deux navigateurs et faire deux demandes à une heure très étroite qu'ils prennent plus que le double de cela, j'ai essayé de mettre tout dans des threads, mais cela n'a pas fonctionné .. (Cela se produit lorsque l'application est en ligne, non seulement sur le dev-serveur)
donc j'ai écrit ce simple test à Voir si ceci est un problème dans Python en général (en cas d'attente occupée), voici le code et le résultat: p> le résultat sur Mac OS X, noyau I7 (4 cœurs, 8 threads), Python2.7: P> single threaded:
<Thread(Thread-1, started 4315942912)> 2011-12-06 15:38:07.763146
<Thread(Thread-1, started 4315942912)> 2011-12-06 15:38:13.091614 0:00:05.328468
multi threaded:
<Thread(Thread-2, started 4315942912)> 2011-12-06 15:38:13.091952
<Thread(Thread-3, started 4323282944)> 2011-12-06 15:38:13.102250
<Thread(Thread-3, started 4323282944)> 2011-12-06 15:38:29.221050 0:00:16.118800
<Thread(Thread-2, started 4315942912)> 2011-12-06 15:38:29.237512 0:00:16.145560
3 Réponses :
L'interprète CPPHON ne permettra pas davantage d'exécuter un fil. Lisez à propos de Gil http://wiki.python.org/moin/globalInterPreterlock
Donc, certaines tâches ne peuvent pas être faites simultanément de manière efficace dans le CPPHON avec des threads.
Si vous voulez faire des choses parallèles dans GAE, commencez-les parallèlement à des demandes séparées.
En outre, vous voudrez peut-être consulter le Wiki http://wiki.python.org/ Moin / ParallelalProcessing
Je regarderais où se passe le moment. Supposons, par exemple, le serveur ne peut répondre que dans une requête chaque 200ms. Ensuite, il n'y a rien que vous puissiez faire, vous n'obtiendrez qu'une réponse à chaque 200ms car c'est tout ce que le serveur peut vous fournir.
Regardez son code. Il appelle DateTime , pas de communication avec un serveur.
David Bezley a donné une conversation à propos de ce problème à Pycon 2010. Comme d'autres l'ont déjà dit, pour certaines tâches, l'utilisation de la filetage en particulier avec plusieurs cœurs peut entraîner des performances plus lentes que la même tâche effectuée par un seul fil. Le problème, Beazley a trouvé, a dû faire avec plusieurs cœurs ayant un "Gil Battle" :
p>
Pour éviter les conflits Gil, vous pouvez obtenir de meilleurs résultats avec les tâches Exécutez dans des processus séparés au lieu de threads séparés. MultiProcessing module offre un moyen pratique de le faire, en particulier depuis l'API multiprocessing, est Très similaire à l'API de threading. P>
single process: Process-1 2011-12-06 12:34:20.611526 Process-1 2011-12-06 12:34:28.494831 0:00:07.883305 multi process: Process-3 2011-12-06 12:34:28.497895 Process-2 2011-12-06 12:34:28.503433 Process-2 2011-12-06 12:34:36.458354 0:00:07.954921 Process-3 2011-12-06 12:34:36.546656 0:00:08.048761
Ce comportement est-il spécifique à Python? Et si oui, pourquoi?
Le gil est spécifique à Python, et donc "batailles Gil" sont spécifiques au gil. Je ne sais pas si quelque chose de similaire peut arriver dans d'autres langues.
Avez-vous lu quelque chose sur le verrouillage de l'interprète global (GIL) à Python? Si vous voulez un traitement parallèle, vous devriez examiner le multiprofession, pas le filetage. L'exécution est limitée à un seul fil à la fois, à moins que les bibliothèques utilisées sont spécifiquement conçues pour libérer le gil.
Votre référence est mal conçue. Votre cas d'utilisation réelle sera io-lié et non liée à la CPU. Le gil de Python se comporte assez différemment dans chaque cas. Filetage Devrait Travailler correctement pour vous dans votre cas d'utilisation réelle.
@ g.d.d.c. Le multiprocession n'est pas disponible dans GAE
@bpgergo C'est dans le temps d'exécution de Python 2.7.
L'autre problème que vous voyez, Mohamed, est que le moteur d'application Dev_AppServer est une seule fois fileté, de sorte que plusieurs demandes sont exécutées de manière séquentielle. Ce n'est pas le cas dans la production. Ne vous attendez pas à ce que les métriques de performance sur Dev_AppServer soient représentatives du comportement de production.