In the documentation for developers (here) written about this error
Service using too much computer time for one day
that
This indicates that the script exceeded the total allowable execution time for one day. It most commonly occurs for scripts that run on a trigger, which have a lower daily limit than scripts executed manually.
And there is a daily limit for triggers total runtime (1hr for basic account).
But where can I get the limitation for manual executed script?
I'm pretty sure the limit is the same regardless of whether the script is manually executed or executed from a trigger; the limit is simply applied to your account, however you run the script.
As mentioned here: "Daily quotas are refreshed at the end of a 24-hour window; the exact time of this refresh, however, varies between users." I don't think Google publicly announces exactly what you get.
I run script on the sidebar that request calculation on the server side which stops after 300 seconds and the sidebar starts it again. This engine worked more than 12 hours without any fails. So, I suppose that there is no any limit for 'manually' executed scripts.
Related
When I create a daily time-based trigger for the Google app script associated with my Google spreadsheet, I am prompted to select an execution time that is within an hour-long window, and it appears that a cron wrapper randomly assigns an exact execution time within that hour-long interval.
Because my application's specific use case has several data dependencies which may not be completed early in the hour, I was forced to divide my application into several stages, with separate triggers each delayed by an hour, to insure that the required data would be available.
For example, the trigger time that was initially assigned for my script was 6:03AM, but the data which usually arrived at 5:57AM, occasionally did not arrive until 6:10AM and the script had nothing to process for that day. As a blunt force solution, I deleted the 6-7AM trigger and re-created it to execute in the 7-8AM time slot to insure the required data was available. This required that the second stage of the script had to be moved to 8-9AM, resulting in script results which could be delayed by as much as 2-3 hours.
To improve this situation, I am contemplating integrating the two script processing stages and creating a more accurate script execution trigger time, say 6:30AM to be safe. Does anyone know if:
Is it possible, other than by observing daily processing, to discover the exact trigger execution time that has been assigned, and
If randomly assigned, can script triggers be created and deleted until an acceptably precise execution time is obtained?
Thanks in advance for any guidance provided.
If accuracy is paramount, you can forgo using apps script triggers altogether and leverage a 3rd party tool instead.
I'd recommend using cron-job.org. This service can create cron jobs that make POST requests to a url endpoint you specify, and you can schedule times accurate to a minute. To use it with Apps Script implement a doPost() to handle post requests and deploy your script as a Web APP. You then create a cron job using the service and pass it the web app's URL as an endpoint.
The cron job will fire at the scheduled time and you can perform any requisite operations inside the doPost() in response to the incoming POST request.
Thank you to random parts and Dimu Designs for the guidance. Based upon experimentation, here are the answers to my questions:
Is it possible, other than by observing daily processing, to discover the exact trigger execution time that has been assigned? Answer: No way except by observing the random trigger time assigned within the requested hour window.
If randomly assigned, can script triggers be created and deleted until an acceptably precise execution time is obtained? Answer: Yes. I adjusted my script's assigned execution time by observing a trigger's execution time (via email message timestamp), and deleting, recreating, and observing the randomly assigned trigger execution time until I got an acceptable minute within the requested hour window.
I am using Google Apps Script to create documents based on a template and some data stored in a spreadsheet. It was previously working well but recently (without having changed any code) I started getting the below error during a "google.script.run" call from a very simple HTML sidebar:
Execution failed: Memory limit exceeded
The error occurs during the copying process - it seems to occur at slightly different places each time the script is run.
I don't see any references to memory limits in the apps script quotas and a general Google search doesn't seem to find anything.
Can anyone shed some light on this and how to determine the limit/what is holding most of the memory/increase the limit if possible?
Check the methods that you're using to get the data ranges.
i.e. if you use sheet.getRange(A:X) it'll get all the rows in the sheet, even the empty ones (probably in the order of tens of thousands, or even hundreds of thousands). It's a better option to use the getDataRange method, which get the last column and last row with data.
Be noted with the Quotas for Google Services. Apps Script services impose daily quotas and hard limitations on some features. If you exceed a quota or limitation, your script will throw an exception and terminate execution.
I'm not sure if I have encountered with a bug or is just me not fully understanding how triggers work, probably the second one :D.
I have a google apps script that collects information through a series of requests to our CRM's API and puts it on a Google Docs Spreadsheet, the script takes a while to run, however, it runs successfully (I run it manually every morning, takes about 3 minutes). But when I try to automate that task, I get an error message saying my script exceeded its execution time limit.
I tried setting up my triggers manually, creating them within the script, breaking down my script reducing the number of API requests (taking less then a minute to execute) and execute it several times so I get the whole information. Every single time I get the same error message.
Am I missing something here? Any help will be much appreciated!
Edit: The mail I received has this error message: "Exceeded maximum execution time".
Edit2: I was able to fix this (party). I came across the answer for this question Exceeded maximum execution time in Google Apps Script and worked like a charm.
There are some limits to Google Apps Scripts that you must keep in mind: see Quotas.
It is possible that you are exceeding your total runtime for Triggers. There is also the shorter individual execution time limits on Triggers. I think I remember reading somewhere that Triggers have a lower total execution time limit per execution, but I can't remember where I saw it, and I can't find a source, even in Google's documentation.
This SO question is also similar...
I wouldn't say it's a bug, however as my own painfully experience, I can tell it's not the same running the script manually than through a time-driven trigger.
Sometimes it's just slower, but others it fails for timeout.
I don't know your specifics (there is no code available), but I would recommend you to use a retry exponential backoff function wrapping any critical call and also check for a timeout warning (let's say at 5 minutes) within the main loop.
So I got the error message in the subject on the 1 (one) script I had running yesterday and I am assuming I will get a similar message today.
I have improved the script (which has a trigger to run once per minute) so it functions more along the lines of how it is supposed to however the error message got me thinking as to what sort of functions or bits of programs might be asking for more service time than others.
For example, I have had to use multiple sleep calls in my google apps script to allow the data import to run and again for the worksheet changes/copy paste calls to process. Are all those sleep calls counting against me in terms of service time used?
I would ask on the community's behalf that this be left as an open ended question not specific to the sleep function. What sorts of parts of a script are demanding service time and which are not (if any).
Every call to a service (Spreadsheet, Calendar or whatever) takes more time than regular JavaScript operations.
For example, if you have to modify 10 cells in a Spreadsheet,
calling range.setValue() 10 times takes far more time than having all the data in an array and then updating the spreadsheet in one go using range.setValues().
If you can paste pieces of your code, the community will be able to offer more advice on how to improve your script.
The limit is on CPU time used in time based triggers, and I believe those sleep calls are counted against your limit. I'd encourage you to find ways to avoid the sleep calls, or schedule your script to run less often.
Task:
For each of our clients, we need to build eight spreadsheets with a minimum of two triggers each: 1) on Open and 2) Time based to refresh specific data from a larger spreadsheet. (This is a workaround for failing IMPORTRANGE functions.)
We currently have 100 clients, and are expanding to 200 shortly. Therefore, our current need is approximately 800 spreadsheets, and 1,600 triggers; projected to be 1,600 and 3,200 respectively very soon.
Problem
After creating the first 300 spreadsheets (approximately 600 triggers) we have received the following error:
Your Quota of Triggers has been exceeded. To Create more, you must delete some existing triggers.
Desired Solution:
We are collecting the eight spreadsheets on a private Google site for each client. Ideally we could invoke each spreadsheet script from the site, and eliminate time-based triggers. Tried creating a button to execute the script, but on the site, it is not interactive.
Questions:
Operating on Windows 7, error is in Chrome also tried Firefox, and got same error.
1)a Does anyone know of the limits on triggers, is it published somewhere?
1)b Is there a way to increase these limits?
2) Any ideas on another work around or solution?
Eric already answered your question (1). (No, and no)
Now to question (2), a possible workaround is to invert the scenario of your scripts, instead of each script fetch its data on the "larger spreadsheet", a single script on your master could distribute the data on all other spreadsheets. You could have some kind of "registration" of each spreadsheet, maybe place them in the same folder, or any other way that suit you.
By changing the approach to this one, you'll surely run into another limitation, which is the script total run time: 6 minutes. But this problem you can easily work around by splitting the task into minor chunks that you can work and resume on a every minute trigger.
There are limits to the number of triggers one user can have, but they aren't published and they can't be changed.