Repository navigation
Replies: 1 comment 1 reply
|
If you are after speed you should work with the async version of the API With the async version you can have multiple requests in parallel in flight but don't expect too much parallelization. More than 5 won't show much speedup anymore. Go for multiprocessing instead to make full use of all available CPUs/RAM. |
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi all,
Thanks for the good work for providing Nominatim!
Based on the docs and on some content of #3404 I was looking for a way to get (especially reverse) geocoding faster for our use-case.
I thought that the direct DB search via nominatim-api would be quite faster than the geocoding via HTTP. And doing first tests (not optimized for parallel searches, so not expecting to be really faster), I'm surprised how slower they actually are!!!
I've also tested https://github.com/traccar/traccar-geocoder as they claim to be much faster.
I have a test file on a branch on the open source project I'm working on if you wanna check it: https://gitlab.com/prospect-energy/prospect-server/-/merge_requests/2656/diffs?commit_id=83317d276fe319079902532ce566fcfb530f93d6
The access via API appears to be more than 4x slower, on 3 servers with the same middle-size hardware. Is it really expected to behave that slow on classical parallel requests?
Here is the content simplified, HTTP requests are based on geopy to have it as close as possible to our usage:
And the output and speed are, when setting runs/loops to 20:
And to 100:
Best, Matthieu
All reactions