Skip to content

Commit

Permalink
Add a note for parallelisation (#85)
Browse files Browse the repository at this point in the history
Co-authored-by: arnsetzer <25772747+arnesetzer@users.noreply.github.com>
  • Loading branch information
arnesetzer and arnesetzer authored Nov 9, 2023
1 parent 3d5ef96 commit 2534c26
Showing 1 changed file with 8 additions and 0 deletions.
8 changes: 8 additions & 0 deletions docs/notes/performance-optimisation.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,14 @@ Batch request are faster (per point queried) than single-point requests, and lar

Batch queries are fastest if the points are located next to each other. Sorting the locations you are querying before batching will improve performance. Ideally sort by some block-level attribute like postal code or state/county/region, or by something like `round(lat, 1), round(lon, 1)` depending on your tile size.

If the requests are very large and the server has several CPU cores, try splitting the request and sending it simultaneously. The optimum for the number of requests is slightly higher than the amount of CPU cores used by OpenTopodata.

Example: With 4 CPU cores in use, a maximum of 5-6 requests should run simultaneously.

The number of CPU cores used is displayed when OpenTopodata is started. Alternatively, it can also be determined with the following command:
```bash
docker logs elevation-service1 2>&1 | grep "CPU cores"
```


## Dataset format
Expand Down

0 comments on commit 2534c26

Please sign in to comment.