https://speakerdeck.com/summerwind/2-prioritization

Is there any progress in this issue?

No

On Mon, Jun 6, 2016 at 10:29 PM shanghuibo [email protected] wrote:

Is there any progress in this issue?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#404 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAEEEcc90-JqoPgEeT6VF9VhdjqZ4tvWks5qJNeBgaJpZM4BXgco
.

我是来看jake大神的

Dispatcher Proposal

I propose a prioritization scheme for use in processing Dispatcher’s backlog of async calls. Each call has a priority between 0.0 (lowest priority) and 1.0 (highest priority). The default priority is 0.1.

We assign each queued call a priority score using the following function:

val BASE_MILLIS = 1000

fun Call.priorityScore() = (BASE_MILLIS   timeInQueueMillis()) * priority

Suppose we enqueue 3 calls:

A enqueued at time=0, priority=1.0
B enqueued at time=100, priority=0.5
C enqueued at time=200, priority=0.0

At time 200 we compute the priorities as A=1200, B=550, C=0.
At time 1000 we compute the priorities as A=2000, B=950, C=0.

Higher priority requests “age faster” than lower-priority requests. Any request with a non-zero priority eventually has been queued long enough to be preferred over higher-priority requests. Another example:

D enqueued at time=0, priority=0.1
E enqueued at time=10,000, priority=1.0
At time 10,000 we compute the priority of D=1100 ((1000 10,000) x 0.1), and E=1000 ((1000 0) x 1.0), so D is processed before E.
But if we hadn’t checked until time 11,000, then D=1200 and E=2000 so E is preferred.

Requests of priority 0.0 are allowed to starve and are only processed if requests of higher priority are not enqueued.

Dispatcher Proposal

I propose a prioritization scheme for use in processing Dispatcher’s backlog of async calls. Each call has a priority between 0.0 (lowest priority) and 1.0 (highest priority). The default priority is 0.1.

We assign each queued call a priority score using the following function:

val BASE_MILLIS = 1000

fun Call.priorityScore() = (BASE_MILLIS   timeInQueueMillis()) * priority

Suppose we enqueue 3 calls:

A enqueued at time=0, priority=1.0
B enqueued at time=100, priority=0.5
C enqueued at time=200, priority=0.0

At time 200 we compute the priorities as A=1200, B=550, C=0.
At time 1000 we compute the priorities as A=2000, B=950, C=0.

Higher priority requests “age faster” than lower-priority requests. Any request with a non-zero priority eventually has been queued long enough to be preferred over higher-priority requests. Another example:

D enqueued at time=0, priority=0.1
E enqueued at time=10,000, priority=1.0
At time 10,000 we compute the priority of D=1100 ((1000 10,000) x 0.1), and E=1000 ((1000 0) x 1.0), so D is processed before E.
But if we hadn’t checked until time 11,000, then D=1200 and E=2000 so E is preferred.

Requests of priority 0.0 are allowed to starve and are only processed if requests of higher priority are not enqueued.

Current dispatcher has readyAsyncCalls and runningAsyncCalls. How to implement this scheme?

Is there any update on this?

As a workaround, would you accept a pr that allows the caller to optionally provide their own Dispatcher?

I'm thinking that OkHttpClient.Builder.dispatcher's type could be an interface (that Dispatcher implements), or alternatively Dispatcher could be open (although that seems kind of messy)

FAST-FORWARD MERGE Often the current branch head is an ancestor of the named commit. This is the most common case especially when invoked from git pull: you are tracking an upstream repository, you have committed no local changes, and now you want to update to a newer upstream revision. In this case, a new commit is not needed to store the combined history; instead, the HEAD (along with the index) is updated to point at the named commit, without creating an extra merge commit. This behavior can be suppressed with the --no-ff option. TRUE MERGE Except in a fast-forward merge (see above), the branches to be merged must be tied together by a merge commit that has both of them as its parents. A merged version reconciling the changes from all branches to be merged is committed, and your HEAD, index, and working tree are updated to it. It is possible to have modifications in the working tree as long as they do not overlap; the update will preserve them. When it is not obvious how to reconcile the changes, the f I don't know how to use any of this Stuff!

You could create two instances of OkHttpClient, one for high-priority calls and one for low-priority calls. We can’t make Dispatcher user-implementable; it’s too difficult internally for that.

You could create two instances of OkHttpClient, one for high-priority calls and one for low-priority calls. We can’t make Dispatcher user-implementable; it’s too difficult internally for that.

Could you expand on how that would work exactly? How would one instance of the OkHttpClient be able to "communicate" with the other one and say "my requests are higher priority than yours"? Maybe some brief example code if possible, thanks!

Is this issue still being worked on?

@fzandroid nopers! We work in the open here so there's nothing happening in OkHttp that isn't also happening in GitHub.

HTTP/2 dropped its priority scheme.
https://httpwg.org/specs/rfc9113.html#PriorityHere

What makes you say HTTP/2 priority was dropped? On the contrary, RFC 9113 says that it retains RFC 7540's priority fields in order to maintain interoperability:

frame fields and some of the mandatory handling is retained to ensure that implementations of this document remain interoperable with implementations that use the priority signaling described in RFC 7540.

And it goes on to say that priority is (still) important and encourage the use of RFC 9218:

Signaling priority information is necessary to attain good performance in many cases. Where signaling priority information is important, endpoints are encouraged to use an alternative scheme, such as the scheme described in HTTP-PRIORITY

The footnote for HTTP-PRIORITY links to RFC 9218, which seems very forward-looking:

This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing responses. These share a common format structure that is designed to provide future extensibility.

If anything, how clients communicate priority will change as HTTP/3 is adopted. But RFC 7540 support hasn't been dropped and the IETF has defined a scheme that will allow them to support priority as a feature beyond HTTP/2.

The impression I'd got was that HTTP/2 prioritisation was considered problematic, frequently not implemented by servers and clienta. And lessons learned were being applied to HTTP/3.

[Edit: I think your links have more context.]

But I don't have anything definitive on this. I could have misunderstood. Maybe https://blog.cloudflare.com/adopting-a-new-approach-to-http-prioritization/

Do we have real numbers for usage? Regardless, I don't think there is appetite and incentives to tackle this in OkHttp.

Yes

I think we want to track RFC 9113’s prioritization scheme.