Nous appelons un programme Java sur une machine iseries et le premier appel au programme est lent. Les appels suivants sont rapides mais si nous attendons un certain temps, l'appel est lent à nouveau.Conserver la JVM sous iseries
Comment puis-je maintenir la JVM en service ou existe-t-il un autre moyen de résoudre ce problème?
Merci
(IBM Technology for Java) de la nouvelle machine virtuelle Java sont les plus rapides disponibles. Le problème typique est que si les propres fichiers JAR de la JVM sont mis en mémoire cache, il est assez rapide à charger. Dans le cas contraire, ils doivent être chargés à partir du disque, ce qui est assez lent. (Il existe actuellement un processus d'accélération pour Windows).
Vous pourriez envisager d'avoir un petit script qui lit toutes les jarres de la JVM toutes les X secondes, ou d'implémenter un "communiquer avec le démon JVM par les files de données" qui est l'approche traditionnelle pour cela.
Merci pour votre réponse. Pourriez-vous s'il vous plaît donner un exemple d'un tel script ou me diriger vers une documentation sur la façon de le faire et comment implémenter les files d'attente de données? – user271858
Votre meilleur pari pour l'instant est de faire fonctionner les JVM dans leur propre sous-système. –
Vous voudrez peut-être envisager de faire de votre application java un serveur qui fonctionne tout le temps ... votre application native peut envoyer des demandes de réception au serveur en utilisant des files d'attente de tcp ou de données. De cette façon, le coût de démarrage du serveur est une chose unique et aucun des utilisateurs ne doit jamais en souffrir.
alloueront plus de mémoire au sous-système de la machine virtuelle Java est en cours d'exécution dans.
Ne pas appeler une méthode statique, car, par définition, une classe statique ne doit pas rester en mémoire.
Appelle les méthodes avec * ceci.
Bonne chance
'this' est implicite. –
Implicite est quelque chose de totalement différent de statique. N'appelez pas les classes java statiques car, par définition, elles seront chargées et déchargées pour chaque appel. C'est la même chose que d'appeler un rpg qui revient avec * lr sur. Pas une bonne pratique quand le problème est la vitesse ou dans votre cas à quelle vitesse il charge la vitesse. – danny117
Dans un contexte IBM i, "appeler un programme" peut être plusieurs choses selon le contexte. Par exemple en invoquant RUNJVA (qui est ce que je connais le mieux) ou par le biais d'un programme RPG (dont je crois que c'est ce dont vous parlez). La sémantique semble être différente. Une clarification de OP peut être nécessaire. (et je suis content que vous éditiez "mec" en quelque chose de différent) –
Comment avez-vous déterminé qu'il était un problème « garder la machine virtuelle Java et en cours d'exécution » plutôt que l'utilisation de pool de mémoire ou un autre problème? – user2338816