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

Wed Apr 11 03:50:04 EDT 2012

Op 10-04-12 19:00, Reinis schreef:
> 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
The use of "contains()" can break incremental score calculation, which 
causes the score count to go down a lot.
An alternative I sometimes do to avoid that, is to insert the elements 
of those contains list into the working memory too
and directly LHS match on those.
> 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.
Since it's higher then 1000 (for your biggest dataset I presume), I 
wouldn't worry about it too much.
If you do want to squeeze out everything and are willing put up with a 
high maintenance and less flexibility cost for that, see this blog:
   http://blog.athico.com/2012/04/plain-old-java-score-calculation-in.html

Turn on the statistic BEST_SOLUTION_CHANGED, grab the CSV file and make 
a graph of time vs your hard score.
That graph will show you if it's stuck anywhere for a long time. If that 
graph is an almost straight line, then your score calculation is too 
slow indeed.

> 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
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-- 
With kind regards,
Geoffrey De Smet