Si vous avez déjà passé des heures à allouer une vague de 40K ou attendu sans relâche à regarder le sablier pour que vos sélections soient annulées, vous n'êtes pas seul. Une façon d'y remédier est de tirer parti des capacités de multiprocessus que la nouvelle architecture MOCA prend en charge dans JDA/RedPrairie.

Avec l'introduction de la prochaine génération de MOCA (MOCAng), certaines fonctionnalités de base du SGE, comme l'allocation et la publication, qui sont encore implantées dans le code C existant, ont ralenti de manière fulgurante. Ceci est principalement dû au fait que le MOCA est maintenant basé sur Java ; les composants C natifs encourent des frais généraux pour communiquer dans les deux sens avec les processus MOCA lorsqu'ils tentent d'invoquer SQL ou d'autres composants C. En conséquence, nous assistons à un ralentissement général des composants tels que l'allocation et la libération de sélections où la majorité du code est encore en C. La bonne nouvelle est que la nouvelle architecture Java de MOCA supporte le multiprocessus, et avec la bonne approche, il existe de grandes opportunités pour améliorer les performances.

L'un des avantages du multiprocessus est l'allocation. Le succès de cette approche a conduit le produit à inclure cette fonctionnalité dans sa version 2012. Fondamentalement, au lieu d'avoir un seul processus lien passant par toutes les lignes d'expédition d'une vague et les allouant une par une, nous divisons ces lignes en plusieurs vagues temporaires, de sorte que chacune est traitée par un lien séparé dans le processus du serveur MOCA. La clé du succès ici est de diviser la vague d'une manière qui minimise les conflits entre les liens. Une façon logique de répartir les lignes est de s'assurer que les liens d'allocation ne sont pas en concurrence pour le même élément d'inventaire, en fonction de leur numéro de pièce. Nous avons été témoins de résultats impressionnants avec cette approche ; dans certains cas où l'allocation prenait plus d'une heure et demie pour traiter notre vague 40K, nous avons réussi à la réduire à moins de 10 minutes.

L'allocation n'est pas le seul endroit où le multiprocessus peut être bénéfique. Bien qu'il s'agisse d'un cas d'exception, l’annulation d’un prélèvement (« pick ») est une activité qui peut prendre beaucoup de temps en utilisant l'approche SGE standard. Si nous examinons une trace d'annulation de la sélection, nous constatons que la logique standard sérialise essentiellement l'annulation des sélections l'une après l'autre et effectue des retours en arrière lorsque des erreurs se produisent. Une meilleure approche consisterait à tirer parti du mécanisme d'exécution différée en conjonction avec le multiprocessus pour accélérer le processus.

Fondamentalement, au lieu d'annuler les sélections en ligne, nous créons des enregistrements d'exécution différée pour chaque annulation et un ensemble de commandes de lien en arrière-plan. Ces liens interrogeront la table et chercheront les enregistrements à annuler. Encore une fois, la clé ici est de s'assurer qu'il y a un nombre minimum de points de conflit entre différentes commandes de liens. Pour contrôler cela, nous pouvons utiliser un champ « Valeur clé » dans les enregistrements différés pour diviser l'enregistrement en liens où aucun lien n'essaie d'annuler le même groupe de sélections. Nous avons de nouveau constaté une amélioration remarquable des performances grâce à cette approche, où nous avons pu annuler les sélections 40K en moins de 20 minutes.

L'utilisation des capacités de multiprocessus de la nouvelle architecture MOCA n'est en aucun cas limitée aux cas décrits ci-dessus. Nous l'avons utilisé avec succès pour améliorer les performances du traitement des transactions des intégrateurs, de l'archivage et bien plus encore. Cependant, il y a quelques mises en garde qui valent la peine d'être soulignées:

Contention: en général, comme nous augmentons le nombre de liens de traitement, nous augmentons l'opportunité de conflit entre les liens. Nous avons généralement besoin d'identifier les points de contention et de prendre des mesures pour les résoudre si possible. Mais gardez à l'esprit que la loi des « rendements décroissants » s'applique et qu'après un certain point, l'ajout de liens ne donnera plus de gains.

Problèmes de concomitance: Si les problèmes de concomitance existent toujours dans le code SGE standard, alors une approche multiprocessus les amplifiera considérablement. Le code qui fonctionne correctement 99.95% du temps maintenant est invoqué simultanément par de nombreux liens, donc la probabilité que le 0.05% se produise devient beaucoup plus élevée.

Limitations matérielles: Lorsque nous essayons de déterminer le nombre de liens à utiliser, nous devons prendre en considération le matériel disponible, y compris le nombre de CPU et la mémoire.

Réglage précis des paramètres MOCA: Certains des paramètres que nous devons ajuster pour prendre en charge le multiprocessus incluent : bassin de processus natif, connexions de base de données et taille de stockage maximale pour la machine virtuelle Java.

La prochaine génération de MOCA offre des opportunités passionnantes pour améliorer les performances SGE et tirer un meilleur parti des capacités de votre serveur matériel. Avec la bonne approche, vous pouvez profiter des deux et augmenter votre retour sur investissement.

Pour découvrir d'autres moyens d'améliorer les performances de SGE JDA, téléchargez notre dossier commercial intitulé « Cinq éléments essentiels pour maximiser vos performances JDA ». Cliquez sur le lien ci-dessous pour obtenir votre guide gratuit.

Download White Paper

Continue de lire

Analyse des données de la chaîne d’approvisionnement : Nous ne le faisons pas bien – Partie 2

Alex Wakefield
mai 04, 2019

Lire la suite show link

Hébergement ou non

Kevin Light
avril 14, 2014

Lire la suite show link

Configuration de votre système SGE JDA/RedPrairie : Une astuce pour gagner du temps

Abdullah Alkeilani
janvier 15, 2014

Lire la suite show link