Remarques sur les performances du service Work Area
Le service Work Area est conçu pour prendre en charge les différents modes de transmission de données complexes qui peuvent sérieusement compliquer les tâches de maintenance. Une zone de travail est une mémoire auxiliaire utilisable par n'importe quel client ayant accès à l'interface JNDI (Java™ Naming and Directory Interface). Dès lors qu'une zone de travail est établie, les données peuvent y être placées pour pouvoir être réutilisées au cours des appels de méthode ultérieurs ciblant à la fois les ressources locales et distantes.
Vous pouvez utiliser une zone de travail lorsqu'un grand nombre de méthodes requièrent des informations communes ou si les informations sont requises uniquement par une méthode situé à niveau bien inférieur dans le graphique d'appel. Cela évite de mettre en oeuvre des modèles de transmissions de paramètres complexes dans lesquels le nombre d'arguments transmis est trop élevé et difficile à gérer. Vous pouvez améliorer le fonctionnement de l'application en plaçant les informations dans une zone de travail et accéder ensuite à chaque méthode individuellement, évitant ainsi de transmettre ces paramètres d'une méthode à une autre. Ce dernier cas de figure évite également la transmission inutile de paramètres et améliore les performances en réduisant le coût que représentent la sérialisation et la désérialisation de ces paramètres dans l'ORB (Object Request Broker) lorsque ces derniers ne sont utilisés qu'occasionnellement dans le graphe d'appels.
Lorsque vous tentez d'optimiser les performances par le biais d'une zone de travail, mettez en cache la partition UserWorkArea récupérée de JNDI partout où elle fait l'objet d'un accès. Vous pouvez réduire le temps consacré à la recherche d'informations dans JNDI en les récupérant une fois pour toutes et en conservant une référence à ces informations en vue d'une utilisation ultérieure. Les recherches JNDI prennent du temps et peuvent être coûteuses en ressources.
D'autres mécanismes de mise en cache à la disposition d'une partition définie par l'utilisateur sont définis par la propriété de configuration "Sérialisation d'attribut reportée". Ce mécanisme s'efforce de minimiser le nombre d'appels de sérialisation et de désérialisation. Voir l'article sur le service de partition de zone de travail pour plus d'informations sur cet attribut de configuration.
Les paramètres de configuration maxSendSize et maxReceiveSize peuvent affecter les performances de la zone de travail. Régler ces deux paramètres à zéro (0) annule tout contrôle de la taille du contexte pouvant être envoyé dans une zone de travail. Cela peut améliorer les performances, suivant le nombre de zones de travail imbriquées qu'une application utilise. Dans les applications qui n'utilise qu'une seule zone de travail, le gain de performances risque d'être négligeable. En revanche, les applications utilisant un grand nombre de zones de travail imbriquées peuvent bénéficier d'une amélioration de leurs performances. Il faut toutefois savoir que le fait n'annuler tout contrôle de la taille du contexte rend possible l'envoi d'énormes quantités de données à un serveur.
L'utilisation de la zone de travail en tant que remplacement direct de la transmission d'un paramètre unique par le biais d'un seul appel de méthode entraîne une baisse des performances. Cette opération représente un temps système supérieur à la simple transmission du paramètre entre des appels de méthode. Bien que cette baisse de performances reste dans des limites de tolérance acceptables et se situe dans un ordre de grandeur comparable à celui observé dans le cas de la transmission de paramètres en terme de taille d'objet, considérez-la comme un problème potentiel avant d'utiliser le service. Comme avec la plupart des services fonctionnels, l'utilisation intelligente des zones de travail produit les meilleurs résultats.
Le service Work Area est un outil qui simplifie le passage d'informations d'une ressource à une autre et, dans certains cas, améliore les performances en réduisant le coût associé à une transmission de paramètres lorsque les informations ne sont que rarement "accessibles" dans le graphe d'appels. La mise en cache de l'instance extraite à partir de JNDI a une incidence importante sur l'optimisation des performances lors de l'exécution.