Limit the maximum number of concurrent connections

[danieljl]

Generally, the maximum number of concurrent connections shouldn't be unbounded and should be limited to some number. In actix-web, the default limit is 25k and it's configurable via actix_web::HttpServer::max_connections.

I spent some time to explore the warp's (and even a bit of hyper's) docs and code related to warp::Server, but I didn't find a way to limit the number of concurrent connections. Did I miss anything? Or warp doesn't have this feature yet?

---

Is your feature request related to a problem? Please describe. A too high number of concurrent connections can possibly degrade the performance. It is better to refuse any incoming connection, than to accept a great number of connections but to be hardly able to serve them.

Describe the solution you'd like For warp to have a configurable connection limit, or at least to provide a good default of it.

Describe alternatives you've considered I didn't find any possible solution or workaround.

Additional context N/A

[jxs]

Hi, with Tower::limit you can enforce both a limit on the concurrent number of requests and a rate limit on the number of requests the underlying service can handle over a period of time, would that help? you check an example of using Tower with warp here

[danieljl]

Oh, that should do it. Thanks!

Do you think, though, this backpressure feature of limiting the number of concurrent connections is so essential, in contrast to other Tower's middleware, such as cache, retryer, load balancer, that warp should implement it?

[seanmonstar]

Hm, fair question. I don't think it's so essential to duplicate it in warp. If anything, I think encouraging more that users look at Tower middleware is a good thing.

[danieljl]

encouraging more that users look at Tower middleware is a good thing.

I agree. Should we then add to the docs (esp. of warp::serve and warp::Server) a notice that the warp's server doesn't do any backpressure mechanism and referring to Tower's docs if a user wants to use the feature?

I previously assumed that warp must provide a backpressure mechanism, because in many cases it is essential for production deployments. I thought I was missing something, so then I explored warp's docs and code.

[jxs]

I agree. Should we then add to the docs (esp. of warp::serve and warp::Server) a notice that the warp's server doesn't do any backpressure mechanism and referring to Tower's docs if a user wants to use the feature?

that seems a nice idea, I would just rather mention them on warp docs main page and the README.md i.e:

Thanks to its `Filter` system, warp provides these out of the box:

* Path routing and parameter extraction
* Header requirements and extraction
* Query string deserialization
* JSON and Form bodies
* Multipart form data
* Static Files and Directories
* Websockets
* Access logging
* Gzip, Deflate, and Brotli compression

Since it builds on top of [hyper](https://hyper.rs), you automatically get:

- HTTP/1
- HTTP/2
- Asynchronous
- One of the fastest HTTP implementations
- Tested and **correct**

With [`Filter` to `Service`](https://docs.rs/warp/latest/warp/fn.service.html) conversion you can also use [`Tower` middlewares](https://docs.rs/tower/0.4.6/tower/#modules) and implement features like:
- Load Balancing
- Load limiting and measurement
- Rate Limiting
you can check an example of plugging `Tower` middlewares with Warp [here](https://github.com/tower-rs/tower-http/blob/master/examples/warp-key-value-store/src/main.rs) 

[benzwt]

is it possible to set limit using hyper for certain warp's CRUD endpoint only ?