Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

via search is extremely slow #6398

Open
miklcct opened this issue Jan 17, 2025 · 3 comments
Open

via search is extremely slow #6398

miklcct opened this issue Jan 17, 2025 · 3 comments

Comments

@miklcct
Copy link
Contributor

miklcct commented Jan 17, 2025

Expected behavior

A search with one via point takes at most twice the time of the search without via point.

Observed behavior

It takes much more time compared to a search without via point.

The following query took 3 minutes and 22 seconds to run, but without the via point, it only took 9 seconds. Caching isn't an issue as I ran the query without the via point first, then with via point afterwards.

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)

Great Britain OSM + GTFS

Command line used to start OTP

Router config and graph build config JSON

Steps to reproduce the problem

  1. Plan a journey with a via point, with the following query
# This is an example query for fetching all routes of your OTP deployment.
# Click on the documentation icon on the left to read about the available types
# or use autocomplete to explore the schema.
query GtfsExampleQuery {
  planConnection(
    origin: {
      location: {
        coordinate: {
          latitude: 51.5
          longitude: 0.0
        }
      }
    }
    destination: {
      location: {
        coordinate: {
          latitude: 51.50743
          longitude: -0.12772
        }
      }
    }
    via: [
      {
      	visit: {
          stopLocationIds: ["GB:910GLNDNBDE"]
          minimumWaitTime: "PT30M"
      	}
      }
    ]
  ) {
    edges {
      node {
        start
        end
        legs {
          from {
            name
          }
          to {
            name
          }
          route {
            shortName
          }
        }
      }
    }
  }
}
@t2gran
Copy link
Member

t2gran commented Jan 22, 2025

If you query the two segments separately, what do you get?

  • From (51.5, 0.0) to "GB:910GLNDNBDE"
  • From "GB:910GLNDNBDE" to (51.50743, -0.12772)

@miklcct
Copy link
Contributor Author

miklcct commented Jan 22, 2025

They are fast, with response time just 4 and 6 seconds respectively.

@miklcct
Copy link
Contributor Author

miklcct commented Jan 22, 2025

The same problem also appears at the production Digitransit all-Finland server ( https://api.digitransit.fi/routing/v2/finland/gtfs/v1 ) - the query timed out after about 30 seconds. Without a via point, it only takes 5 seconds for results to load.

However, the response time from the Norway test server ( https://otp2debug.entur.org/otp/routers/default/index/graphql ) is normal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants