Comment le multi-threading améliore les performances WMS de BlueYonder

Si vous avez déjà passé des heures à allouer une onde de ligne de 40 000 ou à attendre sans relâche à regarder le sablier pour que vos choix soient annulés, vous n’êtes pas seul. Une façon de résoudre ce problème consiste à tirer parti des capacités multi-threading prises en charge par la nouvelle architecture MOCA dans BlueYonder WMS (anciennement JDA).

Bonnes nouvelles

Avec l’introduction du MOCA de nouvelle génération (c’est-à-dire MOCAng ), certaines fonctionnalités WMS de base telles que l’allocation et la publication de sélection sont toujours implémentées dans le code C hérité qui est devenu lent. Cela est principalement dû au fait que MOCA est désormais basé sur Java ; les composants C natifs subissent une surcharge de communication avec les processus MOCA lors de la tentative d’invocation de SQL ou d’autres composants C. En conséquence, nous assistons à un ralentissement général d’éléments tels que l’allocation et la publication de sélection, où la majorité du code est toujours en C. La bonne nouvelle est que la nouvelle architecture basée sur Java de MOCA prend en charge le multi-threading, et avec la bonne approche. , il existe une excellente opportunité d’amélioration des performances.

Multi-threading dans l’allocation

Un domaine pour tirer parti du multi-threading est l’allocation. Le succès de cette approche a conduit les produits à inclure cette fonctionnalité dans sa version 2012. Fondamentalement, au lieu d’avoir un processus monothread passant par toutes les lignes d’expédition pour une vague et de les allouer une par une, nous divisons ces lignes en plusieurs vagues temporaires, de sorte que chacune est traitée par un thread distinct au sein du processus serveur MOCA. La clé du succès ici est de diviser la vague d’une manière qui minimise les conflits entre les threads. Une façon logique de diviser les lignes est par numéro de pièce, où nous nous assurons que les threads d’allocation ne sont pas en concurrence pour le même morceau d’inventaire. Chez Longbow Advantage, 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 l’onde 40K, nous avons réussi à la réduire à moins de 10 minutes.

Multi-threading dans les choix

L’allocation n’est pas le seul endroit où le multi-threading peut être bénéfique. Bien qu’il s’agisse d’un cas d’exception, « Pick Cancellation » est une activité qui peut prendre beaucoup de temps avec l’approche WMS standard. Si nous regardons une trace d’annulation de sélection, nous voyons que la logique standard sérialise l’annulation des sélections les unes après les autres et effectue des annulations lorsque des erreurs se produisent. Une meilleure approche serait de tirer parti du mécanisme d’exécution différée en conjonction avec le multi-threading pour obtenir une accélération.

Fondamentalement, au lieu d’annuler les sélections en ligne, nous créons des enregistrements d’exécution différés pour chaque annulation et un ensemble de tâches de thread d’arrière-plan. Ces threads interrogeront la table et rechercheront les documents à annuler. Encore une fois, la clé ici est de s’assurer qu’il existe un nombre minimum de points de conflit entre les tâches de thread. Pour contrôler cela, nous pouvons utiliser un champ Key Value dans les enregistrements différés pour hacher l’enregistrement dans des threads où deux threads n’essayent pas d’annuler le même ensemble de sélections. Nous avons de nouveau assisté à une amélioration remarquable des performances en utilisant cette approche, où nous avons pu annuler 40 000 sélections en moins de 20 minutes.

Tirez parti du multi-threading

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

Conflit : en général, à mesure que nous augmentons le nombre de threads de traitement, nous augmentons le risque de conflit entre les threads. Nous devons généralement identifier les points litigieux et prendre des mesures pour les résoudre si possible. Mais gardez à l’esprit que la loi des « rendements décroissants » s’applique, et après un certain point, l’ajout de threads ne produira plus de gains.

Problèmes de simultanéité : Si des problèmes de simultanéité existent toujours dans le code WMS standard, une approche multithread les amplifiera considérablement. De nombreux threads appellent simultanément le code qui fonctionne correctement 99,95% du temps maintenant. La probabilité que 0,05 % se produise devient beaucoup plus élevée.

Limitations matérielles : lorsque nous essayons de déterminer le nombre de threads à utiliser, nous devons prendre en compte le matériel disponible, y compris le nombre de processeurs et de mémoire.

Réglage fin des paramètres MOCA : Certains des paramètres que nous devons ajuster pour prendre en charge le multi-threading incluent :

• Pool de processus natif
• Connexions à la base de données
• Taille de segment de mémoire maximale pour la machine virtuelle Java

La prochaine génération de MOCA offre des opportunités intéressantes pour améliorer les performances WMS et tirer le 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.