Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Interest check: Peak EWMA (latency-aware P2C) LB policy

Offen
  • Stimmt etwas nicht?
#13,092 2 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@markdroth arbeitet bereits daran.

Seit 13.10.2026.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
grpc, java
Bereich
backend-api-design

Rechercherichtung

The issue proposes a new load-balancing policy and asks for team direction before a gRFC or implementation; it names no target files or tests. First read the A48 least_request and A61 endpoint-level pick_first precedents, then resolve the open questions about all-language support, Envoy xDS mapping, and unary-only measurements with the team. Done would require an agreed scope before implementation begins.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

enhancement Type: Feature
Is your feature request related to a problem?

None of the built-in policies route by observed latency. A backend that is slow but not failing
(GC pauses, a noisy neighbour, CPU throttling, a cold cache) keeps a full share of traffic, and
tail latency goes up for every caller:

  • round_robin and pick_first ignore backend performance.
  • least_request_experimental balances outstanding requests only, so it can't tell a slow backend
    from a busy one.
  • weighted_round_robin needs servers to report ORCA load, which many deployments don't.
  • outlier_detection reacts to failures, not slowness.
Describe the solution you'd like

A peak_ewma_experimental policy, using the algorithm from Finagle and Linkerd/tower that Envoy
now ships as a contrib load balancer
(envoy.extensions.load_balancing_policies.peak_ewma.v3alpha.PeakEwma):

  • Per endpoint, keep a "peak" EWMA of client-observed RTT. It jumps up immediately on a slow
    response and decays over a configurable time, including while the endpoint isn't being picked,
    so it gets probed again and can recover.
  • cost = peak_rtt × (outstanding_requests + 1)
  • Per pick, sample choiceCount (default 2) READY endpoints and take the cheapest.

It would be structured like least_request (endpoint-level pick_first children, A61), with no
ejection of its own; users who want ejection wrap it in outlier_detection. Config is three
fields: choiceCount, decayTime, defaultRtt. It needs nothing from the server.

I'd write the gRFC and the Java implementation, following the A48 (least_request) precedent.

Describe alternatives you've considered
  • least_request + outlier_detection: good for failures, but a uniformly slower backend
    isn't failing, so it keeps a large share (numbers below).
  • weighted_round_robin with ORCA: more accurate where it's available, but it needs server
    cooperation. It doesn't help with third-party or legacy servers.
  • Keeping it as an external library: this is what I do today
    (https://github.com/ParkerHarrelson/grpc-peak-ewma-lb). It works, but latency-aware balancing is
    a common need, and a built-in policy would be usable from service config and xDS without an
    extra dependency.
  • Extending least_request with a latency mode: possible, but the cost function differs, and a
    separate policy maps cleanly onto Envoy's separate extension.
Additional context

I load-tested my standalone implementation against round_robin and
outlier_detection_experimental(least_request_experimental): 20 backends, one JVM per pod, real
gRPC over TCP, on a single machine (not yet a real cluster):

scenario p99 peak_ewma p99 least_request + outlier_detection p99 round_robin
steady, uneven fleet (noisy, GC-pausing, throttled pods) 26.9 ms 76.0 ms 93.8 ms
4 pods 2× slower (shared-node CPU contention) 23.6 ms 314 ms 488 ms
one pod 5× slower for 40 s 21.5 ms 21.5 ms 450 ms
identical pods 21.3 ms 21.3 ms 21.3 ms

Client CPU per RPC was within noise of round_robin at 10 and 50 backends. The tested
implementation is a superset of what's proposed here (it adds per-method scoring and adaptive
decay); I'd re-run the tests with the minimal policy for the gRFC.

Before I write the gRFC:

  1. Would the team consider this as an all-languages gRFC?
  2. Should it map to Envoy's peak_ewma proto via A52, even though that proto is contrib/v3alpha?
    Or should it start as service-config only?
  3. Is it acceptable to count only unary RPCs as RTT samples and outstanding load? A long-lived
    stream's duration isn't a latency. My concern is that other languages may not expose the method
    type at pick time.
Vorherrschende Sprache
Java
Sterne
12.1k
Forks
4k
Ø Merge
2 T. 1 Std.
Gemergte PRs (30 T.)
48

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus grpc/grpc-java

Alle Issues in grpc/grpc-java

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.