Op 02-04-13 17:11, roman.stumm schreef:
We are experiencing that the performance for a
vehicleRouting) starts to decrease in our app when there are 200 or more
stops on a tour, while there is only one of the CPUs doing the work. We are
using drools-planner 5.5.0-Final and we would be glad to hear of any
experiences or hints:
6.0 should be a lot faster with chained planning variables, I
fixing several performance/scalability issues there.
(at least if you use the normal moveSelectors IIRC)
or 6.0.0.Beta1 when its released (later this week hopefully).
How many stops do you want to scale too?
If it really big, like the Santa problem, where we faced 150 000 stops,
some extra tricks might be needed.
- whether a multi-thread solver would help here? Is there any
releasing this feature?
After 6.0 is out, I am going to hide in a cave and come out
Solver is multi-threaded with delta's :) (metaphorically speaking)
Mult-threading without delta's is relatively easy but much slower than
the current implementation.
Multi-threading with delta's is uncharted territory. I believe it's
possible, time will tell..
- if it would be promising when we split the problem into many
use different solver instances (one for each geo-area) or
This is called
partitioning. It's an often used technique, that works,
but not as well as a solver that can scale out.
Try upgrading to 6.0 first. Let us know how that works out.
- if we could optimize this by using other configuration tricks, such
similar for subChainSwapMoveSelector.
See VRP in 6.0.
I 'll improve the docs for these special moves by 6.0.0.Final.
Is this something that requires a multi-threaded solver in your opinion?
Thanks in advance,
View this message in context:
Sent from the Drools: User forum mailing list archive at Nabble.com
rules-users mailing list