Announcement

Collapse
No announcement yet.

Shipment Planning performance - Column Generation as Multistop Consolidation algrithm

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Shipment Planning performance - Column Generation as Multistop Consolidation algrithm

    Hi All,

    Good Morning , we are facing issue during Bulk Planning of around 250 - 300 orders wherein we could see the bulk plan is getting stuck and taking too long a time during
    "BUILD MULTISTOP SHIPMENTS"--> Multistop Merge shipments logic

    We are using "Column Generation" as Consolidation Algorithm , Concurrent Savings/Seq Savings as Saving Algorithm and MULTISTOP COLGEN NUMBER OF ITERATIONS = 2

    when we plan around 30 to 40 orders it completes within 5 to 10 minutes..but moment orders go beyond 200 then it gets stuck while running the "Saving Algorithm" during the Multistop Merge logic

    Thread settings for BATCH event queue = 5 ,
    PlanningBuild event queue number of threads = 10

    glog.workflow.task.group.SavingsAlgorithm= planningBuild
    glog.workflow.task.desiredBatchSize.SavingsAlgorit hm = QUEUE
    glog.workflow.task.minimumBatchSize.SavingsAlgorit hm=50
    glog.workflow.task.parallelThreshold.SavingsAlgori thm=2

    For given set of orders how do we know the total number of tasks which would be processing ...then only we could as to many batches it could have to process internally..

    Is there a way we could improve bulk plan performance when using MULTISTOP CONSOLIDATION ALGORITHM = Column Generation..

    any suggestions would be really very helpfull as we are stuck with this issue and critical as well..

    with kind regards
    Sachin

  • #2
    Hi Sachine,

    What is your OTM version?
    Are you getting any error or exception on Bulk Plan Performance Tab? If yes what is it?
    Thank You,
    cshah8

    Oracle Certified OTM 6 Implementation Specialist
    ------------------------------------------------------------------
    If my post was useful please click Thanks!

    Comment


    • #3
      Hello Sir,

      Thanks for replying back , we are at 6.4.1 Cloud version.

      No we are not getting any errors basically it gets stuck during the MultStop Merge/Consolidation phase when we see the Performance tab and finally after running for 2.5 hrs or so we have to terminate the bulk plan.

      with more number of orders more than 200 it seems it is becoming very very slow when running the Savings Algorithm logic.

      we actually need to bulk plan around 1000 orders in one bulk plan run ( thats the target we are trying to achieve )

      are there any Threads to be tweaked or Properties to be altered or set as we need to make this bulk plan run happen but we are really stuck with this..

      kindly please help ..

      Comment


      • #4
        Hi Sachin,

        1. Bulk Plan performance issues are tricky to resolve. However, you can go thru series of checks provided on Oracle Support to improve bulk plan performance.
        2. Multithreading is also very critical topic, by over doing multi threading you can hurt performance. Work with your DBA along with document on Oracle Support for multi-threading to fine tune Bulk plan performance.
        3. Finally, coming back to use of Column Generation algorithm. Algorithms are very sensitive topic and needs to be thoroughly reviewed before implementing. I would recommend to go thru help document to evaluate what other planning parameters/logic config contributing to the performance and behavior of that same algorithm. You need to start playing with samller subset to achieve desired result and then volume test it. As algorithm can generate large number of pairs during planning process you do want to trade off optimization over performance.

        We are on 6.3.1 so can not speak to performance within 6.4.1, however if nothing works out from above suggested you may have to create SR with oracle to work on same.

        Good Luck.
        Thank You,
        cshah8

        Oracle Certified OTM 6 Implementation Specialist
        ------------------------------------------------------------------
        If my post was useful please click Thanks!

        Comment


        • #5
          Column Generation algorithm - Very resource intensive, The bulk plan will take longer to run since it's computing many other possibilities as Chirag mentioned. You have to answer these questions.
          1. Do you need fast running plan?
          2. Do you need best cost plan/cheapest/efficient plan?

          I had luck with just using Single container MIP. Those 6 -7 algorithms are robust.The only way is to run an iterative test to see the results of the planning. Bulk plan optimisation is very tricky and sensitive, I would suggest getting help from a consultant.
          Thanks,
          Vinoth Gopalakrishnan
          http://www.vinoth.co/
          Reach out for OTM/GTM - Transportation/Logistics and Blockchain Consultations/Strategy

          Comment


          • #6
            Hi Chirag and Vinoth


            Thanks for your inputs surely would consider your points and try again..

            with concurrent savings we don't get proper consolidation when we go for Col generation the performance becomes bad.

            With cloud environment the other major problem is that other than looking at the Threads and Bulk Plan Performance tab there is no other way to figure out what it does...that's the worst part

            we surely know that during Multi stop merge it is getting stuck

            Nonetheless would try again..

            with kind regards
            Sachin

            Comment


            • #7
              Hello Yes even am facing same issue in 6.4.2 Cloud, till 100/200 orders good but when taken 1000 orders with 2 source and 400 destinations , we do are getting performance issue , any suggestions and experience is most welcome to support on the same.

              Comment


              • #8
                Guys- What ever OTM ships with is optimal and if you would need more consolidation you might have to tweak up a bit.
                And you have to let the customer know If they need Performance Vs Consolidation, if they need both, i suggest you to scale up the system/CPU and then tweak the parameter again. It's really fine tuning per customers need. It's not do this and it will do this sort of thing.
                Hope that helps a bit.

                Thanks
                Thanks,
                Vinoth Gopalakrishnan
                http://www.vinoth.co/
                Reach out for OTM/GTM - Transportation/Logistics and Blockchain Consultations/Strategy

                Comment

                Working...
                X