|
@@ -72,4 +72,19 @@ If your {transform} must process a lot of historic data, it has high resource
|
|
|
usage initially--particularly during the first checkpoint.
|
|
|
|
|
|
For better performance, make sure that your search aggregations and queries are
|
|
|
-optimized and that your {transform} is processing only necessary data.
|
|
|
+optimized and that your {transform} is processing only necessary data. Consider
|
|
|
+whether you can apply a source query to the {transform} to reduce the scope of
|
|
|
+data it processes. Also consider whether the cluster has sufficient resources in
|
|
|
+place to support both the composite aggregation search and the indexing of its
|
|
|
+results.
|
|
|
+
|
|
|
+If you prefer to spread out the impact on your cluster (at the cost of a slower
|
|
|
+{transform}), you can throttle the rate at which it performs search and index
|
|
|
+requests. Set the `docs_per_second` limit when you <<put-transform,create>> or
|
|
|
+<<update-transform,update>> your {transform}. If you want to calculate the
|
|
|
+current rate, use the following information from the
|
|
|
+{ref}/get-transform-stats.html[get {transform} stats API]:
|
|
|
+```
|
|
|
+documents_processed / search_time_in_ms * 1000
|
|
|
+```
|
|
|
+
|