Instance Django démarrer sous Google App Engine

Question

Après avoir réfléchi longuement sur la façon de créer une application Web rapide et évolutive, je suis presque décidé à opter pour une combinaison de Google App Engine, Python + Django et app-engine-patch . Mais je suis tombé sur un commentaire dans le app-engine-patch FAQ qui m'a fait penser que peut-être la combinaison n'est pas aussi mature que je le pensais: cela peut prendre quelques secondes (1-4, selon la FAQ) pour démarrer une instance de Django. Cela peut ne pas être un problème s'il y a une certaine persistance de la demande à la demande, mais il semble que lorsqu'il n'y a pas de trafic soutenu, l'instance de Django est arrêtée en quelques secondes. Si le système n'est pas appelé toutes les secondes ou plus, toute demande entrante prendra quelques secondes (!) Pour être accordée. C'est inacceptable. Comme une solution rapide (moche, je sais), je pensais à avoir une machine externe faisant une demande factice au framework chaque seconde juste pour le garder en vie.

Êtes-vous d'accord avec cela? Avez-vous une autre approche? Un autre doute que j'ai est ce qui se passera s'il y a assez de trafic pour passer d'un n serveurs à n + 1, cette requête prendra-t-elle quelques secondes parce qu'une nouvelle instance de Django doit être lancée? ou l'infrastructure de Google ne fonctionne pas de cette façon? Je confesse mon ignorance à ce sujet. problème.

Aide!

Answer 1

Je respecte ce que vous essayez de faire, mais cela ressemble un peu à l'optimisation pré-mature pour moi. Le patch py + django dont vous parlez est recommandé par Google jusqu'à la mise à niveau vers le "vrai" django, donc je ne peux pas imaginer que ce soit si mauvais. Ce n'est pas si difficile de tester la performance de ce dont vous parlez, alors je vous suggère de le faire et de faire quelques mesures avant de prendre votre décision finale. De cette façon, vous aurez des maths pour le sauvegarder quand quelqu'un d'autre commence à se plaindre;)

Answer 2

Oui, les longs temps de démarrage sont une mise en garde d'utiliser un framework avec beaucoup de code. À l'heure actuelle, il n'y a aucun moyen de les contourner, mis à part l'utilisation d'un framework plus léger (tel que le framework webapp intégré). Il n'est pas recommandé d'interroger votre application: elle utilise un quota et ne garantit pas que les demandes réelles des utilisateurs touchent la même instance que vos demandes d'interrogation, car les applications s'exécutent sur plusieurs instances. Heureusement, il existe une solution simple: soyez populaire! Plus votre application est populaire, moins les instances ont besoin de redémarrer, et plus la proportion d'utilisateurs affectée est faible.

Answer 3

Aussi, il me semble (mais Nick peut me corriger ici si je me trompe) que si vous utilisez le Django intégré (.97 ou 1.0) le chargement est moins un problème. Logiquement, je dirais qu'ils gardent les bibliothèques intégrées en mémoire pour tout le monde, ou partagent ce code en cache entre les instances. Mais je ne sais pas avec certitude.

Answer 4

Voir Takashi Matsuo's comparisons. Fondamentalement, pour le plus simple app-engine-patch qui ne fait presque rien, il réclame environ ~ 1s contre ~ 350ms pour les templates webapp + Django.

Il semble que ce soit plus long que 1s pour notre application, mais Takashi vient d'essayer l'application la plus simple à laquelle il puisse penser.

Answer 5

Ils mentionnent également dans la FAQ que l'utilisation d'une version zippée de Django va aider le temps de chargement, bien que je suppose qu'il pourrait encore être long. En ce qui concerne votre question initiale, je serais d'accord avec d'autres personnes que l'interrogation de votre application n'est probablement pas une bonne idée car cela ne résoudra probablement pas votre problème car Google peut distribuer vos requêtes sur plusieurs machines, etc ..