L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2025 !
Excellentes performances avec la jointure côté serveur
OpenEdge 12.1 a été publié en septembre 2019. Saviez-vous qu'il étend la nouvelle prise en charge de la jointure côté serveur (SSJ) introduite dans 12.0 aux requêtes dynamiques?
OpenEdge 12.0 a introduit la fonctionnalité SSJ avec l'instruction FOR. Dans OpenEdge 12.1, vous pouvez désormais utiliser la fonctionnalité SSJ avec les requêtes dynamiques FORWARD-ONLY NO-LOCK. Dans cet article, nous partageons un didacticiel pour faciliter votre capacité à implémenter.
L'optimisation des performances et de l'évolutivité d'une application étaient des priorités dans notre livraison d'OpenEdge 12. Les améliorations de la base de données en particulier se sont avérées augmenter considérablement le débit – dans certains par 3x. Le serveur de base de données multithread d'OpenEdge 12 traite simultanément les demandes des clients distants, améliorant considérablement les performances de la base de données sous charge sans nécessiter de modifications de codage d'application. Pour améliorer encore les performances, OpenEdge 12 effectue des jointures côté serveur avec des requêtes FOR-EACH qui joignent plusieurs tables. Ces requêtes sont désormais résolues sur le serveur de base de données plutôt que sur le client, et aucune modification de codage n'est requise. Par conséquent, moins d'enregistrements sont généralement renvoyés au client, ce qui accélère les performances.
La jointure côté serveur prend en charge jusqu'à 10 tables jointes dans la même base de données logique. Toute requête qui ne peut pas être résolue actuellement côté serveur continue de fonctionner comme d'habitude. Avec OpenEdge, nous avons amélioré la capacité en offrant la possibilité d'exécuter des requêtes dynamiques avec des jointures côté serveur pour améliorer les performances des requêtes ABL.
Les applications utilisant une architecture à n niveaux se connectent à la base de données via les paramètres réseau. Dans ce scénario, le client peut être un client GUI, un client TTY ou un processus d'agent dans PASOE. Dans les versions précédentes (sans SSJ), la résolution d'une jointure obligeait le serveur à envoyer des enregistrements de la table parent au client même s'ils ne correspondaient pas à la jointure.
En fin de compte, la jointure côté serveur (SSJ) le traitement améliore les performances en résolvant les requêtes sur le serveur et en réduisant les données envoyées sur le réseau. SSJ est activé par défaut et est utilisé pour résoudre les jointures qui remplissent toutes les conditions suivantes:
- Jointures dans un environnement client / serveur
- Jointures utilisant NO-LOCK avec l'instruction FOR ou la requête dynamique FORWARD-ONLY
- Jointures avec jusqu'à 10 tables sur la même base de données logique
Examinons de plus près comment cela est implémenté.
Paramètres PROSERVE
La fonctionnalité de jointure côté serveur est contrôlée par le paramètre de base de données -ssj. [19659003] Par défaut, la base de données utilise -ssj 1. L'utilisation de la jointure côté serveur peut être désactivée en spécifiant -ssj 0 comme paramètre de démarrage lors du démarrage du courtier de base de données avec PROSERVE .
Le multi La fonctionnalité de serveur fileté (MTS) doit également être activée pour que la jointure côté serveur fonctionne. MTS est également activé par défaut.
Vous pouvez utiliser –ssj 0 si vous souhaitez désactiver la fonctionnalité, par exemple, si vous analysez les gains de l'utilisation de SSJ dans votre application.
Paramètres | Serveur- Jointure latérale |
-threadedServer 1 | Activé (par défaut) |
-threadedServer 1 | Désactivé |
-threadedServer 0 | -ssj 1 est ignoré car le serveur multithread n'est pas activé. |
-threadedServer 0 |
|
Traitement des jointures côté serveur avec une instruction FOR
Le programme suivant montre une jointure utilisant l'instruction FOR. La connexion à la base de données se fait à l'aide de paramètres réseau afin que SSJ puisse être utilisé.
![Join Using For Statement "title =" Join Using For Statement "data-openoriginalimageonclick =" true "/ > </a> </strong> </p>
<p> Voici les étapes pour exécuter l'exemple de programme avec SSJ sur un système avec OpenEdge 12.1 installé: </p>
<ol>
<li> prodb sports2020 sports2020 </li>
<li> proserve sports2020 -S 20000 </li>
<li> mpro sports2020 -S 20000 -p SSJ1.p </li>
</ol>
<p> La connexion à la base de données se fait à l'aide du paramètre réseau "-S 20000". Une connexion client / serveur est établie. Le programme SSJ1.p s'exécute et affiche le temps écoulé pour le </p>
<p> Vous pouvez exécuter le programme sur la même machine ou sur une machine distante que le serveur de base de données. </p>
<p> Lorsque vous exécutez votre programme avec SSJ, les performances sont beaucoup plus rapides. (Au cas où vous auriez besoin de comparer les performances avec et sans SSJ, la section suivante fournit les étapes nécessaires pour exécuter sans SSJ.) [19659003] Vous pouvez demander: Quelle est la vitesse de la performance? Et vous pourriez simplement répondre «très rapidement». </p>
<p> <strong> Remarques: </strong></p>
<ul>
<li> Votre kilométrage peut varier. En réalité, les performances dépendent des données et de la réduction des données envoyées sur le réseau. </li>
<li> Aucune modification n'est apportée aux règles de sélection d'index lorsque vous exécutez la fonctionnalité de jointure côté serveur. </li>
<li> Si nécessaire, vous pouvez spécifier USE-INDEX pour garantir qu'un certain index est utilisé pour une résolution optimale des requêtes. </li>
</ul>
<h2> Test des performances en désactivant la jointure côté serveur </h2>
<p> Pour désactiver SSJ afin de pouvoir obtenir une comparaison des performances, procédez comme suit: [19659007] prodb sports2020 sports2020 <strong> -ssj 0 </strong> </li>
<li> proserve sports2020 -S 20000 </li>
<li> mpro sports2020 -S 20000 -p SSJ1.p </li>
</ol>
<p> La différence avec les étapes de la section précédente est que le " L'option -ssj 0 "est utilisée pour désactiver SSJ. </p>
<p> Lorsque vous testez les performances, vous souhaiterez peut-être arrêter et redémarrer le courtier de base de données afin que les améliorations de l'exécution des requêtes ne soient pas associées à la mise en cache des blocs ou des enregistrements. [19659003] Les performances lorsque vous désactivez SSJ (-ssj 0) seront </p>
<h2> Exemple de code utilisant des requêtes dynamiques FORWARD-ONLY </h2>
<p> <a href=](https://i0.wp.com/blog.arcoptimizer.com/wp-content/uploads/2020/01/excellentes-performances-avec-la-jointure-cote-serveur.png?ssl=1)
Voici les étapes pour exécuter l'exemple de programme en utilisant SSJ sur un système avec OpenEdge 12.1 installé:
- prodb sports2020 sports2020
- proserve sports2020 -S 20000
- mpro sports2020 -S 20000 -p SSJ2.p
La connexion à la base de données se fait à l'aide du paramètre réseau "-S 20000". Une connexion client / serveur est établie. Le programme SSJ2.p s'exécute et affiche le temps écoulé pour la requête.
L'exemple de programme utilise une requête dynamique FORWARD-ONLY avec NO-LOCK.
Journalisation QryInfo
Vous pouvez analyser l'exécution d'une requête à l'aide de l'option de journalisation QryInfo.
Suivez ces étapes pour exécuter l'exemple de programme sans SSJ avec la journalisation QryInfo sur une machine avec OpenEdge 12.1 installé:
- proserve sports2020 -S 20000 -ssj 0
- mpro sports2020 -S 20000 -p SSJ2.p
-clientlog client.log -logentrytypes QryInfo -logginglevel 3
Suivez ces étapes pour exécuter l'exemple de programme utilisant SSJ avec QryInfo se connectant sur une machine avec OpenEdge 12.1 installé:
- proserve sports2020 -S 20000
- mpro sports2020 -S 20000 -p SSJ2.p
-clientlog client.log -logentrytypes QryInfo -logginglevel 3
En savoir plus sur OpenEdge 12.1 Extension des jointures côté serveur aux requêtes Dymanic
Ressources
Pour plus d'informations sur les jointures côté serveur, consultez ces diapositives d'une récente présentation d'OpenEdge Development Fellow Richard Banville, «OpenEdge 12.0 Database Performance and Server-Side Joins», ou n'hésitez pas à explorer la progression Liens vers le hub d'informations ci-dessous:
Conclusion
La fonctionnalité de traitement des jointures côté serveur dans OpenEdge 12. x offre de grandes performances prêtes à l'emploi.
Voici certaines des choses que nous avons appris:
- SSJ est activé par défaut.
- SSJ est disponible avec l'instruction FOR et les requêtes dynamiques FORWARD-ONLY, NO-LOCK.
- Les gains de performances réels dépendent des données interrogées et de la réduction de les enregistrements envoyés sur le réseau.
- L'option de journalisation QryInfo peut être utilisée pour analyser l'exécution des requêtes.
Avez-vous constaté l'amélioration des performances de SSJ dans votre application?
Combien de performances avez-vous gagnées? 2x, 3x? Veuillez nous le faire savoir dans les commentaires.
Restez à l'écoute. D'autres améliorations de SSJ sont à venir. Et si vous n'avez pas encore OpenEdge 12.1 et que vous souhaitez tester vous-même les fonctionnalités, vous pouvez commencer un essai gratuit aujourd'hui.
Merci d'avoir lu.
Source link