尽管通过GET拨打相同的电话，我的GAS网络应用仍然没有回复。相反，调用应用程序在等待15秒以上后报告超时条件*。
我使用过hurl.it（使用＆＃39;关注重定向＆＃39;设置） - 一个出色的测试工具！ - 以及Twilio消息服务，用于调用相同的URL，参数，值等，并发现响应超时，就好像预期的Google Apps脚本代码从未运行过一样。
超时是间歇性的，没有关于时间的模式，请求URL，有效负载（GET参数）等。此外，基础GAS代码在其他所有时间都可以完美运行。
预期的XML响应：
<Response><Sms>Timothy has sent you ...</Sms></Response>
*注意：基础GAS代码，其性能似乎不会影响我的困境，通常在响应确实通过后的0.125秒内执行。
在进行故障排除时，我对“明显的东西”进行了双重和三重检查。例如确保将最新代码部署为Web App ...，确保代码本身包含doGet（）函数，所有服务都已获得授权，用户权限设置为＆＃34;任何人（甚至匿名）＆ ＃34;等等。
我此时的怀疑（称之为我的智慧结束）是Google的服务器根本不会随机做出反应，这导致我的工作严重积压。任何见解都非常感谢！我已经彻底检查了这个和其他论坛的类似投诉，但没有用。
感谢提前！
答案 0 :(得分：1)
最终（有效？）＆＃34;解决方案＆＃34;
我还在脚本开头实现了lock.tryLock(10000)（请参阅GAS文档），以便基于触发器和GET请求的代码实例不会相互跳过。同样，我在更改电子表格数据的任何脚本/函数的末尾添加了SpreadsheetApp.flush()，以防止发生冲突。
具有讽刺意味的是，将BetterLog库添加到我的项目似乎已经引入了自己的超时问题，即在其代码中使用getLastRow()。仔细观察View＆gt;执行脚本（谢天谢地，BetterLog还在原生Logger中记录自己的活动！）显示getLastRow()的实例每个需要10-20秒执行！我认为这是GAS中的一个真正的缺陷，因此在Google的问题跟踪器上提交了一份详尽的Bug报告。
这是一个展示问题的示例线（仍然是间歇性的）：
[16-06-11 07：11：13：980 CDT] Sheet.getLastRow（）[20.141秒]
半决赛（几乎有效？）＆＃34;解决方案＆＃34;
关于我手中唯一剩下的技巧是看幕后是否发生任何代码冲突。最终，在禁用现有项目Trigger（设置为每分钟运行一次）后，超时问题就消失了！这使得我不愿意重新启动那个（非常必要的）触发器，但科学方法要求我这样做才能判断超时问题是否会返回。
注意：当然，我想知道为什么完全正常运行的代码库很容易被并行运行的两个（独立）子程序绊倒？我的怀疑是，由于两者都使用相同的功能并访问相同的底层电子表格，因此存在（未通知）锁定违规的风险。为什么这会反过来显示为超时（而不是错误消息）超出我的范围，但足以说我的增强日志记录工作（请参阅下面的注释......）清楚地表明运行时从0.3秒升级到大约60秒（!!）当它发生时。
ORIGINAL（无效）＆＃34;解决方案＆＃34;
基本问题出现与使用GAS的本机Logger功能相关联。从我的代码中删除Logger.log()的实例几乎可以立即改进时间，直到应用程序在很长一段时间内响应每个GET请求。
因此，我实施了Peter Herrmann最优秀的帮助库BetterLog（请参阅https://github.com/peterherrmann/BetterLog）以满足我的日志记录需求，并将活动记录在新表格上（适当命名为＆＃39） ;记录在Google云端硬盘中已连接的电子表格中。
在接下来的两个小时内，网络应用程序响应率保持在100％......然而，原始问题在同一天下午后报复，随后响应率降至0％。
如果出现任何其他见解，将进一步更新（或编辑此答案）！