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