[rules-users] [Drools Planner] Proof-of-Concept Stock-planning System

Tue Apr 10 13:00:23 EDT 2012

Thank you for all the tips. In the mean time I was able to locate the source of serious performance "killer". These 3 rules:

http://nopaste.info/3f89c43eee_nl.html

I tried to reorganize and re-optimize them at least 10 times to no avail. I'd appreciate, if anyone could suggest me how to change them to get the performance up.

Until now I have tried:
- reducing variable bindings (e.g. resource == $resource to resource == $maxLoad.resource)
- moving accumulate from constraint rules to "insert momentary load"
- joining sum for TUs and Picks in one accumulate
- and number of other less useful changes

still, if I add these rules the calculate count goes down from approx 5300 to 2000 per second which is more than a half.

Thanks and kind regards,
Reinis

On 04/06/2012 01:50 PM, Geoffrey De Smet wrote:

> I just realized that the graph only prints out values (the soft score)
> of the hard score = 0.
> Since you don't reach feasibility early on, the graph will be zero.
> Try to tmp hack it to get the graph by disabling soft constraints and
> putting the hard constraints values in the soft score.
>
> With kind regards,
> Geoffrey De Smet
>
>
> Op 06-04-12 13:46, Geoffrey De Smet schreef:
>> 32 hours, that is very long, especially if you're talking about
>> feasibility.
>> Feasibility much be attained within seconds or maybe 2 minutes.
>>
>> So either your problem is very, very constrained (unlikely)
>> or there is much room for optimization.
>>
>> Run the Benchmarker and enable the statistic BEST_SOLUTION_CHANGED.
>> Verify that you have a good graph, and not a bad graph. See this issue
>> to see the difference:
>>    https://issues.jboss.org/browse/JBRULES-3451
>>
>>
>> Op 06-04-12 13:33, drools at orbit-x.de schreef:
>>> Thank you, Geoffrey!
>>>    This is the answer I was hoping for and it confirms my
>>> understanding of this problem.
>>>    Indeed it looks like it will be a standard implementation (since it
>>> is (A) and (C)).
>>>    The reason I was willing to ask the community is that current
>>> (non-optimizied prototype solution) takes approx. 32 hours to
>>> complete. But I am pretty sure that optimized move factory, rule
>>> definitions and engine configuration will move the completion time
>>> down to expected 6 hours.
>>>    -----Original-Nachricht-----
>>>> Von: "Geoffrey De Smet"<ge0ffrey.spam at gmail.com>
>>>> An: rules-users at lists.jboss.org
>>>> Datum: 05-04-2012 11:34
>>>> Betreff: Re: [rules-users] [Drools Planner] Proof-of-Concept
>>>> Stock-planning System
>>>>
>>>> Op 03-04-12 23:10, Reinis schreef:
>>>>> Hello,
>>>>>
>>>>> I want to ask you, guys, if you could guess if it is possible or
>>>>> probable to build such a System with Drools Planner:
>>>>>
>>>>> The system shall plan the best time where the transport unit (TU)
>>>>> has to
>>>>> be input into stock system to reach set delivery deadlines,
>>>>> utilization
>>>>> of resources and load balancing of bottle necks (all expressed as
>>>>> rules).
>>>>>
>>>>> Most of things (resource capacity, route within the stock system,
>>>>> etc.)
>>>>> are given and constant facts. Actually there is only one planning
>>>>> variable - time interval of a transport unit characterizing retention
>>>>> period within a given Resource. Like this:
>>>>>
>>>>> TU#1 is in Resource #A from 11:00 till 11:30<- the optimal interval
>>>>> has
>>>>> to be planned
>>>> Is the value range something like this:
>>>> (A)
>>>> - 10:00 till 10:30
>>>> - 10:30 till 11:00
>>>> - 11:00 till 11:30
>>>> - 11:30 till 12:00
>>>> Or like this?
>>>> (B)
>>>> - 11:00 till 11:15
>>>> - 11:01 till 11:16
>>>> - 11:02 till 11:17
>>>> - 11:03 till 11:18
>>>> ...
>>>>   From reading further, I presume (A).
>>>>
>>>>> TU#1 is in Resource #B from 11:45 till 12:00<- the optimal interval
>>>>> has
>>>>> to be planned
>>>>>
>>>>> TU#1 is in Resource #C from 12:30 till 13:00<- the optimal interval
>>>>> has
>>>>> to be planned
>>>>>
>>>>> I have following problem size and constraints:
>>>>> - TUs per day: 160'000
>>>>> - Amount of resources a TU travel through: 3
>>>> Do the TU need to go through it's 3 resources in a specific order?
>>>> (C) No
>>>> (D) Yes
>>>> I presume it can not go through 2 resources at the same time.
>>>>> - Average smallest time interval: 15 Min
>>>>> - Planning period: 09:00 - 16:00 = 8 hours = 32 intervals
>>>>> - Initial planning window: 4-6 hours
>>>>> - continuous planning multiple batch execution time during the day
>>>>> after
>>>>> addition and/or retraction of number of TUs: 20 minutes
>>>> (E) This is repeated planning (see documentation manual if you haven't
>>>> already).
>>>>> So the problem size would be(?):
>>>>> (TUs * resources) ^ intervals = (160'000 * 3) ^ 32 = 6.305500958×10¹⁸¹
>>>> That's not a big search space. In some examples I 've seen 10^6800.
>>>> Of course, the search space isn't the only metric to take into account
>>>> (but I haven't found a good way to measure the other metrics,
>>>> such as how-constrained-is-the-problem, how-big-is-the-snowball-effect,
>>>> ...).
>>>>> I know there is no one answer to this question. I would like only
>>>>> to get
>>>>> your feeling on this problem. Would you take on solving this sort of
>>>>> problem with drools planner?
>>>> Definitely :)
>>>> If it's (A) and (C), it should be an easy, standard implementation.
>>>> If it's (B) and (D), then it becomes interesting :)
>>>>
>>>> The only part I expect some rough edges is (E).
>>>> I suspect you'll be asking for build-in support for "planning entity
>>>> locking" to do your continuous planning easily.
>>>>     https://issues.jboss.org/browse/JBRULES-3359
>>>> It's a PITA to do that yourself for now.
>>>>> thanks and br
>>>>> Reinis
>>>> -- 
>>>> With kind regards,
>>>> Geoffrey De Smet
>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users