Copilot commented on code in PR #13532:
URL: https://github.com/apache/apisix/pull/13532#discussion_r3395367475
##########
apisix/balancer.lua:
##########
@@ -229,7 +280,12 @@ local function pick_server(route, ctx)
end
end
- if checker then
+ local health_status
+ if checker and up_conf.type == "chash" then
+ health_status = fetch_health_status(up_conf, checker)
+ end
Review Comment:
For chash upstreams, pick_server() now calls fetch_health_status() on every
request and iterates all upstream nodes to build a fresh health_status map.
This introduces O(N) work per request (previously health filtering happened
when building the picker and was keyed off checker.status_ver), which can
become a noticeable CPU cost for large upstreams. Consider caching the computed
health_status table keyed by checker.status_ver (and upstream key/version) so
it only recomputes when the checker state changes, while still keeping the
chash ring stable.
##########
apisix/plugins/ai-proxy-multi.lua:
##########
@@ -448,8 +514,13 @@ local function pick_target(ctx, conf, ups_tab)
end
end
- local version = plugin.conf_version(conf) .. "#" ..
- get_checkers_status_ver(conf, checkers)
+ local health_status
+ local version = plugin.conf_version(conf)
+ if conf.balancer.algorithm == "chash" then
+ health_status = fetch_health_status(conf, checkers)
+ else
+ version = version .. "#" .. get_checkers_status_ver(conf, checkers)
+ end
Review Comment:
When algorithm == "chash", pick_target() computes health_status by scanning
every instance (and its resolved DNS nodes) on each request. This adds
per-request O(instances * dns_nodes) overhead compared to the previous approach
(picker rebuild keyed on health status changes), and may be costly with many
instances or frequent calls. Consider caching per-instance health results keyed
by the relevant checker status versions (or otherwise memoizing within a short
TTL) so health filtering is recomputed only when the checker state changes,
while keeping the chash ring stable.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
