You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Address review on dropping source-side aggregation
Docs: the autoscaling guide still described the removed flag, simple mode as the
default, and aggregation_function as inert. Rewrite Stage 2/3 and add an upgrade
note, since aggregation_function now always applies -- a deployment that set max
or min and never enabled the flag changes behavior -- and controller-side merging
costs more than summing pre-computed scalars.
HandleMetricReport.total_requests summed the last sample of each series, but a
handle is only dropped once its report is stale, so a queue that drained on that
final sample logged nothing: exactly the case the log exists for. Sum the
per-series peak instead, and pin it in test_common.py.
aggregate_sum, aggregate_avg, timeseries_count and _aggregate_reduce lost their
last callers along with simple mode; delete them and re-point the store tests at
the stored series. Fold _calculate_total_requests_aggregate_mode into
get_total_num_requests now that there is one mode, drop the duplicate empty check
in _get_queued_requests, drop the guard in _get_metrics_report that re-tested an
already-asserted local, and route the async-inference delay through
_record_metrics_delay so the third copy of the delay-and-tag block goes away.
_collect_handle_running_requests is the sole path under the collect-on-handle
default and scanned every running replica for every handle; iterate the report of
each handle instead, which the order-independence of the merge allows.
Give test_num_replicas_auto_basic a collect-on-replica target so its looser
upscaling assertion is reachable at all, and set
RAY_SERVE_COLLECT_AUTOSCALING_METRICS_ON_HANDLE explicitly in both metric
variants rather than inheriting the default.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: John Taylor <john.taylor@anyscale.com>
Copy file name to clipboardExpand all lines: doc/source/serve/advanced-guides/advanced-autoscaling.md
+5-23Lines changed: 5 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -125,33 +125,19 @@ Replicas and deployment handles continuously record autoscaling metrics:
125
125
126
126
Periodically, replicas and handles push their metrics to the controller:
127
127
-**Frequency**: Every 10s (configurable via `RAY_SERVE_REPLICA_AUTOSCALING_METRIC_PUSH_INTERVAL_S` and `RAY_SERVE_HANDLE_AUTOSCALING_METRIC_PUSH_INTERVAL_S`)
128
-
-**Data sent**: Both raw timeseries data and pre-aggregated metrics
129
-
-**Raw timeseries**: Data points are clipped to the [`look_back_period_s`](../api/doc/ray.serve.config.AutoscalingConfig.rst) window before sending (only recent measurements within the window are sent)
130
-
-**Pre-aggregated metrics**: A simple average computed over the [`look_back_period_s`](../api/doc/ray.serve.config.AutoscalingConfig.rst) window at the replica/handle
131
-
-**Controller usage**: The controller decides which data to use based on the `RAY_SERVE_AGGREGATE_METRICS_AT_CONTROLLER` setting (see Stage 3 below)
128
+
-**Data sent**: Raw timeseries data. Data points are clipped to the [`look_back_period_s`](../api/doc/ray.serve.config.AutoscalingConfig.rst) window before sending (only recent measurements within the window are sent)
132
129
133
130
#### Stage 3: Metric aggregation
134
131
135
-
The controller aggregates metrics to compute total ongoing requests across all replicas. Ray Serve supports two aggregation modes (controlled by `RAY_SERVE_AGGREGATE_METRICS_AT_CONTROLLER`):
-**Input**: Pre-aggregated simple averages from replicas/handles (already clipped to [`look_back_period_s`](../api/doc/ray.serve.config.AutoscalingConfig.rst))
139
-
-**Method**: Sums the pre-aggregated values from all sources. Each component computes a simple average (arithmetic mean) before sending.
140
-
-**Output**: Single value representing total ongoing requests
141
-
-**Characteristics**: Lightweight and works well for most workloads. However, because it uses simple averages rather than time-weighted averages, it can be less accurate when replicas have different metric reporting intervals or when metrics arrive at different times.
The controller aggregates the raw timeseries to compute total ongoing requests across all replicas:
144
133
-**Input**: Raw timeseries data from replicas/handles (already clipped to [`look_back_period_s`](../api/doc/ray.serve.config.AutoscalingConfig.rst))
145
134
-**Method**: Time-weighted aggregation using the [`aggregation_function`](../api/doc/ray.serve.config.AutoscalingConfig.rst) (mean, max, or min). Uses an instantaneous merge approach that treats metrics as right-continuous step functions.
146
135
-**Output**: Single value representing total ongoing requests
147
-
-**Characteristics**: Provides more mathematically accurate aggregation, especially when replicas report metrics at different intervals or you need precise time-weighted averages. The trade-off is increased controller overhead.
148
-
149
-
:::{note}
150
-
The [`aggregation_function`](../api/doc/ray.serve.config.AutoscalingConfig.rst) parameter only applies in aggregate mode. In simple mode, the aggregation is always a sum of the pre-computed simple averages.
151
-
:::
152
136
153
137
:::{note}
154
-
The long-term plan is to deprecate simple mode in favor of aggregate mode. Aggregate mode provides more accurate metrics aggregation and will become the default in a future release. Consider testing aggregate mode(`RAY_SERVE_AGGREGATE_METRICS_AT_CONTROLLER=1`) in your deployments to prepare for this transition.
138
+
Earlier releases also supported a "simple mode" that summed averages pre-computed at each replica and handle, selected by `RAY_SERVE_AGGREGATE_METRICS_AT_CONTROLLER`. That flag and that mode are removed: the controller now always aggregates raw timeseries. Two consequences if you are upgrading from a release that had the flag, where it defaulted to simple mode:
139
+
-[`aggregation_function`](../api/doc/ray.serve.config.AutoscalingConfig.rst) now always applies. Under simple mode it was ignored, so a deployment that set `max` or `min` and never enabled the flag scaled on a mean and now scales on a peak or a trough.
140
+
- Aggregating timeseries costs the controller more than summing pre-computed averages, and the cost grows with the number of replicas. Watch controller CPU on deployments with very high replica counts.
155
141
:::
156
142
157
143
#### Stage 4: Policy execution
@@ -201,10 +187,6 @@ Several environment variables control autoscaling behavior at a lower level. The
201
187
202
188
***`RAY_SERVE_MIN_HANDLE_METRICS_TIMEOUT_S`** (default: 10.0s): Minimum timeout for handle metrics collection. The system uses the maximum of this value and `2 * `[`metrics_interval_s`](../api/doc/ray.serve.config.AutoscalingConfig.rst) to determine when to drop stale handle metrics.
203
189
204
-
#### Advanced feature flags
205
-
206
-
***`RAY_SERVE_AGGREGATE_METRICS_AT_CONTROLLER`** (default: false): Enables an experimental metrics aggregation mode where the controller aggregates raw timeseries data instead of using pre-aggregated metrics. This mode provides more accurate time-weighted averages but may increase controller overhead. See Stage 3 in "How autoscaling metrics work" for details.
0 commit comments