From 97914cbfd60d2eb8cc4d4870e181c32345373025 Mon Sep 17 00:00:00 2001 From: Bouke Haarsma Date: Wed, 23 Aug 2023 11:08:19 +0200 Subject: [PATCH 1/6] Correctly format example --- aspnetcore/performance/rate-limit.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/aspnetcore/performance/rate-limit.md b/aspnetcore/performance/rate-limit.md index e09b3e50b287..81ee2e6fad01 100644 --- a/aspnetcore/performance/rate-limit.md +++ b/aspnetcore/performance/rate-limit.md @@ -60,7 +60,9 @@ A sliding window algorithm: * Is similar to the fixed window limiter but adds segments per window. The window slides one segment each segment interval. The segment interval is (window time)/(segments per window). * Limits the requests for a window to `permitLimit` requests. * Each time window is divided in `n` segments per window. -* Requests taken from the expired time segment one window back (`n` segments prior to the current segment), are added to the current segment. We refer to the most expired time segment one window back as the expired segment. Consider the following table which shows a sliding window limiter with a 30-second window, 3 segments per window and a limit of 100 requests: +* Requests taken from the expired time segment one window back (`n` segments prior to the current segment), are added to the current segment. We refer to the most expired time segment one window back as the expired segment. + +Consider the following table which shows a sliding window limiter with a 30-second window, 3 segments per window and a limit of 100 requests: * The top row and first column shows the time segment. * The second row shows the remaining requests available. The remaining requests are available-requests+recycled. From 05bba1ee2eb18eefb530f23ee507767365ffbf17 Mon Sep 17 00:00:00 2001 From: Luke Latham <1622880+guardrex@users.noreply.github.com> Date: Wed, 23 Aug 2023 06:40:22 -0400 Subject: [PATCH 2/6] Updates --- aspnetcore/performance/rate-limit.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/aspnetcore/performance/rate-limit.md b/aspnetcore/performance/rate-limit.md index 81ee2e6fad01..d5c71022fede 100644 --- a/aspnetcore/performance/rate-limit.md +++ b/aspnetcore/performance/rate-limit.md @@ -62,7 +62,7 @@ A sliding window algorithm: * Each time window is divided in `n` segments per window. * Requests taken from the expired time segment one window back (`n` segments prior to the current segment), are added to the current segment. We refer to the most expired time segment one window back as the expired segment. -Consider the following table which shows a sliding window limiter with a 30-second window, 3 segments per window and a limit of 100 requests: +Consider the following table that shows a sliding window limiter with a 30-second window, three segments per window, and a limit of 100 requests: * The top row and first column shows the time segment. * The second row shows the remaining requests available. The remaining requests are available-requests+recycled. @@ -88,14 +88,14 @@ Consider the following table which shows a sliding window limiter with a 30-seco The following table shows the data in the previous graph in a different format. The **Remaining** column shows the requests available from the previous segment (The **Carry over** from the previous row). The first row shows 100 available because there's no previous segment: | Time | Available | Taken | Recycled from expired | Carry over | -| ---- | ---- | ------| ------ | ---- | -| 0 | 100 | 20 | 0 | 80 | -| 10 | 80 | 30 | 0 | 50 | -| 20 | 50 | 40 | 0 | 10 | -| 30 | 10 | 30 | 20 | 0 | -| 40 | 0 | 10 | 30 | 20 | -| 50 | 20 | 10 | 40 | 50 | -| 60 | 50 | 35 | 30 | 45 | +| :--: | :-------: | :---: | :-------------------: | :--------: | +| 0 | 100 | 20 | 0 | 80 | +| 10 | 80 | 30 | 0 | 50 | +| 20 | 50 | 40 | 0 | 10 | +| 30 | 10 | 30 | 20 | 0 | +| 40 | 0 | 10 | 30 | 20 | +| 50 | 20 | 10 | 40 | 50 | +| 60 | 50 | 35 | 30 | 45 | The following code uses the sliding window rate limiter: From 14eb32e6bd249f0ec054dbca19c2e5b6a1b8d02a Mon Sep 17 00:00:00 2001 From: Luke Latham <1622880+guardrex@users.noreply.github.com> Date: Wed, 23 Aug 2023 06:46:41 -0400 Subject: [PATCH 3/6] Updates --- aspnetcore/performance/rate-limit.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/aspnetcore/performance/rate-limit.md b/aspnetcore/performance/rate-limit.md index d5c71022fede..daf5df22a0ea 100644 --- a/aspnetcore/performance/rate-limit.md +++ b/aspnetcore/performance/rate-limit.md @@ -85,7 +85,7 @@ Consider the following table that shows a sliding window limiter with a 30-secon --> -The following table shows the data in the previous graph in a different format. The **Remaining** column shows the requests available from the previous segment (The **Carry over** from the previous row). The first row shows 100 available because there's no previous segment: +The following table shows the data in the previous graph in a different format. The **Available** column shows the requests available from the previous segment (The **Carry over** from the previous row). The first row shows 100 available because there's no previous segment. | Time | Available | Taken | Recycled from expired | Carry over | | :--: | :-------: | :---: | :-------------------: | :--------: | @@ -105,7 +105,7 @@ The following code uses the sliding window rate limiter: ### Token bucket limiter -The token bucket limiter is similar to the sliding window limiter, but rather than adding back the requests taken from the expired segment, a fixed number of tokens are added each replenishment period. The tokens added each segment can't increase the available tokens to a number higher than the token bucket limit. The following table shows a token bucket limiter with a limit of 100 tokens and a 10-second replenishment period: +The token bucket limiter is similar to the sliding window limiter, but rather than adding back the requests taken from the expired segment, a fixed number of tokens are added each replenishment period. The tokens added each segment can't increase the available tokens to a number higher than the token bucket limit. The following table shows a token bucket limiter with a limit of 100 tokens and a 10-second replenishment period. | Time | Available | Taken | Added | Carry over | | ---- | ---- | ------| ------| ---- | From feb478f9e7c7d26ef45f0117e2b30c7dc3520833 Mon Sep 17 00:00:00 2001 From: Luke Latham <1622880+guardrex@users.noreply.github.com> Date: Wed, 23 Aug 2023 06:48:44 -0400 Subject: [PATCH 4/6] Updates --- aspnetcore/performance/rate-limit.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/aspnetcore/performance/rate-limit.md b/aspnetcore/performance/rate-limit.md index daf5df22a0ea..733cb50658a4 100644 --- a/aspnetcore/performance/rate-limit.md +++ b/aspnetcore/performance/rate-limit.md @@ -108,14 +108,14 @@ The following code uses the sliding window rate limiter: The token bucket limiter is similar to the sliding window limiter, but rather than adding back the requests taken from the expired segment, a fixed number of tokens are added each replenishment period. The tokens added each segment can't increase the available tokens to a number higher than the token bucket limit. The following table shows a token bucket limiter with a limit of 100 tokens and a 10-second replenishment period. | Time | Available | Taken | Added | Carry over | -| ---- | ---- | ------| ------| ---- | -| 0 | 100 | 20 | 0 | 80 | -| 10 | 80 | 10 | 20 | 90 | -| 20 | 90 | 5 | 15 | 100 | -| 30 | 100 | 30 | 20 | 90 | -| 40 | 90 | 6 | 16 | 100 | -| 50 | 100 | 40 | 20 | 80 | -| 60 | 80 | 50 | 20 | 50 | +| :--: | :-------: | :---: | :---: | :--------: | +| 0 | 100 | 20 | 0 | 80 | +| 10 | 80 | 10 | 20 | 90 | +| 20 | 90 | 5 | 15 | 100 | +| 30 | 100 | 30 | 20 | 90 | +| 40 | 90 | 6 | 16 | 100 | +| 50 | 100 | 40 | 20 | 80 | +| 60 | 80 | 50 | 20 | 50 | The following code uses the token bucket limiter: From fb595e0270597efde22c17c53df4be2cb7ea0d60 Mon Sep 17 00:00:00 2001 From: Luke Latham <1622880+guardrex@users.noreply.github.com> Date: Wed, 23 Aug 2023 12:06:09 -0400 Subject: [PATCH 5/6] Updates --- aspnetcore/performance/rate-limit.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/aspnetcore/performance/rate-limit.md b/aspnetcore/performance/rate-limit.md index 733cb50658a4..a1b5760ec12a 100644 --- a/aspnetcore/performance/rate-limit.md +++ b/aspnetcore/performance/rate-limit.md @@ -60,12 +60,12 @@ A sliding window algorithm: * Is similar to the fixed window limiter but adds segments per window. The window slides one segment each segment interval. The segment interval is (window time)/(segments per window). * Limits the requests for a window to `permitLimit` requests. * Each time window is divided in `n` segments per window. -* Requests taken from the expired time segment one window back (`n` segments prior to the current segment), are added to the current segment. We refer to the most expired time segment one window back as the expired segment. +* Requests taken from the expired time segment one window back (`n` segments prior to the current segment) are added to the current segment. We refer to the most expired time segment one window back as the expired segment. Consider the following table that shows a sliding window limiter with a 30-second window, three segments per window, and a limit of 100 requests: * The top row and first column shows the time segment. -* The second row shows the remaining requests available. The remaining requests are available-requests+recycled. +* The second row shows the remaining requests available. The remaining requests are calculated as the available requests less the processed requests plus the recycled requests. * Requests at each time moves along the diagonal blue line. * From time 30 on, the request taken from the expired time segment are added back to the request limit, as shown in the red lines. @@ -82,10 +82,9 @@ Consider the following table that shows a sliding window limiter with a 30-secon | 40 | |**[+30]**| | | -10 | | | | 50 | | | **[+40]** | | | -10 | | | 60 | | | | **[+30]** | | | -35| - --> -The following table shows the data in the previous graph in a different format. The **Available** column shows the requests available from the previous segment (The **Carry over** from the previous row). The first row shows 100 available because there's no previous segment. +The following table shows the data in the previous graph in a different format. The **Available** column shows the requests available from the previous segment (The **Carry over** from the previous row). The first row shows 100 available requests because there's no previous segment. | Time | Available | Taken | Recycled from expired | Carry over | | :--: | :-------: | :---: | :-------------------: | :--------: | From c653d01bdc5c368ba0712cf8f35258ad63246130 Mon Sep 17 00:00:00 2001 From: Rick Anderson <3605364+Rick-Anderson@users.noreply.github.com> Date: Wed, 23 Aug 2023 13:55:45 -1000 Subject: [PATCH 6/6] Update aspnetcore/performance/rate-limit.md --- aspnetcore/performance/rate-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/aspnetcore/performance/rate-limit.md b/aspnetcore/performance/rate-limit.md index a1b5760ec12a..14f84983e684 100644 --- a/aspnetcore/performance/rate-limit.md +++ b/aspnetcore/performance/rate-limit.md @@ -65,7 +65,7 @@ A sliding window algorithm: Consider the following table that shows a sliding window limiter with a 30-second window, three segments per window, and a limit of 100 requests: * The top row and first column shows the time segment. -* The second row shows the remaining requests available. The remaining requests are calculated as the available requests less the processed requests plus the recycled requests. +* The second row shows the remaining requests available. The remaining requests are calculated as the available requests minus the processed requests plus the recycled requests. * Requests at each time moves along the diagonal blue line. * From time 30 on, the request taken from the expired time segment are added back to the request limit, as shown in the red lines.