How to Return Time Until Quota Resets?

[#1]

I'd like to return information about the current quota to the user via headers. I'm able to return the current limit and the remaining calls until the limit is reached, but I can't seem to find anything that lets me return when the limit will be reset. Quotas have a flow variable "ratelimit.{policy_name}.expiry.time", but this just seems to return the current time.

Is there any way for me to calculate when the quota for a particular user will be reset?

Thanks!

[anilsr]

Dear @Dan Fearing ,

Welcome to Apigee Community 🙂

"ratelimit.{policy_name}.expiry.time" doesn't return current time. It returns time in milliseconds which determines when the quota expires. I have tested same and works as expected.

As per documentation "ratelimit.{policy_name}.expiry.time" Returns the time in milliseconds, which determines when the quota expires and new quota counter starts.

For Example if you use quota policy like below one

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Quota async="false" continueOnError="false" enabled="true" name="Quota-1" type="calendar">
    <DisplayName>Quota 1</DisplayName>
    <Allow count="2000" countRef="request.header.allowed_quota"/>
    <Interval ref="request.header.quota_count">1</Interval>
    <TimeUnit ref="request.header.quota_timeout">month</TimeUnit>
    <StartTime>2015-06-30 12:00:00</StartTime>
</Quota>

If you query , ratelimit.{policy_name}.expiry.time , then you will get value 1438257600000 in milliseconds. Which is equal to Thu Jul 30 2015 12:00:00 . Convert using this tool here.

Cheers,

Anil Sagar

[#3]

Does this not work with rolling window quotas? I have two setup and here is how they are defined:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Quota async="false" continueOnError="false" enabled="true" name="Per-Day" type="rollingwindow">
    <DisplayName>Per Day</DisplayName>
    <Identifier ref="signatureResults.requestLimitId"/>
    <Allow countRef="signatureResults.dailyRequestLimit"/>
    <Interval>1</Interval>
    <TimeUnit>day</TimeUnit>
    <AsynchronousConfiguration>
        <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
        <SyncMessageCount>5</SyncMessageCount>
    </AsynchronousConfiguration>
</Quota>

And...

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Quota async="false" continueOnError="false" enabled="true" name="Per-Hour" type="rollingwindow">
    <DisplayName>Per Hour</DisplayName>
    <Identifier ref="signatureResults.requestLimitId"/>
    <Allow countRef="signatureResults.hourlyRequestLimit"/>
    <Interval>1</Interval>
    <TimeUnit>hour</TimeUnit>
    <AsynchronousConfiguration>
        <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
        <SyncMessageCount>5</SyncMessageCount>
    </AsynchronousConfiguration>
</Quota>

When I run them with trace, I get the following.

• ratelimit.Per-Hour.expiry.time: 1435764914838
• ratelimit.Per-Day.expiry.time 1435764914838

Which when I use the tool you linked to, gives me pretty much the exact time I executed the call.

[ozanseymen]

@Dan Fearing - rolling quota doesn't support expiry date because in theory it doesn't expire. Quota window is moving on every minute as if the time box is shifting all the time.

[#5]

Hi @Ozan Seymen. I'm not sure how that makes sense. For example, if I have a quota of 500 and my interval is 1 hour, my understanding of the rolling window is that 1 hour from the first request, the quota resets.

You are saying that every time I hit the API, the quota expiration gets reset to 1 hour? Two problems with this, one, it still would have an expiration date (otherwise the quota is a lifetime quota and once you hit it, game over), and two, how would this make sense with a quota? With how I think you are describing it, my quota won't reset unless I don't hit the API for an hour?

[#6 · Accepted solution]

As @Ozan Seymen mentioned rolling and flexi types are dynamic so they will not have a defined start time. However we can still have the time when the counter reset happens in the expiry time or probably the starttime stamp using which we can compute when the reset happens.

At present the expiry variable captures the time of request which is wrong .I think the docs has to clearly mention that .

[anilsr]

@sgilson , FYI, Docs updated needed. Thank you 🙂

[#8]

So right now, to the best of your knowledge @Maruti Chand, it's not possible to get or calculate the expiration time when using a rolling window quota. Correct?

[#9]

Correct . Thats what I feel , there is no way for you to get what you want . cc @sgilson -- FYI

@Dan Fearing , lets see if any one has more ideas but in parallel I will try to raise a request internally to have those variables in future .

[ozanseymen]

@Dan Fearing @Maruti Chand

"if I have a quota of 500 and my interval is 1 hour, my understanding of the rolling window is that 1 hour from the first request, the quota resets." - this is not correct for rolling quota.

Rolling quota is interested in how much of the quota has been used up in (now - quota_duration). (now - quota_duration) is called rolling quota window and it is moving all the time - even if you make requests or not. Therefore quota counter is increasing all the time if you don't do any requests!!!

Assume we are allowed to do 60 requests in an hour. If we send 1 request every minute between 13:18 – 14:17 and stop using it

• @14:18 – we would have a quota of 1
• @14:19 – we would have a quota of 2
• @14:20 – we would have a quota of 3

Therefore it never resets fully (no expiry anymore). Quota will not truly reset to 0. It will be used down to 0.

Consider this example:

We have a daily quota of 1000 requests.

On Tue

• between 10:00 – 10:01: use 100
• between 10:02 – 10:10: use 900
• @10:11 – no quota

On Wed

• @09:59 – no quota
• @10:00 – no quota
• @10:02 – have 100
• @10:11 – have 1000 (counter is increasing as window is moving - as it is trying to keep the total same between now - quota_interval)

This is much easier to explain in front of a whiteboard! 🙂

[birute]

@Ozan Seymen I'm sure community would appreciate a quick and scrappy video you explaining this on the whiteboard too 🙂

[#12]

@Ozan Seymen

thats a nice explanation but feel free to post a video :D.

I did a quick test and this is my observation

type calendar and flexi , the expiry variable works .

type rolling window :

In your example ,

Aren't we allowing 100 more between 10 am to 11 am on wednesday ? as the actual quota started 10 am Tuesday and every 24 hours I want the proxy to allow only 1000 right ?

[ozanseymen]

Hi @Maruti Chand

Just pasting here some snippet from our internal discussion - nothing new for you I am afraid:

In that example above, in a 24 hour period, Apigee will never allow more than 1000 calls.

In a horizontal timeline, imagine a rectangle of 24 hours. You can move that rectangle back and forth in time. You should never find an occurrence where # of calls exceed 1000 within that rectangle.