Skip to content

Commit

Permalink
Docs tweak
Browse files Browse the repository at this point in the history
  • Loading branch information
ajnisbet committed Feb 19, 2024
1 parent 2534c26 commit d7fb819
Showing 1 changed file with 2 additions and 6 deletions.
8 changes: 2 additions & 6 deletions docs/notes/performance-optimisation.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,13 +19,9 @@ 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:
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 Open Topo Data. The number of CPU cores used is displayed when OpenTopodata is started. If you missed the log message, you can find iw with the following command:
```bash
docker logs elevation-service1 2>&1 | grep "CPU cores"
docker logs {NAME_OF_CONTAINER} 2>&1 | grep "CPU cores"
```


Expand Down

0 comments on commit d7fb819

Please sign in to comment.