限界検証シリーズ

1日当たりのトリガー実行時間制限に時間主導型は含まれない【GAS】

はじめに

今回は、GASの実行制限についてです。
GASには、トリガーで実行できる1日あたりの時間制限があります。
無料版では90分、GoogleWorkspaceユーザは6時間です。

ところが、私のGWS環境で7時間以上、実行されていました。
「誰もどこにも書いてないけど、時間主導はトリガー扱いではない・・・?」
と思い、検証してみました。

結論1:時間主導型は制限対象に含まれていないと思われる
結論2:そもそもこの制限、機能してなくない?
以下でそこに辿り着くまでの検証を紹介します。

無料プランで検証その1

1分毎に実行するトリガーを設定し、どれだけ実行できるか観察します。

仮説1:実行数参照画面の時間合計到達で上限到達

AppsScriptDashboardの実行数を確認する画面で、
表示される所要時間が上限値にきたら次のスクリプトは即エラーになる。
普通に解釈したらこれで引っ掛かりそうですが・・・

トリガー実行ログが数十件並ぶ画像

はい、ご覧の通り、完璧に90分を超過しています。
この後数時間放置しましたが、特に変化なく実行されていました。
本当なら実行開始2,3秒でエラーになるべきですが、
タイムアウトまでちゃんと中身動いてます。

仮説2:トリガー実行始めてからの経過時間で上限到達

9時から始めて、常時トリガー実行のスクリプトがあった場合、
10時半になったら上限にかかる、という仮説です。
大量の実行ログ
はい、この説も破綻!m9(^Д^)プギャー

無料プランで検証その2

仮説3:Dashboardで「トリガー」と区分されているものが対象

さすがに「トリガー」って書いてあるやつは対象だろう。
ということで、フォーム送信時トリガーを使います。
C#でseleniumを使い、強引に1分ごとにフォーム送信します。
起動されたスクリプトはほぼ360秒を所要するため、計算が容易です。
以下、検証用コードと結果画面です。

    internal class Class1
    {
        internal async void main()
        {
            var chromeVersion = new ChromeConfig().GetMatchingBrowserVersion();
            new WebDrivermana.DriverManager().SetUpDriver(new ChromeConfig());

            var options = new ChromeOptions();
            var sv = ChromeDriverService.CreateDefaultService();
            sv.HideCommandPromptWindow = true;

            using(var Cd = new ChromeDriver(sv, options, TimeSpan.FromSeconds(30)))
            {
                for(var i = 0; i < 500; i++)
                {
                    Cd.Url = "フォームURLやで";
                    Thread.Sleep(1000);
                    Cd.FindElement(By.TagName("textarea")).SendKeys("textarea");
                    Thread.Sleep(1000);
                    Cd.FindElement(By.XPath("//div[@aria-label='Submit']")).Click();
                    Thread.Sleep(58000);
                }
            }
        }
    }

やっぱり上限エラーにならない

結果:仮説立証ならず

画像を参照いただいた通り、どう見ても上限突破しています。

まとめ

今回の検証では、結論が明確になりませんでした。
GASのフォーラムにも投稿したことがありますが、
誰も分からないのか回答が1つもありませんでした。

制限が無かったと考えれば嬉しい部分もありますが、
公式サイトには上限が明記(範囲定義が曖昧ですが)されているので、 急に適用されるかもしれません。
「トリガー」という定義に当てはまりそうなものは上限に注意しましょう。

【GAS】appendRow()の同時実行は競合するのか

はじめに

GASでシート末尾に値を追加するappendRow()について、
同時に実行したら同じ行を編集してしまうのか、検証しました。
結論:同時実行は競合します。
以下、検証方法の紹介です。

コードと出力結果

function myFunction() {
  const sh = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("シート1");

  let now = dayjs.dayjs();
  while(now.format("HH:mm")!="09:30"){
    now = dayjs.dayjs();
  }

  sh.appendRow([dayjs.dayjs().format("YYYY/MM/DD HH:mm:ss")]);
  Utilities.sleep(300);
  sh.appendRow([dayjs.dayjs().format("YYYY/MM/DD HH:mm:ss")]);
  Utilities.sleep(300);
  sh.appendRow([dayjs.dayjs().format("YYYY/MM/DD HH:mm:ss")]);
  Utilities.sleep(300);
  sh.appendRow([dayjs.dayjs().format("YYYY/MM/DD HH:mm:ss")]);
  Utilities.sleep(300);
  sh.appendRow([dayjs.dayjs().format("YYYY/MM/DD HH:mm:ss")]);
}

4つのタブで同じスクリプトエディタを開き、実行します。
すると9:30になった瞬間同時に書き込みが走り、合計20行に値が入るはずです。
しかし、何度かやっても17~19行しか値が入りませんでした。
やはり20回の実行のうち、最終行を取得するタイミングが重なってしまうようでした。
気になる方はシートからエディタを開いてコピペして試してみてください。
(シートなので証拠になりませんが、イメージ図です。)
18行しか書き込まれていないイメージ図

対処方法はあるのか

appendRow()を使う限り、競合の可能性は捨てきれないでしょう。
appendRow()以外の方法で、絶対に競合を避けたい場合には、
GoogleDriveにファイルを保存する等の手段があります。

シート行に保存しようとしていたデータ1つ1つについて、
Drive上にJSONなどのファイルを設ければ、競合可能性を相当下げることができます。
ファイル名を日次+UUIDなどにしておけば、同名ファイルが生成されることもありません。
注意点として、それらのJSONを同時に変更可能な仕様にしてはいけません。

さいごに

GoogleAppsScriptを使う以上、
一部の処理ではどうしても競合が発生してしまいます。
上述のような打開策もありますが、仕様が分かりにくくなります。
外部のデータベースの利用なども視野に入れて仕様検討するのが無難かと思います。

GASの変更時トリガーが実行頻度によっては実行されない問題について検証してみた

0.はじめに

GASの変更時トリガーってあるけど、
本当に全ての変更をキャッチしてくれてるの?

と疑問に思ったので検証してみました。

例えばGoogleフォーム回答が入力されるスプレッドシートに対して、
シート変更時トリガーを仕込んでおり複数から同時に回答があったとしたら・・・?
本当はそんなスクリプトは組まない方がいいわけですが、
そんな時どうなるのか気になる方はぜひご覧ください。

 

1.検証用のコードとトリガー

本当の限界頻度を知りたいので、ごくシンプルな負荷の低いコードを使いました。


function myFunction() {
  console.log("testやで");
  GmailApp.createDraft("test@test","testやで","testやわ");
}

トリガーはこちら。普通の変更時トリガーです。
変更時トリガー設定の画像
もちろんこのスクリプトはスプレッドシートにバインドしています。

 

2.高速で実行してみた

まず、適当に10回実行してみた結果がこちらです。
セルを10個変更したスプレッドシートの画像
6行の実行ログ
10回変更したのに実行ログは6行しかあらへん。どういうこっちゃ。
実行されてるけど、実行ログだけ出てないのか?と思い、Gmailの下書きを確認します。
6件だけのメール下書き
やっぱり6件しかない。という事で、6回しか実行されていないようです。
高速での変更時トリガーは実行が欠損する
という事が分かりました。
(1回だけでは試行回数不足のため複数回、別時期にも試しております。)

 

3.実行頻度を落として実行してみた

どれぐらいが敷居なのか判断したいため、
秒間1~3回程度に実行ペースを落としてみます。

10回成功 秒間1~2回
10回成功した画像

10回成功 秒間1~3回
10回成功した画像

9回成功 秒間1~2回
9回成功した画像

無暗に高速実行した時より成功率は上がりましたが、まだムラがあります。
(3回だけでは試行回数不足のため複数回、別時期にも試しております。)

 

4.秒間1回にしてみた

では秒間1回ではどうでしょうか。

秒間1回程度で10回成功
秒間1回程度の実行で10回成功している画像

秒間1回程度で10回成功その2
秒間1回程度の実行で10回成功している画像

秒間1回程度で10回成功その3
秒間1回程度の実行で10回成功している画像

概ね、1秒に1回程度の実行であれば安定して動きそうです。
私の過去の検証や経験則を合わせても、
1秒1回以下のペースで安定すると結論付けてよいのでは、と考えています。

 

5.さいごに

いかがでしたでしょうか。
変更時トリガーが安定しない、同時実行の際に不安、
といった場合にはぜひこの内容を思い出してみてください。

それにしても、皆さんに画像で伝わるように秒間1回で実行するとかって難しいですね…w
GASの限界に挑戦するシリーズ、個人的に面白いなと思っているので、
何か思いつけばまたやってみようと思います。
「これ試してみてほしい!」等あればお気軽にコメントくださいね。