J'ai récemment appris sur les scénarios qui nécessitent de réchauffer une application (avec une exigence de débit élevé) avant de commencer à servir de vraies demandes. La logique derrière c'était pour permettre à JIT de faire sa performance magique!
est-ce une norme pour les applications Java ou est-ce généralement faite pour les applications de mémoire lourdes (pas d'empreinte)?
3 Réponses :
Si vous parlez d'un webApp / site Web de trafic élevé, JIT est un problème très mineur. Le plus gros problème est de réchauffer (peupler) toutes les couches de cache dont vous aurez besoin. Par exemple, régions EHCache qui sont peuplées d'hibernate < / a>. C'est parce que les opérations liées à IO sont des ordres de magnitude plus lentement que tout ce qui se passe à l'intérieur de la CPU (si vous calculez des fractales :)
Merci pour le pointeur, mais je pense que je faisais référence à la réchauffement des chemins de code plutôt que des données "coûteuses". Je me demandais particulièrement s'il est logique que les grandes applications Java soient pré-réchauffées en particulier envisagent de considérer que JVMS aujourd'hui est suffisamment intelligente pour décider du chemin de code accessible beaucoup et donc de mettre en cache le JIT pour eux, etc. Certainement, il y a un perf. Frappez lors de la première fois pour la première fois et je voulais donc savoir si dans la vie réelle, quiconque a été confronté à cette question qui les aurait encouragée à réchauffer leurs applications et, dans l'affirmative, ce que la perf. les améliorations ont-elles vu.
@Aayush Pui: Et ma réponse était que si vous parlez de WebApp, alors Jit Warmup est de 0,01% important, donc dans la vie réelle (et dans le contexte de WebApps), tout le monde a des problèmes plus importants à résoudre (réchauffement de la base de données, caches, etc.)
BTW lors de certaines recherches sur le Web sur un sujet connexe, j'ai découvert une petite discussion sur ce sujet de ce sujet par quelques personnes dans l'équipe IBM WebSphere Extreme Scale: youtube.com/watch?v=hrbtyk1yra Ils n'ont pas beaucoup expliqué sur l'application, mais je suppose que ce type de scénario est assez rare
La question est, quand voudriez-vous Si vous déployez une webApp, et il est immédiatement en direct, alors que vous «réchauffez-vous», vous ajoutez une charge supplémentaire, ce qui est contre-productif. Similaire est vrai quand une application de bureau commence. Aucun point de réchauffement si l'utilisateur va commencer immédiatement à l'utiliser. Ou pire, ne permettant pas à l'utilisateur d'interagir pendant que vous réchauffez l'application.
Si vous déployez une webApp, et vous testez le déploiement avant de pointer vos équilibreurs de charge, vous l'avez déjà réchauffé comme résultat du côté.
Personnellement, I irait de mon mieux pour le faire lorsque je fais des tests de performance. Ou quand j'ai un cluster et réchauffer une machine avant de le brancher dans le cluster n'affecte pas les utilisateurs.
Mais si votre environnement de production n'a pas bénéficié de réchauffement, pourquoi voudriez-vous incliner vos résultats de test de performance en réchauffement dans l'environnement de test de performance?
Je suis tout à fait d'accord pour dire qu'il est logique de réchauffer une application avant de l'ajouter à votre équilibreur de charge.
En plus de La réponse de Cherouvim , je peux penser de quelques autres problèmes nécessitant un échauffement:
XMS est plus petit que votre xmx ).
J'imagine que le système d'exploitation s'attache également au comportement d'une application, de sorte que les appels du système d'exploitation peuvent également être affectés par une période d'échauffement.
La plupart des éléments ci-dessus (la population cache, l'initialisation de l'objet) ne sont pas spécifiques à Java.
> Allocation de tas (si votre XMS est plus petit que votre XMX). Bon point. Et je crois que c'est pourquoi il est dit de définir xmx = xms
Le réglage de la performance est de moins sur "l'apprentissage des scénarios" que de mesurer et d'analyser ce qui se passe dans vos scénarios spécifiques .
Voir aussi ma question: Stackoverflow.com/Questtions/1481853/...