J'ai récemment déployé une application Spring MVC à Google App Moteur et que la durée totale de la charge est d'environ 7 secondes. Une fois que l'application est chargée, l'application est assez réactive. Mais si l'application est inactive pendant plus de 1 minute (il n'y a pas de trafic de trafic), l'application doit être à nouveau rechargée par GAE, qui prend également environ 7 secondes. Pour une application de niveau de PRD, cela est inacceptable. ( l'application est vide - je n'utilise même pas JPA, Sitemesh, Sécurité de printemps, etc. Il charge simplement une page JSP avec du texte. P>) P>
La seule "meilleure pratique" pour résoudre le "temps de chargement" que j'ai vu jusqu'à présent est de mettre en place un travail cron qui frappe l'URL chaque minute, ce qui maintient l'application "chargée". Évidemment, c'est une solution terrible. P>
Voici la question suivante: existe-t-il des "meilleures pratiques" pour le printemps sur GAE en termes de "réactivité"? Étant donné que Google et le printemps travaillent à la mise au point d'une meilleure intégration entre les deux, y a-t-il eu des nouvelles / progrès sur ce problème? Je ne trouve rien de concret, c'est pourquoi je le demande ici ici strong> em> p>
Discussions sur le sujet:
http://groups.google.com/group/google-appengine -java / browse_thread / thread / 80D014FD5ABD526F p>
Il existe un "billet" pour créer des instances réservées, ainsi que "chauffer" logique:
http://code.google.com/p/googleAppengine/issues/detail ? id = 2456 p>
3 Réponses :
OK, faute de réponses, j'ai décidé d'aller avec le travail cron (car je ne peux pas voir une autre option à partir de maintenant)
Voici le fichier cron.xml que j'utilise p> et voici le contrôleur: p>
S'il vous plaît ne faites pas ça. code.google.com/appengine/kb/java.html#should_i_run_a_cron_j ob < / a>
J'ai lu ça, malheureusement, il n'y a pas d'autre moyen! À moins que je souhaite que mes utilisateurs attendent 10 secondes avant que ma page ne se charge, c'est le seul moyen de la garder relativement «prête à la production». Comme je l'ai mentionné ci-dessus, Google travaille sur une solution (payée et gratuite). Jusqu'à ce que cette solution soit créée, beaucoup de personnes qui ont créé des applications Java à déployer sur Google ne sont pas de chance: code.google.com/p/googleappengine/issues/detail?id=2456
Si votre application "Production" possède des exigences SLA (accord de niveau de service), vous devez alors envisager de meilleures solutions d'hébergement que GAE. GAE ne garantit pas de temps de disponibilité, de temps de réponse, etc. et surtout pas pour les comptes gratuits. Si vous souhaitez utiliser GAE, vos utilisateurs vont devoir payer le temps d'attente. Cependant, si vous avez besoin d'une sorte de fiabilité, vous envisagez probablement de dépenser quelques dollars.
@Gweebz - Il n'y avait pas de mention (ni d'avertissement) sur le site de GAE que l'heure de chargement d'une application Java peut dépasser 15 secondes et pour effectuer un commutateur rapide d'une "plate-forme" à une autre (par exemple Amazon) n'est pas réalisable dans la plupart des cas. Donc, ces personnes qui ont décidé de développer leur application Java sur GAE n'étaient pas au courant de cet énorme stumage. De plus, lorsque j'ai commencé ce "thread", il n'y avait aucune option pour payer une instance "toujours sur".
Depuis SDK 1.4.0 < / a> Vous pouvez éviter cette latence en utilisant Demandes d'échauffement .
WarmUp demande la charge du code d'application dans une nouvelle instance avant que toutes les demandes vivantes atteignent cette instance. P>
Cela ne fonctionne que lorsque l'instance initiale est chargée (qui prend plus de 10 secondes).
GAE a commencé à fournir un service payé dans lequel vous pouvez avoir une instance hot-instance réservée à tout moment: P>
http: // googleAppEgine. blogspot.com/2010/12/happy-Holidays-from-app-Engine-team-140.html P>
Toujours sur - pour les applications hautement prioritaires avec trafic faible ou variable, vous pouvez désormais réserver des instances via la fonctionnalité Toujours sur une fonctionnalité d'App. Toujours sur est une caractéristique premium coûtant 9 $ par mois qui se réserve trois instances de votre demande, ce qui ne les désactive jamais, même si l'application n'a pas de trafic. Cela atténue l'impact des demandes de chargement sur les applications présentant des quantités de trafic de petites ou variables. P> blockQuote>
En conjonction avec les demandes d'échauffement, il s'agit de la meilleure solution si vous envisagez d'utiliser GAE. p>
Par curiosité, pourquoi le travail cron "évidemment" est-il une mauvaise solution. Il "évidemment" grille, mais si ça marche ...
Au fur et à mesure que l'application se développe, le temps nécessaire à l'initialisation augmentera, par conséquent, le travail de 1 minute cron se transformera en un travail cron 30 secondes si l'application prend 30 secondes pour initialiser, etc. Il suffit d'ajouter une sécurité de printemps augmenterait la charge. temps assez drastiquement. En outre, cela ajoute une complexité inutile pour un problème de printemps / gazeux qui devrait être corrigé. :)