Dima calculation with multiple xTour workers

[i.kobeissy]

Hello,

For one of our clients, we need to be able to perform calculations simultaneously, the client works as B2C, so we have a large number of delivery locations, typically each TransportOrder has a new location as its destination, we have cases with 500 TransportOrders in the same request.

So, taking this into consideration, we have requests that are taking more than 15 mins, when debugging, we noticed that most of the time is spent for the construction of the DistanceMatrix.

Our server is made up of 1 xTour server, with 4 workers, this helped us perform 4 simultaneous requests but as a downside we are facing a problem with the Dima calculation.

We noticed that all 4 instances are using the same Dima file on the disk, so when we tried to conserve the Dima (deleteAfterUsage and deleteBeforeUsage parameters set to False), and using the same Dima when planning with the same speed profiles, we had a problems such as “(Reason: Could not calculate distance table for Dima with ID 1). Engine error: Dima locked”.
So, my question is:
- Is it possible to allow several instances to use the same Dima simultaneously without having the Dima locked issue?
- If not, is there any way to multiply the Dima on the 4 workers (each worker uses its own Dima)?
- If not, what do you suggest as a solution for our problem, taking into consideration that we need to be able to have simultaneous requests and minimize the time spent to construct the Dima?


Thanks in advance
Ibrahim

[Joost]

I would suggest to give each worker it's own tenant id .

See https://xserver.ptvgroup.com/fileadmin/ ... r%7C_____4 (last paragraph).

Summary:
Add a CallerContextProperty with key = "TenantId" and value ="<unique text for the worker>" to your CallerContext.

This is a very easy way to allow for each worker to have it's own dima with a relative small change to your code.

Also, i would suggest to have a look enabling high performance routing. That should bring the calculation time of your dima down drastically (I'm estimating from 15 minutes to under a minute). See https://xserver.ptvgroup.com/fileadmin/ ... r%7C_____2 .

[i.kobeissy]

Thanks Joost for the reply,

To get the idea straight, the TenantId allows me to add a prefix to the Dima folder name?
Also, you mention that the TenantId will allow for each worker to have its own dima, how exactly can this be done? because when we send the request we call the xTour Server, it’s not up to us to decide what worker will perform the request, it’s the server that decides which request goes to which worker right ?

In this cas I don't think this will solve my problem, actually my issue is that we have multiple workers on the same xTour Server, we would like to be able to perform multiple simultaneous calls and be able to minimize the time spent in the creation of the Dima.

Any idea how this could be solved with the traditional way?
And for the HPR we will look into it thank you

Best Regards

[Bernd Welter]

Hello Ibrahim,

if you want to benefit from 4 parallel transactions at a time you need to create the 4 independent diatance matrices, correct.
As Joost mentioned you can use the tenant mechanism which simply enables you to define independent scopes which do not interfere with the other tenants on file system level. You could also use different Distance Matrix IDs instead.

You could look at the whole picture of the application:
If you want to recycle a specific tenants ID (e.g. same tenant = same driver) this mechanism is easier to implement than a more complex handling of DIma IDs (though you could also use a look-a-side table of driver->dimaID).

With a proper HPR being enabled you could also evaluate to create&destroy a dima whenever you use it (e.g. with a random TENANT ID). There are many ways to reach the target.

In the end I recommend to get in touch with your technical counterpart (Amar?) to check the best approach that ensures a stable application and a proper runtime.

Best regards,
Bernd

[i.kobeissy]

Hello Bernd,

Thanks for the follow up, the image is clear now, we'll go through the documentation of HPR and will try to implement it for our case.

Regards

[i.kobeissy]

Hello,

I'm adding this reply to share with you the results of our tests on the HPR using xRoute and xTour, below are some stats we gathered during our tests.

In summary the results are so impressive and drastically better than before

Testing Environment

• 4 worker xTour
  2 worker xLocate
  2 worker xRoute
  1 worker xMap
  64 GB RAM
  2 profiles dimaTruck and dimaCar
  During the tests we ran (15 requests xTour, 7 requests xRoute, 5 requests xMap, 4 requests xLocate)

Here are the results
- xTour without HPR (calculation time without Queuing)

xTourWithoutHPR

- xTour with HPR (calculation time without Queuing)

xTourWithHPR

- xRoute without HPR (calculation time without Queuing)

xRouteWithoutHPR

- xRoute with HPR (calculation time without Queuing)

xRouteWithHPR

- And here's a summary

summary

summary.png (8.86 KiB) Viewed 4058 times

Regards
Ibrahim