Introducing TrafficIncidents hits requestQueueTimeout
Posted: Fri May 12, 2023 12:18 pm
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:
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
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
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:
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
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.
(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
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
- 91 start locations
- 15 destination locations
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
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