Closed Bug 1125536 Opened 11 years ago Closed 11 years ago

Add tracking to rate limiting.

Categories

(support.mozilla.org :: General, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mythmon, Assigned: mythmon)

Details

(Whiteboard: u=dev c=general p=2 s=2015.3)

I've seen mostly complaints about rate limiting, and I'm not convinced it is actually helping anyone more than it is hurting. We should modify the rate limit code to log who is getting rate limited, what they are trying to post, how often they are doing it, and any other potentially useful data. After we get this data, we can make an informed decision about what good values for the rate limits are and if we need rate limits at all.
I've been rate limited twice since January 27th. I can no longer post in the kb forums for individual Article Discussions, even though vesper added me to the trusted contributors list the first time it happened. Related discussion: https://support.mozilla.org/en-US/forums/knowledge-base-articles/711067 Locked out of the KB discussion: Frequent Contributors including with those with Admin, Reviewer & Trusted status
Let's do this.
/me does this.
Assignee: nobody → mcooper
Status: NEW → ASSIGNED
Whiteboard: u=dev c=general p= s= → u=dev c=general p= s=2015.3
Priority: -- → P3
Whiteboard: u=dev c=general p= s=2015.3 → u=dev c=general p=2 s=2015.3
PR: https://github.com/mozilla/kitsune/pull/2363 Merged in https://github.com/mozilla/kitsune/commit/557e7484f803f24d2df6cd77c4eb504ac6ed5b54 I deployed this to production now. The trusted contributors group now has permission to bypass *all* ratelimiting, instead of parts of it. If there are other groups that need this permission, we can add it to them as well.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
(In reply to Mike Cooper [:mythmon] from comment #0) > We should modify the rate limit code to log who is getting rate limited, > what they are trying to post, how often they are doing it, and any other > potentially useful data. > > After we get this data, we can make an informed decision about what good > values for the rate limits are and if we need rate limits at all. This bug is now resolved "fixed". I'm no longer being rate-limited as of yesterday but I was wondering, are those modifications still being planned?
The changes mentioned above involved consolidation of our rate-limiting code and some tracking of rate-limiting. The consolidation is likely why you stopped getting rate-limited. If the data we gather from this supports changes to how we do rate limiting, we will do that. Right now it is too early to tell.
This does not seem to be working. The consolidation appears to have been 12th Feb. Yet I was blocked on 16th Feb., so was Fred. Fred was blocked again yesterday 21st Feb. At least the tracking implemented in this bug should help to quickly resolve the blocking issue. It would appear bug1131196 is still an issue and should therefore be reopened.
You need to log in before you can comment on or make changes to this bug.