Can the Google Calendar API events watch be used without risking to exceed the usage quotas?
I am using the Google Calendar API to preprocess events that are being added (adjust their content depending on certain values they may contain). This means that theoretically I need to update any number of events at any given time, depending on how many are created.
The Google Calendar API has usage quotas, especially one stating a maximum of 500 operations per 100 seconds.
To tackle this I am using a time-based trigger (every 2 minutes) that does up to 500 operations (and only updates sync tokens when all events are processed). The downside of this approach is that I have to run a check every 2 minutes, whether or not anything has actually changed.
I would like to replace the time-based trigger with a watch. I'm not sure though if there is any way to limit the amount of watch calls so that I can ensure the 100 seconds quota is not exceeded.
My research so far shows me that it cannot be done. I'm hoping I'm wrong. Any ideas on how this can be solved?
google-calendar-api watch quota
add a comment |
I am using the Google Calendar API to preprocess events that are being added (adjust their content depending on certain values they may contain). This means that theoretically I need to update any number of events at any given time, depending on how many are created.
The Google Calendar API has usage quotas, especially one stating a maximum of 500 operations per 100 seconds.
To tackle this I am using a time-based trigger (every 2 minutes) that does up to 500 operations (and only updates sync tokens when all events are processed). The downside of this approach is that I have to run a check every 2 minutes, whether or not anything has actually changed.
I would like to replace the time-based trigger with a watch. I'm not sure though if there is any way to limit the amount of watch calls so that I can ensure the 100 seconds quota is not exceeded.
My research so far shows me that it cannot be done. I'm hoping I'm wrong. Any ideas on how this can be solved?
google-calendar-api watch quota
add a comment |
I am using the Google Calendar API to preprocess events that are being added (adjust their content depending on certain values they may contain). This means that theoretically I need to update any number of events at any given time, depending on how many are created.
The Google Calendar API has usage quotas, especially one stating a maximum of 500 operations per 100 seconds.
To tackle this I am using a time-based trigger (every 2 minutes) that does up to 500 operations (and only updates sync tokens when all events are processed). The downside of this approach is that I have to run a check every 2 minutes, whether or not anything has actually changed.
I would like to replace the time-based trigger with a watch. I'm not sure though if there is any way to limit the amount of watch calls so that I can ensure the 100 seconds quota is not exceeded.
My research so far shows me that it cannot be done. I'm hoping I'm wrong. Any ideas on how this can be solved?
google-calendar-api watch quota
I am using the Google Calendar API to preprocess events that are being added (adjust their content depending on certain values they may contain). This means that theoretically I need to update any number of events at any given time, depending on how many are created.
The Google Calendar API has usage quotas, especially one stating a maximum of 500 operations per 100 seconds.
To tackle this I am using a time-based trigger (every 2 minutes) that does up to 500 operations (and only updates sync tokens when all events are processed). The downside of this approach is that I have to run a check every 2 minutes, whether or not anything has actually changed.
I would like to replace the time-based trigger with a watch. I'm not sure though if there is any way to limit the amount of watch calls so that I can ensure the 100 seconds quota is not exceeded.
My research so far shows me that it cannot be done. I'm hoping I'm wrong. Any ideas on how this can be solved?
google-calendar-api watch quota
google-calendar-api watch quota
asked Nov 22 '18 at 8:53
AlexAlex
62
62
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
AFAIK, that is one of the best practice suggested by Google. Using watch and push notification allows you to eliminate the extra network and compute costs involved with polling resources to determine if they have changed. Here are some tips to best manage working within the quota from this blog:
- Use push notifications instead of polling.
- If you cannot avoid polling, make sure you only poll when necessary (for example poll very seldomly at night).
- Use incremental synchronization with sync tokens for all collections instead of repeatedly retrieving all the entries.
- Increase page size to retrieve more data at once by using the maxResults parameter.
- Update events when they change, avoid re-creating all the events on every sync.
- Use exponential backoff for error retries.
Also, if you cannot avoid exceeding to your current limit. You can always request for additional quota.
Thanks for the response! But I think this has more to do with the daily quota and not with the 100 second quota. I am well within the 1 million calls per day, but I can't ensure that I do less than 500 operations per 100 seconds with a watch.
– Alex
Nov 26 '18 at 8:49
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53427067%2fcan-the-google-calendar-api-events-watch-be-used-without-risking-to-exceed-the-u%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
AFAIK, that is one of the best practice suggested by Google. Using watch and push notification allows you to eliminate the extra network and compute costs involved with polling resources to determine if they have changed. Here are some tips to best manage working within the quota from this blog:
- Use push notifications instead of polling.
- If you cannot avoid polling, make sure you only poll when necessary (for example poll very seldomly at night).
- Use incremental synchronization with sync tokens for all collections instead of repeatedly retrieving all the entries.
- Increase page size to retrieve more data at once by using the maxResults parameter.
- Update events when they change, avoid re-creating all the events on every sync.
- Use exponential backoff for error retries.
Also, if you cannot avoid exceeding to your current limit. You can always request for additional quota.
Thanks for the response! But I think this has more to do with the daily quota and not with the 100 second quota. I am well within the 1 million calls per day, but I can't ensure that I do less than 500 operations per 100 seconds with a watch.
– Alex
Nov 26 '18 at 8:49
add a comment |
AFAIK, that is one of the best practice suggested by Google. Using watch and push notification allows you to eliminate the extra network and compute costs involved with polling resources to determine if they have changed. Here are some tips to best manage working within the quota from this blog:
- Use push notifications instead of polling.
- If you cannot avoid polling, make sure you only poll when necessary (for example poll very seldomly at night).
- Use incremental synchronization with sync tokens for all collections instead of repeatedly retrieving all the entries.
- Increase page size to retrieve more data at once by using the maxResults parameter.
- Update events when they change, avoid re-creating all the events on every sync.
- Use exponential backoff for error retries.
Also, if you cannot avoid exceeding to your current limit. You can always request for additional quota.
Thanks for the response! But I think this has more to do with the daily quota and not with the 100 second quota. I am well within the 1 million calls per day, but I can't ensure that I do less than 500 operations per 100 seconds with a watch.
– Alex
Nov 26 '18 at 8:49
add a comment |
AFAIK, that is one of the best practice suggested by Google. Using watch and push notification allows you to eliminate the extra network and compute costs involved with polling resources to determine if they have changed. Here are some tips to best manage working within the quota from this blog:
- Use push notifications instead of polling.
- If you cannot avoid polling, make sure you only poll when necessary (for example poll very seldomly at night).
- Use incremental synchronization with sync tokens for all collections instead of repeatedly retrieving all the entries.
- Increase page size to retrieve more data at once by using the maxResults parameter.
- Update events when they change, avoid re-creating all the events on every sync.
- Use exponential backoff for error retries.
Also, if you cannot avoid exceeding to your current limit. You can always request for additional quota.
AFAIK, that is one of the best practice suggested by Google. Using watch and push notification allows you to eliminate the extra network and compute costs involved with polling resources to determine if they have changed. Here are some tips to best manage working within the quota from this blog:
- Use push notifications instead of polling.
- If you cannot avoid polling, make sure you only poll when necessary (for example poll very seldomly at night).
- Use incremental synchronization with sync tokens for all collections instead of repeatedly retrieving all the entries.
- Increase page size to retrieve more data at once by using the maxResults parameter.
- Update events when they change, avoid re-creating all the events on every sync.
- Use exponential backoff for error retries.
Also, if you cannot avoid exceeding to your current limit. You can always request for additional quota.
answered Nov 23 '18 at 5:05
Mr.RebotMr.Rebot
5,1062757
5,1062757
Thanks for the response! But I think this has more to do with the daily quota and not with the 100 second quota. I am well within the 1 million calls per day, but I can't ensure that I do less than 500 operations per 100 seconds with a watch.
– Alex
Nov 26 '18 at 8:49
add a comment |
Thanks for the response! But I think this has more to do with the daily quota and not with the 100 second quota. I am well within the 1 million calls per day, but I can't ensure that I do less than 500 operations per 100 seconds with a watch.
– Alex
Nov 26 '18 at 8:49
Thanks for the response! But I think this has more to do with the daily quota and not with the 100 second quota. I am well within the 1 million calls per day, but I can't ensure that I do less than 500 operations per 100 seconds with a watch.
– Alex
Nov 26 '18 at 8:49
Thanks for the response! But I think this has more to do with the daily quota and not with the 100 second quota. I am well within the 1 million calls per day, but I can't ensure that I do less than 500 operations per 100 seconds with a watch.
– Alex
Nov 26 '18 at 8:49
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53427067%2fcan-the-google-calendar-api-events-watch-be-used-without-risking-to-exceed-the-u%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown