Raise the throttling limits of the storage API.

Raise the throttling limits of the storage API.

The per-hour limit is now 1800, allowing 1 write operation every 2 seconds over
an extended period of time. To provide protection against short-term flooding,
add a new per-minute limit of 120 (2 per second).

BUG=406406
R=zea@chromium.org

Committed: https://crrev.com/f7a2e0c4baa4c8029a87b0264abfae8b16865dac
Cr-Commit-Position: refs/heads/master@{#303248}

[not at google - send to devlin, 2014-11-05 23:21:27]

Please sanity check, I picked all of these numbers semi-arbitrarily.

[Nicolas Zea, 2014-11-06 00:23:53]

I kind of think the limits should be reversed. That we want a more conservative
per-hour limit to discourage abuse, and a more generous per-minute limit, to
allow bursts.

Given that throttling isn't a permanent state anymore, I'd argue 1 per second
for the per-minute limit (60 per minute), and maybe 1 every 10 seconds for the
hour limit (360 per hour).

[not at google - send to devlin, 2014-11-06 21:49:14]

On 2014/11/06 00:23:53, Nicolas Zea wrote:
> I kind of think the limits should be reversed. That we want a more
conservative
> per-hour limit to discourage abuse, and a more generous per-minute limit, to
> allow bursts.

I think that's what I've written? Else I'm reading numbers wrong and/or
misunderstanding you.

> 
> Given that throttling isn't a permanent state anymore, I'd argue 1 per second
> for the per-minute limit (60 per minute), and maybe 1 every 10 seconds for the
> hour limit (360 per hour).

I think 1 per second is a bit strict, at least 2 per second would be reasonable
(e.g. flushing a cache once per second should work). 360 is doable, I guess I'd
prefer it to be more lenient - and to add metrics for this actually - but that
involves diving into the quota service infrastructure again :\

[Nicolas Zea, 2014-11-06 22:14:58]

On 2014/11/06 21:49:14, kalman wrote:
> On 2014/11/06 00:23:53, Nicolas Zea wrote:
> > I kind of think the limits should be reversed. That we want a more
> conservative
> > per-hour limit to discourage abuse, and a more generous per-minute limit, to
> > allow bursts.
> 
> I think that's what I've written? Else I'm reading numbers wrong and/or
> misunderstanding you.
> 
> > 
> > Given that throttling isn't a permanent state anymore, I'd argue 1 per
second
> > for the per-minute limit (60 per minute), and maybe 1 every 10 seconds for
the
> > hour limit (360 per hour).
> 
> I think 1 per second is a bit strict, at least 2 per second would be
reasonable
> (e.g. flushing a cache once per second should work). 360 is doable, I guess
I'd
> prefer it to be more lenient - and to add metrics for this actually - but that
> involves diving into the quota service infrastructure again :\

Oh oops, I misread your commit statement. You're right, the way you had it was
correct. And 2 per second in a minute sounds good as well. Maybe 1800 an hour
then? (Every 2 seconds)

[not at google - send to devlin, 2014-11-07 00:52:08]

Err, or should I say, done.

[Nicolas Zea, 2014-11-07 01:03:20]

lgtm

[not at google - send to devlin, 2014-11-07 01:09:28]

The CQ bit was checked by kalman@chromium.org

[commit-bot: I haz the power, 2014-11-07 01:11:48]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/702303002/20001

[commit-bot: I haz the power, 2014-11-07 07:13:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-11-07 07:13:12]

Exceeded time limit waiting for builds to trigger.

[not at google - send to devlin, 2014-11-07 16:24:45]

The CQ bit was checked by kalman@chromium.org

[commit-bot: I haz the power, 2014-11-07 16:25:29]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/702303002/20001

[commit-bot: I haz the power, 2014-11-07 17:18:19]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2014-11-07 17:20:02]

Patchset 2 (id:??) landed as
https://crrev.com/f7a2e0c4baa4c8029a87b0264abfae8b16865dac
Cr-Commit-Position: refs/heads/master@{#303248}