No announcement yet.

ORs having 100s of ship units- Bulk plan taking HUGE time (1 hr+ )

  • Filter
  • Time
  • Show
Clear All
new posts

  • ORs having 100s of ship units- Bulk plan taking HUGE time (1 hr+ )


    My clients have ORs where their ship units could run into 100s. Bulk plan takes 1 hr plus. They use Parcel Rates/LTL which are configured in OTM. I even made sure if this is the culprit but it does not seems so.

    From my side I tried to tweak Multi Threading parameters to see if there is any improvement but I dont see any. I did the following tweaks:
    - glog.workflow.topicGroup=planningCommit,6 [ increased it from 2 to 6]
    - glog.workflow.topicGroup=planningBuild,2 [ increased it from 2 to 6]
    I went to Event Diag servlet and tried increasing the 'batch' process thread but I see that OTM still makes use of only 1 Thread (i.e. it is active and rest are waiting)

    The bulk plan milestone is 'MultiStop Direct Shipments' is taking the lion's share of time. I am attaching the screen shot for reference.

    Any pointers to this would be of great help!
    Attached Files
    Last edited by vikonline; May 9th, 2014, 07:36.

  • #2
    Re: ORs having 100s of ship units- Bulk plan taking HUGE time (1 hr+ )

    Resolved! we increasing the bulk plan batch size, increased the RAM, increased multi threading of planning queues. performance of planning which was taking 1 hours 5 mins is now taking less than 18 minutes! I checked the 'Processing Time' under Event Diag servlet..which is very healthy compared to previous stuff!
    Last edited by vikonline; May 8th, 2014, 14:55.


    • #3
      Re: ORs having 100s of ship units- Bulk plan taking HUGE time (1 hr+ )

      Just for other's benefit, I am briefly posting my issue and resolution:

      Isssue: Had 50 Order Releases each having 200+ ship unit lines. Now while performing 'bulk plan' under default parameters was taking 1 hours +. I checked the Event Diagnostics Servlet. I found out the 'Process Time' was HUGE. The Topic Queue 'Batch' was taking long time.
      We tried to upgrade the server specs but still issues persisted. We tried to tweak the 'bundling' parameter logic but still the issue persisted. There were no agents which were getting fired, nor were there any other processes running at the time of bulk plan.

      There are 2 approaches we took:
      1. Increased the Topic Queue 'batch' from default value '2' to '5' in glog properties (multi threading). Split the bulk plan into 5 batches (50/5) and processed them in 5 batch queues. This brought down the time from 1 hr to 20 mins. But the flip side of this was 'consolidation' of ORs went for a toss. Now this was not acceptable as OTM was to be taken advantage of it's consolidation functionality and optimize more TLs.
      2. Second approach was to increase the threads in each of the 'functional' areas of 'each' bulk plan. For this we increased the a 'Topic Group' default thread from '2' to '6' + we reduced the minimum requirement for OTM to apply multi threading on the 'functional area' associated to this topic group from default '100' to '10'. Now this made sure OTM would bring in 'multi threading' in a single bulk plan' and give the advantage of both consolidation & performance. Also the heap size was increased after server upgrade. Entire bulk plan of 50 ORs in a single bulk plan was completed in 18 minutes!
      We finally we with the second approach and it had both the benefits.

      Now for both the approaches, care should be taken to keep server infrastructure in mind. If not, your app server might just collapse. Adopt judicious and incremental approach.

      PS: All were performed in file.
      Last edited by vikonline; May 9th, 2014, 07:28.