How Multi-Threading Enhances BlueYonder’s WMS Performance

If you’ve ever spent hours allocating a 40K line wave or waited restlessly looking at the hourglass for your picks to get canceled, you are not alone. One way to tackle this is to take advantage of the multi-threading capabilities that the new MOCA architecture supports in BlueYonder WMS (formerly JDA).

Good News

With the introduction of next-generation MOCA (i.e., MOCAng ), some core WMS functionalities like allocation and pick release are still implemented in legacy C code became slow. This is mainly due to MOCA now being Java-based; native C components incur overhead from communicating back and forth with MOCA processes when trying to invoke SQL or other C components. As a result, we witness a general slowdown in elements like allocation and pick release, where the majority of code is still in C. The good news is that the new Java-based architecture of MOCA supports multi-threading, and with the right approach, there is an excellent opportunity for performance enhancement.

Multi-Threading in Allocation

One area to take advantage of multi-threading is allocation. The success of this approach has led products to include the feature in its 2012 release. Basically, instead of having one single-threaded process going through all shipment lines for a wave and allocating them one by one, we split these lines into multiple temporary waves, so each is processed by a separate thread within the MOCA server process. The key to success here is to split the wave in a manner that minimizes contention between threads. One logical way to split the lines is by part number, where we ensure that allocation threads are not competing for the same piece of inventory. At Longbow Advantage, we have witnessed impressive results with this approach. In some cases where allocation was taking over 1.5 hours to process 40K wave, we managed to reduce it to under 10 minutes.

Multi-Threading in Picks

Allocation is not the only place where multi-threading can be beneficial. Although an exception case, “Pick Cancellation,” is an activity that can be very time-consuming using the standard WMS approach. If we look at a trace of pick cancellation, we see that the standard logic serializes cancellation of picks one after the other and performs rollbacks when errors occur. A better approach would be to take advantage of the deferred execution mechanism in conjunction with multi-threading to achieve speedup.

Basically, instead of canceling the picks inline, we create deferred execution records for each cancellation and a set of background thread jobs. These threads will poll the table and look for documents to cancel. Again, the key here is to ensure that there is a minimum number of contention points between thread jobs. To control this, we can use a Key Value field within the deferred records to hash the record into threads where no two threads are trying to cancel the same set of picks. We again witnessed a remarkable improvement in performance using this approach, where we were able to cancel 40K picks in fewer than 20 minutes.

Leverage Multi-Threading

Taking advantage of the multi-threading capabilities of new MOCA architecture is by no means limited to the cases described above. We have successfully used it to improve the performance of integrator transaction processing, archiving, and much more. However, there are a couple of caveats that are worth outlining:

Contention: in general, as we increase the number of processing threads, we increase the opportunity for contention between threads. We usually need to identify the contention points and take measures to resolve them if possible. But keep in mind that the law of “diminishing returns” applies, and after a certain point adding threads will not produce any more gains.

Concurrency Issues: If concurrency issues still exist in standard WMS code, then a multi-threading approach will magnify them big time. Many threads are concurrently invoking the code that works correctly 99.95% of the time now. The likelihood of 0.05% happening becomes much higher.

Hardware Limitations: When trying to determine how many threads to use, we need to take into consideration available hardware, including the number of CPUs and memory.

Fine-tuning MOCA Parameters: Some of the parameters that we need to adjust to support multi-threading include:

• Native process pool
• Database connections
• Maximum heap size for Java virtual machine

The next generation of MOCA provides exciting opportunities to improve WMS performance and take better advantage of your hardware server capabilities. With the right approach, you can take advantage of both and increase your ROI.

By: Nima Mohajerin