docs: add docs for RateLimiter

[xialeistudio]

Add a RateLimiter quickstart to docs.
#87

[mustafasegf]

hey, while this code compiles, it gives 403 error while trying because the host header isn't modified to one.one.one.one. It would be better for the example to also add

    async fn upstream_request_filter(
        &self,
        _session: &mut Session,
        upstream_request: &mut RequestHeader,
        _ctx: &mut Self::CTX,
    ) -> Result<()> {
        upstream_request.insert_header("Host", "one.one.one.one").unwrap();
        Ok(())
    }

just like in the https://github.com/cloudflare/pingora/blob/36e09ca389dac053948722a8ed24caa011495439/docs/quick_start.md

[xialeistudio]

hey, while this code compiles, it gives 403 error while trying because the host header isn't modified to one.one.one.one. It would be better for the example to also add

    async fn upstream_request_filter(
        &self,
        _session: &mut Session,
        upstream_request: &mut RequestHeader,
        _ctx: &mut Self::CTX,
    ) -> Result<()> {
        upstream_request.insert_header("Host", "one.one.one.one").unwrap();
        Ok(())
    }

just like in the https://github.com/cloudflare/pingora/blob/36e09ca389dac053948722a8ed24caa011495439/docs/quick_start.md

Thanks to your valuable reminder, I have promptly addressed the issue.

[johnhurt]

Nice. I'm marking this one as accepted. We will ingest it internally, and it should show up in our main branch (attributed correctly to you) in our next sync. Thanks!

[xialeistudio]

Nice. I'm marking this one as accepted. We will ingest it internally, and it should show up in our main branch (attributed correctly to you) in our next sync. Thanks!

Thanks!

[palant]

Please don’t modify the table in this way, the better way to implement a “get or insert” operation is:

rate_limiter_map.entry(appid.clone()).insert_or_with(|| Rate::new(Duration::from_secs(1)))

[palant]

This actually makes little sense. If you do rate limiting by app id, you can just use it as the rate limiter key – no need for an extra table with rate limiter instances per app id (rate limiter storage is more efficient than HashMap). Or you do rate limiting by IP address here.

[xialeistudio]

Nice advice, I have modified the corresponding code.
Thank you!

[palant]

Having implemented rate limiting myself now, it’s rather unlikely that anybody would need more than one rate limiter. It’s built in a way that you can count different data types with it. So you’d do for example:

let mut rate_limiter = RATE_LIMITER.lock().unwrap();
let app_requests = rate_limiter.observe(&appid, 1);
let ip_requests = rate_limiter.observe(&ip_addr, 1);
if app_requests > MAX_REQ_PER_APP || ip_requests > MAX_REQ_PER_IP { // rate limited, return 429
    …

[palant]

You don’t need both Arc and Mutex here, the latter is sufficient. A mutex only allows one reference at a time, no point counting it.

[palant]

Having implemented rate limiting myself now, it’s rather unlikely that anybody would need more than one rate limiter. It’s built in a way that you can count different data types with it. So you’d do for example:

let mut rate_limiter = RATE_LIMITER.lock().unwrap();
let app_requests = rate_limiter.observe(&appid, 1);
let ip_requests = rate_limiter.observe(&ip_addr, 1);
if app_requests > MAX_REQ_PER_APP || ip_requests > MAX_REQ_PER_IP { // rate limited, return 429
    …

[palant]

This isn’t very relevant for the docs, but I’m pretty certain that you don’t need reference counting here. LB(LoadBalancer<RoundRobin>) would be sufficient.