I've made several requests to change my persistent SSD storage on Google Compute starting almost a month ago but I've never received any answer from Google. What should I do to obtain that quotas upgrade?
The Google documentation points to Stack for requesting help, therefore I ask my question here.
Quota Increase requests are usually actioned upon within 2-3 days, usually during regular work days. You ought to have received, at least, the confirmation email of your original request. If you didn't, perhaps the entered address was not correct.
Another possibility is that the request came from an address that, at the time, was not entitled to request such an increase, that wasn't the owner.
And there's always the ever-present spam folder, where some notifications always seem to land.
Also, be aware that projects in free trial are not allowed to request quota increases: in order to do that, an upgrade out of the free trial is required.
You can always submit a new Quota Increase request: I'm sure it will be actioned upon on short notice. :-)
Related
we use a custom script to retrieve data from Bookeo API with UrlFetchApp.fetch. µ
Everything went well but today, we have the following error "Service invoked too many times for one day: urlfetch"
We are aware of the limitation of 20.000 calls/day as mentionned here https://developers.google.com/apps-script/guides/services/quotas, but we don't think that we come close to this (maybe 1.000 - 1.500/day max)
The portion of the code where the error happen is
var responseBooking = UrlFetchApp.fetch(urlBooking);
So i'm sure it's related to quota issue
The weird thing is it's working like 1 time / 5-6 try
My questions are :
has Google changed it's quota limitation? (I didn't see any communication about it)
Is there a way to see how many calls was made for each service?
Is there a sort of chat for technical support for Google Apps Script?
Answer(s):
has Google changed it's quota limitation? (I didn't see any communication about it)
No.
Is there a way to see how many calls was made for each service?
No.
Is there a sort of chat for technical support for Google Apps Script?
No.
More Information:
Aside from the 20,000 calls/day limit, there are also limits which restrict the number of calls in short periods of time.
The quota works based on a rolling average of service invocations. You have a quota of 20,000 per day, but if you exceed the rate of ~0.231 calls per second (20,000/86,400) for a sustained period of time, you can still trigger an error.
You can rectify this by waiting for a while so that the impulse of invocations goes down. I would also suggest adding some form of exponential backoff to your code to stop this from happening again in future.
References:
Quotas for Google Services | Apps Script | Google Developers
Exponential backoff - Wikipedia
I have a small website running on the "always free" tier. It's perfect for my needs. After my trial period ended (and I hadn't used any fee-based resoures), I reverted back to "always free." This is fine. This morning, I received an email which read, in part:
Your Always Free resources will remain available to you as long as you
actively use your account.
but doesn't define the meaning of "actively use your account." I would just chat online with someone, but that's not available to me. I tried to use their community forums, but their login seems busted, so I landed here. (No offense, but I was under the impression this is mostly for development questions.)
Is having a website running sufficient to qualify as "active use?" Do I need to login to the console periodically? No matter the use, what constitutes "active?" For example, if I am required to login the the console periodically, how often to I have to do that? Weekly? Monthly?
Based on the "Inactivity Monitoring and Database Stoppage" sections of the documentation, Always Free account activity works like this:
Oracle Autonomous Database: "Successfully making a SQL*Net or HTTPS connection resets these measurements to zero"
APEX: "Successfully making a HTTPS connection resets these measurements to zero."
COMPUTE and others: Unknown - I can't find the relevant documentation
Per the documentation, you get 7 days before the resource is automatically stopped, and then 90 days before the resource is permanently deleted.
Based on my experience with the database, you get a warning email after 7 days, and then 2 days later the resource is stopped. You get a warning email about permanent deletion after 60 days, and luckily I don't have experience with how long it takes for a resource to be permanently deleted.
we use a custom script to retrieve data from Bookeo API with UrlFetchApp.fetch. µ
Everything went well but today, we have the following error "Service invoked too many times for one day: urlfetch"
We are aware of the limitation of 20.000 calls/day as mentionned here https://developers.google.com/apps-script/guides/services/quotas, but we don't think that we come close to this (maybe 1.000 - 1.500/day max)
The portion of the code where the error happen is
var responseBooking = UrlFetchApp.fetch(urlBooking);
So i'm sure it's related to quota issue
The weird thing is it's working like 1 time / 5-6 try
My questions are :
has Google changed it's quota limitation? (I didn't see any communication about it)
Is there a way to see how many calls was made for each service?
Is there a sort of chat for technical support for Google Apps Script?
Answer(s):
has Google changed it's quota limitation? (I didn't see any communication about it)
No.
Is there a way to see how many calls was made for each service?
No.
Is there a sort of chat for technical support for Google Apps Script?
No.
More Information:
Aside from the 20,000 calls/day limit, there are also limits which restrict the number of calls in short periods of time.
The quota works based on a rolling average of service invocations. You have a quota of 20,000 per day, but if you exceed the rate of ~0.231 calls per second (20,000/86,400) for a sustained period of time, you can still trigger an error.
You can rectify this by waiting for a while so that the impulse of invocations goes down. I would also suggest adding some form of exponential backoff to your code to stop this from happening again in future.
References:
Quotas for Google Services | Apps Script | Google Developers
Exponential backoff - Wikipedia
For about a week now, it says:
Queued for provisioning
Due to an increase in OpenShift Online Starter popularity, please
expect a longer delay in account provisioning. You will receive an
email when there is enough capacity to add your account. Thank you for
your patience!
Two weeks!
It took two weeks for Red Hat to finally provision the account. Yesterday I finally received an email:
Your OpenShift Online account is ready!
Obviously I had already moved to another provider in the meantime.
(Note that the status page had not displayed any technical reasoning for the delays. It was "all green". It's pretty obvious that this is just tactics to avoid getting users on the free tier.)
In Salesforce I have created a future method that makes a Google Maps geocode callout. I know there is a limit of 2,500 requests per day but our instance has made no more than 100 requests today. Maybe the same number of requests yesterday. Yet the response code is 620 G_GEO_TOO_MANY_QUERIES.
Could it be that Google is seeing the IP address of the instance of Salesforce and aggregating all of these requests as coming from one location. So other companies that are sharing the address are causing my instance to hit this limit?
If not can anyone suggest another cause?
This discussion suggests that it is the shared origin from salesforce that is messing it up.
This only makes sense though if you are doing the geocode lookup from the server and not from a client. If you would do it fromt the client it would use the ip from the client and you are dealing with the local clients lookup limits (see below).
If you are doing it on the server you might also have to check if you are actually doing something that is legal and not breaking the ToS from google. In this discussion you will get some background on that and also a solution if you need to fix this on the server (buy a licence)
To be complete the G_GEO_TOO_MANY_QUERIES can mean one of 2 things:
You exceeded the daily limit (too many in a day)
You exceeded the speed limit (too many request is too short period)
Google has not specified an exact limit as far as I know but they don't seem to enjoy automated lookups. If you look at various libraries and plugins you'll see that all of them force a delay between each request and often they add a little randomness to the delay. You could experiment with this if it makes any difference
Did this end up working for you? we're hitting a server-side 620 and all configuration looks a.o.k... we have a premier license and upgraded to 250k requests per day.