我刚刚做了一个本地实验(我目前没有任何可快速部署的游戏应用程序),看起来你非常有趣的想法可以奏效。
我用特定的模式替换了.*
之前捕获所有落后者并将它们路由到我的默认服务脚本(我正在使用 python 运行时)的模式,然后在所有其他模式之后添加了这个处理程序:
- url: /(.*)$
static_files: images/\1
upload: images/.*
我的images
目录是真实的,包含静态图像(但我已经有另一个具有更具体模式的处理程序)。
有了这个,我提出了一个请求/crap
并得到了,正如预期的那样(没有images/crap
文件):
INFO 2019-11-08 03:06:02,463 module.py:861] 默认值:“GET /crap HTTP/1.1”404 -
我在我的脚本处理程序中添加了日志调用,get()
并dispatch()
调用以确认它们实际上没有被调用(开发服务器请求日志记录产生了一些疑问)。
我还检查了一个已经部署的 GAE 应用程序,该应用程序请求与静态处理程序模式匹配但实际上不存在的图像得到404
答案,而不会导致服务的实例被启动(当时没有实例正在运行),即它来了直接来自 GAE 的静态内容 CDN。
因此,我认为使用 go 运行时非常值得一试,这可以为应用程序节省一些重要的实例时间,而无需面对随机机器人流量的大量活动。
至于实例重启,我怀疑你看到的只是你的 min-idle 实例设置为 1 的症状。与动态实例不同,空闲(又名常驻)实例通常不意味着处理流量,它只是准备好了如果/需要时。只有当没有动态实例运行(并且能够有效地处理传入流量)并且有新请求进入时,该请求才会立即路由到空闲实例。那一刻:
- 空闲实例变为动态实例,并将继续为流量提供服务,直到它因不活动或死亡而关闭
- 一个新的空闲实例被启动以满足最小空闲配置,它将保持空闲直到另一个类似的事件发生
注意:您的想法将有助于动态实例使用的实例小时数部分,但不适用于空闲实例部分。