From 2534c2683dca252aa31ffb2f417d3097357e1d8e Mon Sep 17 00:00:00 2001 From: Arne Setzer Date: Thu, 9 Nov 2023 23:47:53 +0100 Subject: [PATCH] Add a note for parallelisation (#85) Co-authored-by: arnsetzer <25772747+arnesetzer@users.noreply.github.com> --- docs/notes/performance-optimisation.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/notes/performance-optimisation.md b/docs/notes/performance-optimisation.md index 537915f..30efce9 100644 --- a/docs/notes/performance-optimisation.md +++ b/docs/notes/performance-optimisation.md @@ -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