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

Average query times? #2

Open
captainswain opened this issue Apr 12, 2019 · 2 comments
Open

Average query times? #2

captainswain opened this issue Apr 12, 2019 · 2 comments
Labels
discussion Discussion on something, not an issue to be fixed

Comments

@captainswain
Copy link

Hi there,

First off really interesting project! I couldn't find any contact information, so instead, I'm opening an issue. I was wondering what the average query time looks like for the project?

I'm borderline going to commit to running the scripts and importing the data, but before I do it I was wondering what performance I can expect.

My computer is rather slow so it would take me some time to import all the data.

thanks!

@dunkelstern
Copy link
Owner

Hi,
Sorry for the late answer, i did not see the notification.

Query times depend on the direction of the Query:

GPS-Coordinate to Address is usually < 50 ms on a "normal Laptop", I reached 1.5 ms response times on a proper DB Server (hot caches, 32 GB Ram, 1 TB SSD, 8 core Intel Xeon 4GHz)

Address line to WGS84 Coordinate depends on the address itself and if you're using the AI address qualifier. Postal can do about 10k classifications per second easily, so i would recommend using it if you have unstructured data (e.g. just a string). If the address is complete or you have a reference point which is near the searched address the response time is between 100 to 500ms, if you reach the worst case the search can be as slow as 3 to 4 seconds. (Measured on the DB server).

Be aware this project is work in progress, the coordinate to address version is used productively for a project at anfema with about 150k queries per day and i would consider it stable. The other direction: address to coordinate is currently not in use.

@dunkelstern
Copy link
Owner

So I just updated the Forward Geocoding and it's much faster (and works now)!
Be aware that version 2.0 of the geocoder has a different DB format, so if you already experimented with this you'll have to start over.

Query times:

  • Forward geocoding with structured data (no Postal qualifier): 15 - 20 ms
  • Forward geocoding with un-structured data (through Postal qualifier as webservice): 25 - 30 ms
  • Reverse geocoding: 1 - 3 ms
  • Text prediction: 3 - 6 ms

Tested on:

  • Macbook Pro 15" 2015
  • 16GB RAM,
  • Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
  • Linux with all spectre and meltdown mitigations enabled
  • PostgreSQL 9.5 and 11.0
  • Bavaria region from Geofabrik (About 3.4 GiB disk usage on the DB)

Import of the Europe/Germany/Bavaria region from Geofabrik takes about 50 minutes.

@dunkelstern dunkelstern added the discussion Discussion on something, not an issue to be fixed label Jun 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion on something, not an issue to be fixed
Projects
None yet
Development

No branches or pull requests

2 participants