Je n'ai pas réussi à trouver cette limite dans l'aide de Google .
Après plusieurs tests, c'est la conclusion à laquelle je suis arrivée.
Cette limite est évoqué dans un tutoriel de Romain Vialard et aussi dans celui pour ScriptDb mais sans plus d'explications :
First, we do a single call to the spreadsheet to retrieve all the data. We could have read our sheet row by row, but JavaScript operations are considerably faster than talking to other services like Spreadsheet. The fewer calls you make, the faster it will go. This is important because each script execution has a maximum run time of 6 minutes.
Depending on how many items are in the database, this script may exceed the current maximum script execution time limit (6 minutes), so the script may terminate prematurely. However, you can run it again as necessary until the database is empty.
J'ai bien essayé de récupérer le message en anglais en changer la langue de mon Drive.
Mais le message d'erreur est resté en français !
J'ai essayé aussi la méthode exception avec un try catch...
Mais ce type d'erreur n'est pas remontée par exception !
function scriptExecutionTime() {
var startTime = new Date();
Logger.log(startTime);
try {
myFunction();
} catch(e) {
var errorTime = new Date();
Logger.log(errorTime);
Logger.log(e);
}
var endTime = new Date();
Logger.log(endTime);
}
Logique si on considère que Google limite à 6 minutes l'exécution des scripts Google Apps.
Incompréhensible et difficilement gérable du point de vue du programmeur.
Alors que faire lorsque votre script dure plus de 6 minutes ?
L'optimisation ! Oui mais comment ?
Difficile d'optimiser du code sans savoir quelles sont les parties de ce dernier qui prennent le plus de temps.
Difficile d'optimiser son code quand il faut attendre 6 minutes pour que le verdict tombe : passera ? passera pas ?
Et quand bien même votre code passe aujourd'hui. Qui de demain ?
Alors en attendant d'avoir un profiler pour le code Google Apps Script, que faire ?
Il faut ruser : utiliser Logger.log(new Date()) pour tracer les heures d'exécution des différents section de votre code.
Cela peut-être fastidieux et rébarbatif je le conçois mais c'est une technique qui a toujours fonctionné quelque soit le langage de programmation utilisé.
Dommage qu'au niveau de la plateforme de Google, on ne reçoive pas au fil de l'eau les événements publiés sur la console.
Consulter aussi la log intitulée "Script d'exécution" qui se trouve dans le menu "Affichage | Script d'exécution..."
Éviter d'utiliser - quand c'est possible - la gestion d'exception avec un bloc try catch.
D'après mon expérience, ce traitement m'a l'air consommateur sur la plateforme de Google.
Sat Jan 26 21:20:59 PST 2013
Sat Jan 26 21:21:27 PST 2013
=> 28 s
Sat Jan 26 21:22:39 PST 2013
Sat Jan 26 21:23:15 PST 2013
=> 36 s
Soit quasiment 30% de temps en plus.
Voici un exemple de code appliquée sur un Drive avec beaucoup de fichiers :
function trycatchRaised() {
throw new Error();
}
function trycatchTime() {
var pageSize = 200;
var files = null;
var token = null;
var fileOwner = "";
var fileName = "";
Logger.log(new Date());
do {
var result = DocsList.getFilesForPaging(pageSize, token);
files = result.getFiles();
token = result.getToken();
for (var i = 0; i < files.length; i++) {
try {
// trycatchRaised();
} catch(e) {
fileOwner = "";
};
fileName = files[i].getName();
}
} while (files.length == pageSize);
Logger.log(new Date());
}
A noter au passage que la fonction getOwner() déclenche une exception sur les fichiers partagés et que - encapsulée dans un try catch - cette fonction consomme tellement de temps à chaque boucle que l'on arrive vite à la limite des fameuses 6 minutes.
fileOwner = files[i].getOwner();
Relisez bien votre code et traquer l'erreur classique du traitement inutilement positionné dans une boucle répété x fois. Ce genre d'erreur peut vite devenir chronophage.
Voici donc quelques conseils pour essayer de tenir l'exécution optimum de votre code pour les 6 minutes allouées par Google.
gDrive Meter Team
Aucun commentaire:
Enregistrer un commentaire