Google Apps Script: best practice per il miglioramento delle performance

Realizzare uno script funzionante può essere fatto con diversi approcci, ma per ottenerne uno che porti allo stesso risultato in modo performante è richiesta una conoscenza di quali sono i limiti e delle potenzialità dello strumento utilizzato. In questo articolo sono elencate le best practice, con collegamenti ad esempi pratici di utilizzo, che consentono di migliorare le prestazioni degli script. Alcune potranno sicuramente risultare banali, tuttavia altre saranno senz'altro utili per aprirsi a nuovi approcci nel modo di lavorare.

La condizione comune al raggiungimento dello scopo la possiamo riassumere in un unico concetto:

Ridurre al minimo le chiamate verso altri servizi

Tutto ciò che può essere elaborato o calcolato in Javascript all'interno del file di Google Apps Script sarà sicuramente molto più veloce rispetto ad effettuare una chiamata verso altri servizi, sia che siano propri delle altre applicazioni della G suite, ovvero che siano destinate ai server di Google, sia che siano destinate verso server esterni.

Alcune situazioni in cui questo concetto diventa tangibile si trovano banalmente quando si lavora con gli Spreadsheet ed è necessario interfacciarsi con i fogli di calcolo in lettura ed in scrittura, oppure questo si ha la necessità accedere a risorse sul web recuperandole tramite URL con i metodi della classe UrlFetchApp, o anche nel caso in cui ci si avvalga di grosse librerie, anche se pur sempre in Apps Script, da includere al progetto.
Di seguito sono riportate in modo più approfondito le situazioni appena decritte, con riferimenti a casi pratici che evidenziano la differenza in termini di tempo di esecuzione dello script:

Utilizza le operazioni batch
Come è noto i comandi alternati di lettura e scrittura sono solitamente lenti per gli applicativi e quando si lavora con gli Spreadsheet il numero di interazioni di questo tipo con il foglio di calcolo tende spesso ad avere un'incidenza importante sulle prestazioni e di conseguenza sul tempo di esecuzione degli script.

Google Apps Script ha di per se una sorta di ottimizzazione incorporata che fa uso del sistema di cache look-ahead per il recupero dei dati in memoria, nel caso vi siano presenti perchè già stati utilizzati con operazioni precedenti, e riscrittura della cache per memorizzare quello che con buona probabilità potrà essere nuovamente interrogato.
Sulla base di questo sistema è possibile scrivere script al fine di trarre il massimo vantaggio, appunto, dal sistema di cache incorporata, script che in definitiva riducono al minimo il numero di chiamate allo Spreadsheet in lettura e scrittura e che, all'atto pratico, recuperano con un solo comando tutti i dati di un intervallo di celle per ottenerli in un array al fine di potervi eseguire qualsiasi operazione di elaborazione lato Apps Script ed andare a riscriverli nel foglio di calcolo, anche in questo caso, con un solo comando.

In altri termini, se devo effettuare un ciclo di lettura e scrittura di celle in un foglio di calcolo costituito da una griglia di dati di 500 righe e 10 colonne, ho la possibilità di effettuare le operazioni cella per cella (5000 operazioni), riga per riga (500 operazioni) o tutto in una volta (una sola operazione). Non è difficile intuire quale di questi 3 tipi di approccio possa essere quello migliore in termini di prestazioni, tuttavia rimando al mio articolo "Scrivere dati su uno Spreadsheet in modo performante con Google Apps Script" dove vengono analizzati in dettaglio questi 3 tipi di scrittura dei dati evidenziandone i tempi di esecuzione degli script dai quali potrete trarne da soli le vostre conclusioni.

Rimanendo nell'ambito Spreadsheet, un altro consiglio per ridurre i tempi di esecuzione del codice è quello di limitare le chiamate al metodo flush() alle sole situazione che ne richiedono realmente l'uso, per approfondimenti rimando al mio articolo "A cosa serve Spreadsheet.flush() e quando conviene usarlo".

Evitare l'inclusione delle librerie negli script
L'uso delle librerie, ovvero progetti le cui funzioni possono essere riutilizzate in altri script, agevola senza ombra di dubbio la scrittura di codice in quanto molte delle operazioni standardizzabili o di ricorrente utilizzo possono essere localizzate in un documento di Apps Script per poi essere incluso in altri progetti al fine di condividere tali funzioni anziché doverle scrivere ogni volta che in un progetto ne nasce la necessità.

Il rovescio della medaglia è che la loro inclusione in un progetto aumenta leggermente il tempo di avvio dello script, inoltre, con una maggiore evidenza negli script corredati di interfaccia HTML che eseguono chiamate ripetute a google.script.run (chiamate asincrone Javascript, disponibili per le pagine che fanno uso del servizio HtmlService, in grado di chiamare le funzioni lato server del relativo file di script), il ritardo incide su ogni chiamata.
Il suggerimento è pertanto quello di evitare l'uso di librerie in script destinati ad uso lato utente e pertanto copiare il contenuto desiderato della libreria direttamente all'interno dello script principale, e riservarne l'uso per agevolare le operazioni di scrittura per quegli applicativi che funzionano 'dietro le quinte', come ad esempio script giornalieri automatizzati per il recupero e la gestione di file, elaborazione automatizzata di documenti e quant'altro non richieda interazioni o tempi di attesa nel momento in cui un utente si trova ad interagire con un'interfaccia.

Utilizzare il servizio CacheService
È possibile utilizzare il servizio Cache per memorizzare nella cache le risorse, in modalità pubblica o privata, al fine di trovarle immediatamente disponibili alle successive esecuzioni dello script. Questa funzionalità permette di ridurre il numero di volte, o la frequenza, con cui è necessario interrogare un servizio per recuperarne i dati.

Se si ha, ad esempio, la necessità di recuperare una serie di informazioni interrogando un web service e questo impiega decine di secondi per restituire il risultato, alle successiva esecuzioni dello script, utilizzando la Cache, accederemo direttamente ai dati senza attendere la latenza di una nuova interrogazione al servizio. Un altro caso pratico può essere quello di predisporre preventivamente, per un tempo indicato (per impostazione predefinita la persistenza dei dati in cache è di 10 minuti, tuttavia il tempo di permanenza può essere personalizzato da 1 secondo a 6 ore dati), i risultati delle chiamati all'interno della cache (non è documentato un limite massimo di dati memorizzabili, l'unico limite certo è quello di 100KB per chiave, tuttavia è possibile memorizzare più di una chiave per lo stesso progetto) e basarsi su questi per le operazioni da effettuare alle successive esecuzioni dello script.

Per prendere visione di un esempio pratico di gestione della cache all'interno di uno script di Google Apps Script e valutarne l'effettivo miglioramento in termini di prestazioni rimando alla lettura del mio articolo "Memorizzare le risorse nella Cache e condividerle tra un'esecuzione e l'altra".

In Conclusione...

Una volta assimilato l'approccio a queste best practice nel proprio modo di lavorare renderete i vostri script sempre più snelli e veloci, sia in fase di testing che di produzione, e lo spettro dell'errore "Exceeded maximum execution time" quando si ha a che fare con una grosse mole di dati in lettura, elaborazione e scrittura, diventerà un ricordo lontano.

Potete inoltre trovare un approccio risolutivo agli script che impiegano più di 6 minuti per il completamento delle operazioni, nell'articolo 'Soluzione al superamento del limite di tempo massimo di esecuzione consentito'.