为什么对我的 Google Apps Script Web App 的 GET 请求会间歇性超时？

Question

尽管通过 GET 进行了相同的调用，但我的 GAS Web 应用程序定期没有返回任何响应。相反，调用应用程序会在等待 15+ 秒后报告超时情况*。

我使用了 hurl.it（设置了“Follow Redirects”）——一个出色的测试工具！ -- 以及 Twilio 消息服务调用相同的 URL、参数、值等，发现响应超时，就好像预期的 Google Apps 脚本代码从未运行过一样。

超时是间歇性的，没有关于一天中的时间、请求 URL、有效负载（GET 参数）等的模式。此外，底层 GAS 代码在所有其他时间都可以完美运行。

示例 GET 请求： https://script.google.com/macros/s/AKfycbw5LddY3SIv-dD6U_1ibAy7cGog5WjmHyDDUSyBq0G2k9gZ3rkI/exec?MessageSid=1234&From=+8081234567&Body=newman

预期的 XML 响应： <Response><Sms>Timothy has sent you ...</Sms></Response>

*注意：底层 GAS 代码（其性能似乎并未影响我的困境）通常在响应通过时在 0.125 秒内执行。

在进行故障排除时，我对“明显的东西”进行了双重和三重检查，例如确保将最新代码部署为 Web 应用...、确保代码本身包含 doGet() 函数、所有服务已获得授权，用户权限设置为“任何人（甚至匿名）”，等等。

此时我的怀疑（称其为我的智慧结束）是 Google 的服务器根本不会随机响应，这导致我的工作严重积压。任何见解都非常感谢！我已经彻底检查了这个论坛和其他论坛是否有类似的投诉，但无济于事。

提前致谢！

Answer 1

最终（有效？）“解决方案”

我还在脚本的开头实现了lock.tryLock(10000)（请参阅 GAS 文档），这样我的代码的基于触发器和 GET 请求的实例就不会相互绊倒。同样，我在更改电子表格数据的任何脚本/函数的末尾添加了SpreadsheetApp.flush()，以防止冲突。

具有讽刺意味的是，将 BetterLog 库添加到我的项目似乎引入了它的自己的超时问题，即在其代码中使用getLastRow()。仔细观察 View > Execution Transcript（谢天谢地，BetterLog 还在本机 Logger 中记录了自己的活动！）发现getLastRow() 的实例每个需要 10-20 秒来执行！我认为这是 GAS 中的一个真正缺陷，因此已在 Google 的问题跟踪器上提交了一份完整的错误报告。

以下是演示问题的示例行（仍然是间歇性的）：
[16-06-11 07:11:13:980 CDT] Sheet.getLastRow() [20.141 秒]

半决赛（几乎有效？）“解决方案”

关于我包里唯一剩下的技巧是查看幕后是否发生了任何代码冲突。最终，在禁用现有项目触发器（设置为每分钟运行一次）后，超时问题消失了！这让我不愿意重新启动那个（非常必要的）触发器，但是科学方法要求我这样做是为了判断超时问题是否会再次出现。

注意：我当然想知道为什么完美运行的代码库会如此容易被并行运行的两个（独立）子例程绊倒？我的怀疑是，由于两者都使用相同的功能并访问相同的底层电子表格，因此存在（未宣布的）锁定违规的风险。为什么这反过来表现为超时（而不是错误消息）超出了我的范围，但足以说明我增强的日志记录工作（见下面的注释......）清楚地表明运行时间从 0.3 秒升级到大约 60 秒（！！）当它发生时。

原始（无效）“解决方案”

底层问题出现与使用 GAS 的原生 Logger 功能有关。从我的代码中删除 Logger.log() 的实例几乎立即导致了时间的改进，以至于应用程序长时间响应每个 GET 请求。

因此，我实现了 Peter Herrmann 最出色的帮助库 BetterLog（请参阅 https://github.com/peterherrmann/BetterLog）来满足我的日志记录需求，并将活动记录在 Google Drive 中连接的电子表格内的新工作表（适当命名为“日志”）上.

在接下来的两个小时内，Web 应用程序的响应率一直保持在 100% ... 但是，原来的问题在当天下午晚些时候又卷土重来，响应率下降到 0%。

如果出现任何其他见解，将进一步更新（或编辑此答案）！