Introducing TrafficIncidents hits requestQueueTimeout

[sulcji]

Hello,
we are going to fulfill customers request and introducing TrafficIncidents feature layer to DIMA calculations.
We are using relatively geograficaly close set of < 100 locations.

Typically when TrafficIncidents are used we observe about 20-25% increase of calculation times.
But in some cases (10% of customer DIMAs) we observer huge increase of calculation time (like in example below from 7 -> 60 seconds).
The increase caused even timeouts with requestQueueTimeout=60 in xserver.conf resulting in end of DIMA calculation with xServer logging:

Code: Select all

com.ptvgroup.xserver.runtime.TimeoutWatchdog
com.ptvgroup.xserver.exceptions.ProcessingFault;The calculation of the createDistanceMatrixRequest has been cancelled.

and not calculating DIMA at all.
(full logs are attached in xserver_logs - request is executed at 8:16)

I was able to let the calculation finish by setting

Code: Select all

requestQueueTimeout = 60s

in xserver.conf
But since these parameter are stated as "optimal defaults" I see increasing of timeout more like fixing of result then solving the root cause.

To more closely describe situation:
We use

• xserver-2.27.0

• PTV Europe City Map Premium 2023.1T

• CurrentTrafficData from ContentUpdateService

• default profiles

The dima size was slightly reduced (on Destination size) and has:

• 91 start locations

• 15 destination locations

I will sum the changes in text form - for more clear table representation please see attached table_overview.png

The xml files mentioned can be all found in attached requests.7z

Original DIMA calc request (01_request.xml) is taking some 7 seconds. It is without TrafficIncidents and profile is CAR.
When adding TrafficIncidents (02_request.xml) we jump to 56 seconds.
When adding 1 extra location (L1.xml) to request (03_request.xml) we hit the timeout.
I found three ways how to get DIMA calc done:

• increase requestQueueTimeout above 60s - and DIMA is calculated in 58 seconds

• remove some random location (L2.xml) from request (03a_request) which drops computation below timeout - and DIMA is calculated in 53 seconds

• switch from car to pedestrian profile - and DIMA is calculated in 8 seconds

None of above I see as final solution (timeout is just workaround, removing location cannot happen, we need car routing not pedestrian)

Here I get to main two questions:
Why when introducing TrafficIncidens layer in some cases cases (such as 01_request.xml -> 02_request.xml) causes so huge increase of computation time?
How this can be avoided? Ususaly increase of time is quite small (20-25%) and Switching from car->pedestrian shows the time can drop back to no-TrafficIncidents times. I suspect there might be something in car profile what could cause this. Our DIMAs are not so huge so I expect that default requestQueueTimeout=60s should be sufficient

Thank you ahead for your support, we spend a lot of time testing/finding solution but in this case we need your expertise.


conf.7z - configuration&profiles
requests.7z - requests mentioned in text above
xserver_logs.7z - logs of timeout - see the time 8:16

[Bernd Welter]

Hi Jirji,

I replayed your requests locally and in PTV xServer Cloud.

In both environments the response times for the critical request 02 where about 5-8 seconds, so way faster than with your local environment.
Please create a regular helpdesk ticket - I may even have to consider a 1:1 session between you and your technical counterpart at PTV (which is Joost, I guess?)

Bernd

[sulcji]

Thank you for quick response - its good news, that computation time you get is not influenced by introducing the TrafficIncidents layer as in our case.
I will raise the support ticket.

And yes I (my profile) should be connected with Joost so he might be the one for 1:1 session which could probably be also efficient (and appreciated) solution of our situation.

Best regards
Jiri