在思考了如何制作一个快速且可扩展的 Web 应用程序之后，我几乎决定选择 Google App Engine、Python+Django 和 app-engine-patch 的组合。但我在app-engine-patch FAQ中看到了一条评论这让我觉得这个组合可能并不像我想象的那么成熟：启动一个 Django 实例可能需要几秒钟（根据常见问题解答，1-4 秒）。如果请求之间存在一些持久性，这可能不是问题，但似乎当没有持续的流量时，Django 实例会在几秒钟内关闭。如果系统不是每隔一秒左右调用一次，任何传入的请求都需要几秒钟（！）才能被授予。这是无法接受的。作为一个快速修复（丑陋，我知道），我正在考虑让外部机器每秒向框架发出一个虚拟请求，只是为了让它保持活力。
你同意吗？你有其他方法吗？
我的另一个疑问是，如果有足够的流量从一台 n 服务器跳转到 n+1 会发生什么，该请求是否需要几秒钟才能被授予，因为必须启动一个新的 Django 实例？或者谷歌的基础设施不能这样工作？我承认我对此一无所知。问题。
帮助！
是的，较长的启动时间是使用包含大量代码的框架的一个警告。目前，除了使用更轻量级的框架（例如内置的 webapp 框架）之外，没有其他方法可以绕过它们。
不建议轮询您的应用程序：它会用完配额，并且实际上并不能保证真正的用户请求会命中您的轮询请求所做的同一实例，因为应用程序在多个实例上运行。
幸运的是，有一个简单的解决方案：流行起来！您的应用越受欢迎，实例需要重启的频率就越低，它影响的用户比例就越小。
我尊重您正在尝试做的事情，但这对我来说听起来有点像未成熟的优化。您正在讨论的 py+django 补丁是 Google 推荐的，直到他们升级到“真正的”django，所以我无法想象它有那么糟糕。测试你所谈论的内容的性能也并不难，所以我建议你这样做并在做出最终决定之前先运行一些指标。这样，当其他人开始抱怨时，您将有一些数学来支持它；）
他们还在常见问题解答中提到使用 Django 的压缩版本将有助于加载时间，尽管我猜它可能仍然很长。至于您最初的问题，我同意其他人的观点，即轮询您的应用程序可能不是一个好主意，因为它可能无法解决您的问题，因为 Google 可能会将您的请求分发到多台机器等。
此外，在我看来（但如果我错了，尼克可以在这里纠正我）如果你使用内置的 Django（.97 或 1.0），加载问题就不那么严重了。从逻辑上讲，我会说他们将内置库保存在内存中供每个人使用，或者在实例之间共享缓存的代码。但我不确定。
参见松尾隆史的比较。基本上，对于几乎什么都不做的最简单的 app-engine-patch，他声称对于 webapp+Django 模板来说大约 1 秒，而大约 350 毫秒。
对于我们的应用来说，感觉比 1s 还要长，但 Takashi 只是尝试了他能想到的最简单的应用。