Chenran Li

Thanks @nader-ziada and @vagababov ! The use case is that our system has optimal performance with the randomChoice2Policy (this is also why we want to keep activator in the request...

Thanks @nader-ziada! Yes, the lb policy is based on the hard limit. Do you think either option 1 or 2 above makes sense? We'll start to work on the PR...

> We currently have queueDepth := 10 * env.ContainerConcurrency, and container concurrency can be set on a [per revision basis](https://knative.dev/docs/serving/autoscaling/concurrency/#hard-limit). So what you're proposing would be make the 10 configurable...

> So to put it slightly differently, you're seeing better performance with the activator as load balancer (using randomChoice2Policy) than a standard Kubernetes service (which is what handles the routing...

@dprotaso could you please take a look at __Feature Request 4__ here? If it makes sense, I'll go ahead and implement it first.

@nader-ziada do you think capping the queue size at `100 * env.ContainerConcurrency` makes sense? So the proposed change is, at [this line](https://sourcegraph.com/github.com/knative/serving@f4ea3ac779621ea133a78a746525f6c6ca9947de/-/blob/cmd/queue/main.go?L326), set the queueDepth to `X` * env.ContainerConcurrency: *...

@nader-ziada @dprotaso @psschwei thanks for all the comments! Is it possible for us to get on a call with you guys? We just hope to facilitate the discussion. If you...

@nader-ziada @psschwei Thanks! We'll join the Serving & Networking WG call tomorrow morning at 9:30 PST

@dprotaso summary of our discussion in the Knative Serving Working Group meeting today: Reasons we want to make the queue-proxy queue size configurable (currently it's hard coded to be 10...