You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OpenTripPlanner should return results in a reasonable time (e.g. 15 seconds) when planning a local journey under any circumstances.
Observed behavior
OpenTripPlanner takes a few minutes to return results whenever a new set of preferences is given on a GB-wide deployment, even if the journey provided is a local journey.
Version of OTP used (exact commit hash or JAR name)
2.7.0-SNAPSHOT
Data sets in use (links to GTFS and OSM PBF files)
A GB-wide dataset containing all public transport (except planes) in the country.
Run a large deployment (our graph is 3.3 GB, with 12638369 vertices and 31311477 edges in the street graph, and 338357 stops, 114151 patterns and 179965 constrained transfers in the transit graph).
Send a journey planning request to OTP with a set of preferences which hasn't been cached in Raptor yet.
Additional information
I have identified the bottleneck to be the Raptor transfer cache. If a journey planning request does not hit the cache, it will need to go through the whole graph, and that process takes 4 minutes on our 16-core server. It leaves an entry in the server log like the following: INFO [ForkJoinPool.commonPool-worker-18] (RaptorRequestTransferCache.java:60) Adding runtime request to cache: StreetRelevantOptions{transferMode: WALK, walk: WalkPreferences{speed: 1.39, reluctance: 1.25, boardCost: $124}, street: StreetPreferences{drivingDirection: LEFT, accessEgress: AccessEgressPreferences{maxDuration: DurationForStreetMode{default:2h}}}}
I will try to profile it first, and if I can't find an improvement in this process, I will need to add another request parameter to limit the search range during journey planning requests (which is also useful to the user to avoid backtracking, e.g. prevent a Hertfordshire - Hertfordshire journey plan from taking a fast train to London and out on another fast train, which is usually the fastest way to make the journey but is much longer than the crow flies or on a sequence of local buses), which can be fed into the transfer cache generation.
The text was updated successfully, but these errors were encountered:
Expected behavior
OpenTripPlanner should return results in a reasonable time (e.g. 15 seconds) when planning a local journey under any circumstances.
Observed behavior
OpenTripPlanner takes a few minutes to return results whenever a new set of preferences is given on a GB-wide deployment, even if the journey provided is a local journey.
Version of OTP used (exact commit hash or JAR name)
2.7.0-SNAPSHOT
Data sets in use (links to GTFS and OSM PBF files)
A GB-wide dataset containing all public transport (except planes) in the country.
Command line used to start OTP
/home/aubin/jdk/bin/java -jar /home/aubin/opentripplanner/otp-shaded.jar --load --serve /home/aubin/opentripplanner
Router config and graph build config JSON
otp-config.json
build-config.json
router-config.json
Steps to reproduce the problem
Additional information
I have identified the bottleneck to be the Raptor transfer cache. If a journey planning request does not hit the cache, it will need to go through the whole graph, and that process takes 4 minutes on our 16-core server. It leaves an entry in the server log like the following:
INFO [ForkJoinPool.commonPool-worker-18] (RaptorRequestTransferCache.java:60) Adding runtime request to cache: StreetRelevantOptions{transferMode: WALK, walk: WalkPreferences{speed: 1.39, reluctance: 1.25, boardCost: $124}, street: StreetPreferences{drivingDirection: LEFT, accessEgress: AccessEgressPreferences{maxDuration: DurationForStreetMode{default:2h}}}}
I will try to profile it first, and if I can't find an improvement in this process, I will need to add another request parameter to limit the search range during journey planning requests (which is also useful to the user to avoid backtracking, e.g. prevent a Hertfordshire - Hertfordshire journey plan from taking a fast train to London and out on another fast train, which is usually the fastest way to make the journey but is much longer than the crow flies or on a sequence of local buses), which can be fed into the transfer cache generation.
The text was updated successfully, but these errors were encountered: