Il est possible d'utiliser WebSphere Real Time avec WebSphere eXtreme Scale. En activant WebSphere Real Time, l'on obtient une récupération de place plus prévisible grâce à des temps de réponses stables et cohérents et des débits de transactions dans un environnement eXtreme Scale autonome.
Installez WebSphere Real Time et WebSphere eXtreme Scale autonome sur les ordinateurs sur lesquels vous prévoyez d'exécuter eXtreme Scale. Définissez la variable d'environnement JAVA_HOME pour qu'elle pointe sur un JRE standard Java SE standard.
Définissez la variable d'environnement JAVA_HOME pour qu'elle pointe sur le WebSphere Real Time installé. Puis activez WebSphere Real Time comme indiqué ci-après.
WXS_REAL_TIME_JAVA="-Xrealtime -Xgcpolicy:metronome -Xgc:targetUtilization=80"
WebSphere Real Time est à présent activé. Pour le désactiver, il vous suffit de repasser la même ligne en commentaire.
WebSphere Real Time confère aux transactions eXtreme Scale des temps de réponse plus prévisibles. Les résultats montrent que les temps de réponse d'une transaction eXtreme Scale s'améliorent de manière significative avec WebSphere Real Time si on les compare à ceux obtenus par le récupérateur de place par défaut de Java. L'activation de WebSphere Real Time avec eXtreme Scale est un must si la stabilité et les temps de réponse de votre application sont essentiels.
Les pratiques recommandées développées ci-après expliquent comment rendre WebSphere eXtreme Scale encore plus efficace grâce à une optimisation et une programmation fonction de la charge attendue.
WebSphere Real Time donne les moyens de contrôler l'utilisation du processeur de manière à contrôler et à réduire l'impact de la récupération de place sur votre application. Le paramètre -Xgc:targetUtilization=NN permet de spécifier NN comme pourcentage du processeur qui est utilisé par votre application toutes les 20 secondes. Par défaut, cette valeur est de 80 % pour WebSphere eXtreme Scale, mais vous pouvez modifier le script dans le fichier objectgridRoot/bin/setupCmdLine.sh pour définir un autre chiffre, 70, par exemple, qui libère davantage de capacité processeur pour le récupérateur de place. Déployez suffisamment de serveurs pour maintenir la charge processeur en dessous de 80 % pour vos applications.
WebSphere Real Time utilise davantage de mémoire que le Java standard, aussi, prévoyez plus de mémoire dynamique pour votre WebSphere eXtreme Scale et définissez la taille du segment mémoire lors du démarrage des serveurs de catalogue avec le paramètre –jvmArgs –XmxNNNM dans la commande ogStartServer. Vous pouvez, par exemple, utiliser le paramètre –jvmArgs –Xmx500M pour démarrer des serveurs de catalogue et utilisez une taille mémoire appropriée pour démarrer les conteneurs. Vous pouvez fixer la taille de la mémoire à 60-70 % de la taille prévue par machine virtuelle Java pour vos données . Si vous ne définissez pas cette valeur, une erreur OutOfMemoryError risque de se produire. Vous pouvez également, si vous le souhaitez, utiliser le paramètre –jvmArgs –Xgc:noSynchronousGCOnOOM pour empêcher le comportement non déterministe lorsque la machine virtuelle Java est à court de mémoire.
WebSphere eXtreme Scale crée un grand nombre d'objets temporaires associés à chaque transaction et aux unités d'exécution RPC (Remote Procedure Call). La récupération de place présente des avantages pour les performances si votre ordinateur dispose de suffisamment de cycles processeur. Le nombre d'unités d'exécution est de 1 par défaut. L'argument –Xgcthreads n permet de modifier ce nombre. La valeur suggérée pour cet argument est le nombre de coeurs qui sont disponibles en prenant en considération le nombre de machines virtuelles Java par ordinateur.
WebSphere Real Time est optimisé pour les applications à exécution longue. D'ordinaire, vous avez besoin d'exécuter des transactions WebSphere eXtreme Scale pendant deux heures en continu pour obtenir des données de performances fiables. Le paramètre –Xquickstart donne de meilleures performances à vos applications à exécution courte. Ce paramètre indique au compilateur JIT (just-in-time) d'utiliser un bas niveau d'optimisation.
Le principal avantage d'utiliser WebSphere eXtreme Scale avec WebSphere Real Time est de bénéficier de temps de réponse des transactions extrêmement fiables, qui représentent usuellement une amélioration de l'ordre de plusieurs fois l'écart constaté dans les temps de réponse des transactions. Toutes les demandes clients mises en file d'attente et tous les relais de ces demandes effectuées via d'autres logiciels ont un impact sur les temps de réponse qui échappent au contrôle de WebSphere Real Time et de WebSphere eXtreme Scale. Vous devez modifier les paramètres de vos unités d'exécution et de vos sockets pour conserver une charge à la fois ferme et fluide sans retards significatifs et vous devez diminuer la profondeur des files d'attente.
Sans modifier votre application, vous pouvez obtenir des temps de réponse WebSphere eXtreme Scale des transactions extrêmement fiable représentant une amélioration de l'ordre de plusieurs fois l'écart standard dans les temps de réponse des transactions. Vous pouvez exploiter davantage les unités d'exécution de vos applications transactionnelles en passant du threading Java standard au RealtimeThread, qui fournit un meilleur contrôle de la priorité des unités d'exécution et de la planification.
Actuellement, votre application comporte le code suivant :
public class WXSCacheAppImpl extends Thread implements WXSCacheAppIF
Vous pouvez remplacer ce code par le code suivant :
public class WXSCacheAppImpl extends RealtimeThread implements WXSCacheAppIF