Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Optimisez les performances de votre application AWS Blu Age modernisée
*Vishal Jaswani, Manish Roy et Himanshu Sah, Amazon Web Services*
## Résumé
Les applications mainframe modernisées avec AWS Blu Age nécessitent des tests d'équivalence fonctionnelle et de performance avant d'être déployées en production. Lors des tests de performance, les applications modernisées peuvent fonctionner plus lentement que les systèmes existants, en particulier dans le cadre de tâches par lots complexes. Cette disparité est due au fait que les applications mainframe sont monolithiques, alors que les applications modernes utilisent des architectures multiniveaux. Ce modèle présente des techniques d'optimisation permettant de combler ces écarts de performances pour les applications modernisées à l'aide du [refactoring automatique avec AWS](https://docs.aws.amazon.com/m2/latest/userguide/refactoring-m2.html) Blu Age.
Le modèle utilise le framework de modernisation AWS Blu Age avec Java natif et des fonctionnalités de réglage des bases de données pour identifier et résoudre les problèmes de performance. Le modèle décrit comment vous pouvez utiliser le profilage et la surveillance pour identifier les problèmes de performances avec des indicateurs tels que les temps d'exécution SQL, l'utilisation de la mémoire et I/O les modèles. Il explique ensuite comment appliquer des optimisations ciblées, notamment la restructuration des requêtes de base de données, la mise en cache et le raffinement de la logique métier.
Les améliorations apportées aux temps de traitement par lots et à l'utilisation des ressources du système vous aident à égaler les niveaux de performance du mainframe dans vos systèmes modernisés. Cette approche permet de maintenir l'équivalence fonctionnelle lors de la transition vers des architectures cloud modernes.
Pour utiliser ce modèle, configurez votre système et identifiez les points critiques de performance en suivant les instructions de la section [Epics](#optimize-performance-aws-blu-age-modernized-application-epics), puis appliquez les techniques d'optimisation décrites en détail dans la section [Architecture](#optimize-performance-aws-blu-age-modernized-application-architecture).
## Conditions préalables et limitations
**Conditions préalables**
+ Une application AWS Blu Age modernisée
+ Une [JProfiler licence](https://www.ej-technologies.com/store/jprofiler)
+ Privilèges administratifs pour installer le client de base de données et les outils de profilage
+ AWS [Certification Blu Age niveau 3](https://bluinsights.aws/certification/)
+ Compréhension de niveau intermédiaire du framework AWS Blu Age, de la structure du code généré et de la programmation Java
**Limites**
Les capacités et fonctionnalités d'optimisation suivantes ne sont pas couvertes par ce modèle :
+ Optimisation de la latence du réseau entre les niveaux d'application
+ Optimisations au niveau de l'infrastructure via les types d'instances Amazon Elastic Compute Cloud ( EC2Amazon) et optimisation du stockage
+ Tests de charge utilisateur et tests de stress simultanés
**Versions du produit**
+ JProfiler version 13.0 ou ultérieure (nous recommandons la dernière version)
+ pgAdmin version 8.14 ou ultérieure
## Architecture
Ce modèle définit un environnement de profilage pour une application AWS Blu Age à l'aide d'outils tels que JProfiler pgAdmin. Il prend en charge l'optimisation via le DAOManager SQLExecution générateur de APIs données fourni par AWS Blu Age.
Le reste de cette section fournit des informations détaillées et des exemples pour identifier les points critiques de performance et les stratégies d'optimisation pour vos applications modernisées. Les étapes décrites dans la section [Epics](#optimize-performance-aws-blu-age-modernized-application-epics) se réfèrent à ces informations pour obtenir des conseils supplémentaires.
**Identification des points critiques de performance dans les applications mainframe modernisées**
Dans les applications mainframe modernisées, les points critiques de *performance sont des* zones spécifiques du code qui entraînent des ralentissements ou des inefficiences importants. Ces points chauds sont souvent dus aux différences architecturales entre le mainframe et les applications modernisées. Pour identifier ces obstacles aux performances et optimiser les performances de votre application modernisée, vous pouvez utiliser trois techniques : la journalisation SQL, un `EXPLAIN` plan de requête et l'analyse. JProfiler
*Technique d'identification des hotspots : journalisation SQL*
Les applications Java modernes, y compris celles qui ont été modernisées à l'aide de AWS Blu Age, disposent de fonctionnalités intégrées pour enregistrer les requêtes SQL. Vous pouvez activer des enregistreurs spécifiques dans les projets AWS Blu Age pour suivre et analyser les instructions SQL exécutées par votre application. Cette technique est particulièrement utile pour identifier les modèles d'accès aux bases de données inefficaces, tels que les requêtes individuelles excessives ou les appels de base de données mal structurés, qui pourraient être optimisés par le traitement par lots ou l'affinement des requêtes.
Pour implémenter la journalisation SQL dans votre application AWS Blu Age modernisée, définissez le niveau de journalisation sur celui `DEBUG` des instructions SQL du `application.properties` fichier afin de capturer les détails de l'exécution des requêtes :
```
level.org.springframework.beans.factory.support.DefaultListableBeanFactory : WARN
level.com.netfective.bluage.gapwalk.runtime.sort.internal: WARN
level.org.springframework.jdbc.core.StatementCreatorUtils: DEBUG
level.com.netfective.bluage.gapwalk.rt.blu4iv.dao: DEBUG
level.com.fiserv.signature: DEBUG
level.com.netfective.bluage.gapwalk.database.support.central: DEBUG
level.com.netfective.bluage.gapwalk.rt.db.configuration.DatabaseConfiguration: DEBUG
level.com.netfective.bluage.gapwalk.rt.db.DatabaseInteractionLoggerUtils: DEBUG
level.com.netfective.bluage.gapwalk.database.support.AbstractDatabaseSupport: DEBUG
level.com.netfective.bluage.gapwalk.rt: DEBUG
```
Surveillez les requêtes à haute fréquence et à faible performance en utilisant les données enregistrées pour identifier les cibles d'optimisation. Concentrez-vous sur les requêtes dans le cadre des processus par lots, car ce sont généralement elles qui ont le plus grand impact sur les performances.
*Technique d'identification des hotspots : plan Query EXPLAIN*
Cette méthode utilise les fonctionnalités de planification des requêtes des systèmes de gestion de bases de données relationnelles. Vous pouvez utiliser des commandes telles que `EXPLAIN` PostgreSQL`EXPLAIN PLAN`, MySQL ou Oracle pour examiner comment votre base de données entend exécuter une requête donnée. Le résultat de ces commandes fournit des informations précieuses sur la stratégie d'exécution des requêtes, notamment sur la question de savoir si des index seront utilisés ou si des analyses complètes des tables seront effectuées. Ces informations sont essentielles pour optimiser les performances des requêtes, en particulier dans les cas où une indexation appropriée peut réduire considérablement le temps d'exécution.
Extrayez les requêtes SQL les plus répétitives des journaux de l'application et analysez le chemin d'exécution des requêtes peu performantes à l'aide de la `EXPLAIN` commande spécifique à votre base de données. Voici un exemple de base de données PostgreSQL.
Interrogation :
```
SELECT * FROM tenk1 WHERE unique1 < 100;
```
`EXPLAIN`commande :
```
EXPLAIN SELECT * FROM tenk1 where unique1 < 100;
```
Sortie :
```
Bitmap Heap Scan on tenk1 (cost=5.06..224.98 rows=100 width=244)
Recheck Cond: (unique1 < 100)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=100 width=0)
Index Cond: (unique1 < 100)
```
Vous pouvez interpréter le `EXPLAIN` résultat comme suit :
+ Lisez le `EXPLAIN` plan des opérations les plus internes aux opérations les plus externes (de bas en haut).
+ Recherchez les termes clés. Par exemple, `Seq Scan` indique une analyse complète de la table et `Index Scan` indique l'utilisation de l'index.
+ Vérifiez les valeurs des coûts : le premier chiffre est le coût de démarrage et le second le coût total.
+ Consultez la `rows` valeur du nombre estimé de lignes de sortie.
Dans cet exemple, le moteur de requête utilise un scan d'index pour trouver les lignes correspondantes, puis extrait uniquement ces lignes (`Bitmap Heap Scan`). Cela est plus efficace que la numérisation de l'ensemble du tableau, malgré le coût plus élevé de l'accès aux lignes individuelles.
Les opérations de numérisation des tables dans la sortie d'un `EXPLAIN` plan indiquent un index manquant. L'optimisation nécessite la création d'un index approprié.
*Technique d'identification des hotspots : analyse JProfiler *
JProfiler est un outil de profilage Java complet qui vous aide à résoudre les problèmes de performances en identifiant les appels de base de données lents et les appels gourmands en ressources CPU. Cet outil est particulièrement efficace pour identifier les requêtes SQL lentes et l'utilisation inefficace de la mémoire.
Exemple d'analyse pour une requête :
```
select evt. com.netfective.bluage.gapwalk.rt.blu4iv.dao.Blu4ivTableManager.queryNonTrasactional
```
La vue JProfiler Hot Spots fournit les informations suivantes :
+ Colonne **horaire**
+ Affiche la durée totale d'exécution (par exemple 329 secondes)
+ Affiche le pourcentage de la durée totale de l'application (par exemple, 58,7 %)
+ Permet d'identifier les opérations les plus chronophages
+ Colonne **Temps moyen**
+ Indique la durée par exécution (par exemple, 2 692 microsecondes)
+ Indique les performances de fonctionnement individuelles
+ Permet de détecter les opérations individuelles lentes
+ Colonne **des événements**
+ Affiche le nombre d'exécutions (par exemple, 122 387 fois)
+ Indique la fréquence de fonctionnement
+ Permet d'identifier les méthodes fréquemment utilisées
Pour les exemples de résultats :
+ Fréquence élevée : 122 387 exécutions indiquent un potentiel d'optimisation
+ Problème de performance : 2 692 microsecondes en moyenne indiquent une inefficacité
+ Impact critique : 58,7 % du temps total indique un goulot d'étranglement majeur
JProfiler peut analyser le comportement d'exécution de votre application afin de révéler les points sensibles qui pourraient ne pas être apparents lors de l'analyse de code statique ou de la journalisation SQL. Ces indicateurs vous aident à identifier les opérations à optimiser et à déterminer la stratégie d'optimisation la plus efficace. Pour plus d'informations sur JProfiler les fonctionnalités, consultez la [JProfiler documentation](https://www.ej-technologies.com/resources/jprofiler/help/doc/main/introduction.html).
Lorsque vous utilisez ces trois techniques (journalisation SQL, `EXPLAIN` plan de requête et JProfiler) en combinaison, vous pouvez obtenir une vue globale des caractéristiques de performance de votre application. En identifiant et en traitant les points critiques en matière de performances, vous pouvez combler l'écart de performance entre votre application mainframe d'origine et votre système cloud modernisé.
Après avoir identifié les points critiques de performance de votre application, vous pouvez appliquer des stratégies d'optimisation, qui sont expliquées dans la section suivante.
**Stratégies d'optimisation pour la modernisation des ordinateurs centraux**
Cette section décrit les principales stratégies d'optimisation des applications modernisées à partir de systèmes mainframe. Il se concentre sur trois stratégies : utiliser l'existant APIs, mettre en œuvre une mise en cache efficace et optimiser la logique métier.
*Stratégie d'optimisation : utilisation de l'existant APIs*
AWS Blu Age fournit plusieurs interfaces DAO puissantes APIs que vous pouvez utiliser pour optimiser les performances. Deux interfaces principales (DAOManager et SQLExecution Builder) offrent des fonctionnalités permettant d'améliorer les performances des applications.
**DAOManager**
DAOManager sert d'interface principale pour les opérations de base de données dans les applications modernisées. Il propose plusieurs méthodes pour améliorer les opérations de base de données et les performances des applications, en particulier pour les opérations simples de création, de lecture, de mise à jour et de suppression (CRUD) et le traitement par lots.
+ **Utilise SetMaxResults.** Dans l' DAOManager API, vous pouvez utiliser la **SetMaxResults**méthode pour spécifier le nombre maximum d'enregistrements à récupérer en une seule opération de base de données. Par défaut, ne DAOManager récupère que 10 enregistrements à la fois, ce qui peut entraîner plusieurs appels de base de données lors du traitement de grands ensembles de données. Utilisez cette optimisation lorsque votre application doit traiter un grand nombre d'enregistrements et qu'elle effectue actuellement plusieurs appels de base de données pour les récupérer. Cela est particulièrement utile dans les scénarios de traitement par lots dans lesquels vous effectuez une itération dans un ensemble de données volumineux. Dans l'exemple suivant, le code de gauche (avant optimisation) utilise la valeur de récupération de données par défaut de 10 enregistrements. Le code de droite (après optimisation) permet **setMaxResults**de récupérer 100 000 enregistrements à la fois.
**Note**
Choisissez avec soin des lots plus importants et vérifiez la taille de l'objet, car cette optimisation augmente l'encombrement mémoire.
+ **Remplacez SetOnGreatorOrEqual par SetOnEqual.** Cette optimisation implique de modifier la méthode que vous utilisez pour définir les conditions de récupération des enregistrements. La **SetOnGreatorOrEqual**méthode récupère les enregistrements supérieurs ou égaux à une valeur spécifiée, tandis que **SetOnEqual**seuls les enregistrements correspondant exactement à la valeur spécifiée.
À utiliser **SetOnEqual**comme illustré dans l'exemple de code suivant, lorsque vous savez que vous avez besoin de correspondances exactes et que vous utilisez actuellement la **SetOnGreatorOrEqual**méthode suivie par **readNextEqual()**. Cette optimisation réduit les récupérations inutiles de données.
+ **Utilisez les opérations d'écriture et de mise à jour par lots.** Vous pouvez utiliser des opérations par lots pour regrouper plusieurs opérations d'écriture ou de mise à jour dans une seule transaction de base de données. Cela permet de réduire le nombre d'appels de base de données et d'améliorer considérablement les performances des opérations impliquant plusieurs enregistrements.
Dans l'exemple suivant, le code de gauche exécute des opérations d'écriture en boucle, ce qui ralentit les performances de l'application. Vous pouvez optimiser ce code en utilisant une opération d'écriture par lots : à chaque itération de la `WHILE` boucle, vous ajoutez des enregistrements à un lot jusqu'à ce que la taille du lot atteigne une taille prédéterminée de 100. Vous pouvez ensuite vider le lot lorsqu'il atteint la taille de lot prédéterminée, puis vider les enregistrements restants de la base de données. Cela est particulièrement utile dans les scénarios où vous traitez de grands ensembles de données nécessitant des mises à jour.
+ **Ajoutez des index.** L'ajout d'index est une optimisation au niveau de la base de données qui peut améliorer considérablement les performances des requêtes. Un index permet à la base de données de localiser rapidement les lignes contenant une valeur de colonne spécifique sans avoir à parcourir la table dans son intégralité. Utilisez l'indexation sur les colonnes fréquemment utilisées dans les `WHERE` clauses, `JOIN` les conditions ou les `ORDER BY` instructions. Cela est particulièrement important pour les grandes tables ou lorsqu'il est crucial de récupérer rapidement des données.
**SQLExecutionConstructeur**
SQLExecutionBuilder est une API flexible que vous pouvez utiliser pour contrôler les requêtes SQL qui seront exécutées, récupérer certaines colonnes uniquement`SELECT`, en `INSERT` utilisant et utiliser des noms de tables dynamiques. Dans l'exemple suivant, SQLExecutor Builder utilise une requête personnalisée que vous définissez.
**Choisir entre DAOManager et SQLExecution Builder**
Le choix entre ces options APIs dépend de votre cas d'utilisation spécifique :
+ DAOManager À utiliser lorsque vous souhaitez que AWS Blu Age Runtime génère les requêtes SQL au lieu de les écrire vous-même.
+ Choisissez SQLExecution Builder lorsque vous devez écrire des requêtes SQL pour tirer parti des fonctionnalités spécifiques à la base de données ou pour écrire des requêtes SQL optimales.
*Stratégie d'optimisation : mise en cache*
Dans les applications modernisées, la mise en œuvre de stratégies de mise en cache efficaces peut réduire considérablement les appels de base de données et améliorer les temps de réponse. Cela permet de combler l'écart de performance entre les environnements mainframe et cloud.
Dans les applications AWS Blu Age, les implémentations de mise en cache simples utilisent des structures de données internes telles que des cartes de hachage ou des listes de tableaux. Vous n'avez donc pas à configurer une solution de mise en cache externe nécessitant une restructuration des coûts et du code. Cette approche est particulièrement efficace pour les données auxquelles on accède fréquemment mais qui changent rarement. Lorsque vous implémentez la mise en cache, tenez compte des contraintes de mémoire et des modèles de mise à jour pour garantir que les données mises en cache restent cohérentes et offrent des avantages réels en termes de performances.
La clé d'une mise en cache réussie consiste à identifier les bonnes données à mettre en cache. Dans l'exemple suivant, le code de gauche lit toujours les données de la table, tandis que le code de droite lit les données de la table lorsque la carte de hachage locale ne contient aucune valeur pour une clé donnée. `cacheMap`est un objet de carte de hachage créé dans le contexte du programme et effacé dans le cadre de la méthode de nettoyage du contexte du programme.
Mise en cache avec DAOManager :
Mise en cache avec SQLExecution Builder :
*Stratégie d'optimisation : optimisation de la logique métier*
L'optimisation de la logique métier se concentre sur la restructuration du code généré automatiquement par AWS Blu Age afin de mieux l'aligner sur les capacités de l'architecture moderne. Cela devient nécessaire lorsque le code généré conserve la même structure logique que le code mainframe existant, ce qui peut ne pas être optimal pour les systèmes modernes. L'objectif est d'améliorer les performances tout en maintenant l'équivalence fonctionnelle avec l'application d'origine.
Cette approche d'optimisation va au-delà des simples ajustements d'API et des stratégies de mise en cache. Cela implique de modifier la façon dont l'application traite les données et interagit avec la base de données. Les optimisations courantes consistent à éviter les opérations de lecture inutiles pour les mises à jour simples, à supprimer les appels de base de données redondants et à restructurer les modèles d'accès aux données afin de mieux les aligner sur l'architecture des applications modernes. Voici quelques exemples:
+ **Mettre à jour les données directement dans la base de données.**Restructurez votre logique métier en utilisant des mises à jour SQL directes au lieu de plusieurs DAOManager opérations avec des boucles. Par exemple, le code suivant (côté gauche) effectue plusieurs appels de base de données et utilise trop de mémoire. Plus précisément, il utilise plusieurs opérations de lecture et d'écriture de base de données au sein de boucles, des mises à jour individuelles au lieu du traitement par lots et la création d'objets inutiles à chaque itération.
Le code optimisé suivant (côté droit) utilise une seule opération de mise à jour Direct SQL. Plus précisément, il utilise un seul appel de base de données au lieu de plusieurs appels et ne nécessite pas de boucles car toutes les mises à jour sont traitées dans une seule instruction. Cette optimisation améliore les performances et l'utilisation des ressources, tout en réduisant la complexité. Il empêche l'injection de SQL, améliore la mise en cache du plan de requête et contribue à améliorer la sécurité.
**Note**
Utilisez toujours des requêtes paramétrées pour empêcher l'injection de code SQL et garantir une bonne gestion des transactions.
+ **Réduction des appels de base de données redondants.** Les appels de base de données redondants peuvent avoir un impact significatif sur les performances des applications, en particulier lorsqu'ils se produisent dans des boucles. Une technique d'optimisation simple mais efficace consiste à éviter de répéter plusieurs fois la même requête de base de données. La comparaison de code suivante montre comment le fait de déplacer l'appel `retrieve()` de base de données en dehors de la boucle empêche l'exécution redondante de requêtes identiques, ce qui améliore l'efficacité.
+ **Réduction des appels de base de données à l'aide de la `JOIN` clause SQL****.** Implémentez SQLExecution Builder pour minimiser les appels à la base de données. SQLExecutionBuilder permet de mieux contrôler la génération de code SQL et est particulièrement utile pour les requêtes complexes qui DAOManager ne peuvent pas être traitées efficacement. Par exemple, le code suivant utilise plusieurs DAOManager appels :
```
List employees = daoManager.readAll();
for(Employee emp : employees) {
Department dept = deptManager.readById(emp.getDeptId()); // Additional call for each employee
Project proj = projManager.readById(emp.getProjId()); // Another call for each employee
processEmployeeData(emp, dept, proj);
}
```
Le code optimisé utilise un seul appel de base de données dans SQLExecution Builder :
```
SQLExecutionBuilder builder = new SQLExecutionBuilder();
builder.append("SELECT e.*, d.name as dept_name, p.name as proj_name");
builder.append("FROM employee e");
builder.append("JOIN department d ON e.dept_id = d.id");
builder.append("JOIN project p ON e.proj_id = p.id");
builder.append("WHERE e.status = ?", "ACTIVE");
List> results = builder.execute(); // Single database call
for(Map result : results) {
processComplexData(result);
}
```
*Utilisation conjointe de stratégies d'optimisation*
Ces trois stratégies fonctionnent en synergie : APIs fournir les outils nécessaires à un accès efficace aux données, la mise en cache réduit le besoin de récupération répétée des données et l'optimisation de la logique métier garantit que ces outils APIs sont utilisés de la manière la plus efficace possible. La surveillance et le réglage réguliers de ces optimisations garantissent l'amélioration continue des performances tout en préservant la fiabilité et les fonctionnalités de l'application modernisée. La clé du succès consiste à comprendre quand et comment appliquer chaque stratégie en fonction des caractéristiques et des objectifs de performance de votre application.
## Outils
+ [JProfiler](https://www.ej-technologies.com/jprofiler)est un outil de profilage Java conçu pour les développeurs et les ingénieurs de performance. Il analyse les applications Java et aide à identifier les problèmes de performance, les fuites de mémoire et les problèmes de thread. JProfiler propose le profilage du processeur, de la mémoire et des threads ainsi que la surveillance des bases de données et des machines virtuelles Java (JVM) afin de fournir des informations sur le comportement des applications.
**Note**
Au lieu de cela JProfiler, vous pouvez utiliser [Java VisualVM](https://visualvm.github.io/). Il s'agit d'un outil open source gratuit de profilage et de surveillance des performances pour les applications Java qui permet de surveiller en temps réel l'utilisation du processeur, la consommation de mémoire, la gestion des threads et les statistiques de collecte des déchets. Java VisualVM étant un outil JDK intégré, il est plus rentable que JProfiler pour les besoins de profilage de base.
+ [pgAdmin](https://www.pgadmin.org/) est un outil d'administration et de développement open source pour PostgreSQL. Il fournit une interface graphique qui vous permet de créer, de gérer et d'utiliser des objets de base de données. Vous pouvez utiliser pgAdmin pour effectuer un large éventail de tâches, de l'écriture de requêtes SQL simples au développement de bases de données complexes. Ses fonctionnalités incluent un éditeur SQL mettant en évidence la syntaxe, un éditeur de code côté serveur, un agent de planification pour les tâches SQL, shell et batch, et la prise en charge de toutes les fonctionnalités de PostgreSQL pour les utilisateurs novices et expérimentés de PostgreSQL.
## Bonnes pratiques
Identification des points critiques en matière de performances :
+ Documentez les indicateurs de performance de base avant de commencer les optimisations.
+ Définissez des objectifs clairs d'amélioration des performances en fonction des exigences de l'entreprise.
+ Lors de l'analyse comparative, désactivez la journalisation détaillée, car elle peut affecter les performances.
+ Configurez une suite de tests de performance et exécutez-la régulièrement.
+ Utilisez la dernière version de pgAdmin. (Les anciennes versions ne prennent pas en charge le plan de `EXPLAIN` requête.)
+ Pour l'analyse comparative, détachez-le une JProfiler fois vos optimisations terminées, car cela augmente le temps de latence.
+ Pour l'analyse comparative, veillez à exécuter le serveur en mode démarrage plutôt qu'en mode débogage, car le mode de débogage augmente la latence.
Stratégies d'optimisation :
+ Configurez **SetMaxResults**les valeurs dans le `application.yaml` fichier afin de spécifier des lots de taille appropriée en fonction des spécifications de votre système.
+ Configurez **SetMaxResults**les valeurs en fonction du volume de données et des contraintes de mémoire.
+ Passez **SetOnGreatorOrEqual**à **SetOnEqual**uniquement lorsque les appels suivants le sont`.readNextEqual()`.
+ Dans les opérations d'écriture ou de mise à jour par lots, traitez le dernier lot séparément, car il est peut-être inférieur à la taille de lot configurée et risque de ne pas être pris en compte lors de l'opération d'écriture ou de mise à jour.
Mise en cache :
+ Les champs introduits pour la mise en cache`processImpl`, qui mutent à chaque exécution, doivent toujours être définis dans ce contexte. `processImpl` Les champs doivent également être effacés à l'aide de la `cleanUp()` méthode `doReset()` or.
+ Lorsque vous implémentez la mise en cache en mémoire, dimensionnez correctement le cache. Les très grands caches stockés en mémoire peuvent occuper toutes les ressources, ce qui peut affecter les performances globales de votre application.
SQLExecutionConstructeur :
+ Pour les requêtes que vous prévoyez d'utiliser dans SQLExecution Builder, utilisez des noms de clé tels que`PROGRAMNAME_STATEMENTNUMBER`.
+ Lorsque vous utilisez SQLExecution Builder, vérifiez toujours le `Sqlcod` champ. Ce champ contient une valeur qui indique si la requête a été exécutée correctement ou si elle a rencontré des erreurs.
+ Utilisez des requêtes paramétrées pour empêcher l'injection de code SQL.
Optimisation de la logique métier :
+ Maintenez l'équivalence fonctionnelle lors de la restructuration du code et exécutez des tests de régression et une comparaison de bases de données pour le sous-ensemble de programmes concerné.
+ Conservez les instantanés de profilage à des fins de comparaison.
## Épopées
### Installation JProfiler et pgAdmin
| Sous-tâche | Description | Compétences requises |
| --- | --- | --- |
| Installez et configurez JProfiler. | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/optimize-performance-aws-blu-age-modernized-application.html) | Développeur d’applications |
| Installez et configurez pgAdmin. | Au cours de cette étape, vous installez et configurez un client de base de données pour interroger votre base de données. Ce modèle utilise une base de données PostgreSQL et pgAdmin comme client de base de données. Si vous utilisez un autre moteur de base de données, suivez la documentation du client de base de données correspondant.[See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/optimize-performance-aws-blu-age-modernized-application.html) | Développeur d’applications |
### Identifiez les points chauds
| Sous-tâche | Description | Compétences requises |
| --- | --- | --- |
| Activez la journalisation des requêtes SQL dans votre application AWS Blu Age. | Activez les enregistreurs pour la journalisation des requêtes SQL dans le `application.properties` fichier de votre application AWS Blu Age, comme expliqué dans la section [Architecture](#optimize-performance-aws-blu-age-modernized-application-architecture). | Développeur d’applications |
| Générez et analysez des `EXPLAIN` plans de requêtes pour identifier les points névralgiques des performances des bases de données. | Pour plus de détails, consultez la section [Architecture](#optimize-performance-aws-blu-age-modernized-application-architecture). | Développeur d’applications |
| Créez un JProfiler instantané pour analyser un scénario de test peu performant. | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/optimize-performance-aws-blu-age-modernized-application.html) | Développeur d’applications |
| Analysez l' JProfiler instantané pour identifier les goulots d'étranglement liés aux performances. | Procédez comme suit pour analyser l' JProfiler instantané.[See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/optimize-performance-aws-blu-age-modernized-application.html)
Pour plus d'informations sur l'utilisation JProfiler, consultez la section [Architecture](#optimize-performance-aws-blu-age-modernized-application-architecture) et la [JProfiler documentation](https://www.ej-technologies.com/jprofiler/docs). | Développeur d’applications |
### Établir une base de référence
| Sous-tâche | Description | Compétences requises |
| --- | --- | --- |
| Établissez une référence de performance avant de mettre en œuvre des optimisations. | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/optimize-performance-aws-blu-age-modernized-application.html) | Développeur d’applications |
### Appliquer des stratégies d'optimisation
| Sous-tâche | Description | Compétences requises |
| --- | --- | --- |
| Optimisez les appels de lecture. | Optimisez la récupération des données à l'aide de DAOManager **SetMaxResults**cette méthode. Pour plus d'informations sur cette approche, consultez la section [Architecture](#optimize-performance-aws-blu-age-modernized-application-architecture). | Développeur d'applications, DAOManager |
| Refactorisez la logique métier pour éviter de multiples appels à la base de données. | Réduisez les appels de base de données à l'aide d'une `JOIN` clause SQL. Pour plus de détails et des exemples, voir *Optimisation de la logique métier* dans la section [Architecture](#optimize-performance-aws-blu-age-modernized-application-architecture). | Développeur d'applications, SQLExecution constructeur |
| Refactorisez le code pour utiliser la mise en cache afin de réduire la latence des appels de lecture. | Pour plus d'informations sur cette technique, voir *Mise en cache* dans la section [Architecture](#optimize-performance-aws-blu-age-modernized-application-architecture). | Développeur d’applications |
| Réécrivez du code inefficace qui utilise plusieurs DAOManager opérations pour des opérations de mise à jour simples. | Pour plus d'informations sur la mise à jour des données directement dans la base de données, voir *Optimisation de la logique métier* dans la section [Architecture](#optimize-performance-aws-blu-age-modernized-application-architecture). | Développeur d’applications |
### Stratégies d'optimisation des tests
| Sous-tâche | Description | Compétences requises |
| --- | --- | --- |
| Validez chaque modification d'optimisation de manière itérative tout en maintenant l'équivalence fonctionnelle. | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/optimize-performance-aws-blu-age-modernized-application.html)L'utilisation de mesures de référence comme référence garantit une mesure précise de l'impact de chaque optimisation tout en préservant la fiabilité du système. | Développeur d’applications |
## Résolution des problèmes
| Problème | Solution |
| --- | --- |
| Lorsque vous exécutez l'application moderne, une exception contenant l'erreur s'affiche`Query_ID not found`. | Pour résoudre ce problème :[See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/optimize-performance-aws-blu-age-modernized-application.html) |
| Vous avez ajouté des index, mais vous ne constatez aucune amélioration des performances. | Procédez comme suit pour vous assurer que le moteur de requête utilise l'index :[See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/optimize-performance-aws-blu-age-modernized-application.html) |
| Vous rencontrez une out-of-memory exception. | Vérifiez que le code libère la mémoire contenue dans la structure de données. |
| Les opérations d'écriture par lots entraînent des enregistrements manquants dans la table | Vérifiez le code pour vous assurer qu'une opération d'écriture supplémentaire est effectuée lorsque le nombre de lots n'est pas nul. |
| La journalisation SQL n'apparaît pas dans les journaux des applications. | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/optimize-performance-aws-blu-age-modernized-application.html) |
## Ressources connexes
+ [Refactorisation automatique des applications avec AWS Blu Age](https://docs.aws.amazon.com/m2/latest/userguide/refactoring-m2.html) (Guide de *AWS Mainframe Modernization l'utilisateur*)
+ [Documentation de pgAdmin](https://www.pgadmin.org/docs/)
+ [JProfiler documentation](https://www.ej-technologies.com/jprofiler/docs)