Django 实例在 Google App Engine 下启动
在思考如何制作快速且可扩展的 Web 应用程序相当长一段时间后，我几乎决定采用 Google App Engine、Python+Django 和 app-engine-patch 的组合。但我在app-engine-patch 常见问题解答 这让我觉得也许这个组合并不像我想象的那么成熟：启动 Django 实例可能需要几秒钟（根据常见问题解答，为 1-4 秒钟）。如果请求之间存在一定的持久性，这可能不是问题，但似乎当没有持续的流量时，Django 实例会在几秒钟内关闭。如果系统不是每隔一秒左右调用一次，任何传入的请求都将需要几秒钟（！）才能被授予。这是不可接受的。作为一个快速解决方案（我知道这很丑），我正在考虑让外部机器每秒向框架发出一个虚拟请求，以保持其活动。
你同意这一点吗？您还有其他方法吗？
我的另一个疑问是，如果有足够的流量从一台 n 服务器跳转到 n+1 台服务器，会发生什么，该请求是否需要几秒钟才能被授予，因为必须启动一个新的 Django 实例？或者谷歌的基础设施不是这样工作的？我承认我对此一无所知。问题。
帮助！
After thinking quite a while about how to make a fast and scalable web application, I am almost decided to go for a combination of Google App Engine, Python+Django, and app-engine-patch. But I came across a comment in the app-engine-patch FAQ that made me think that perhaps the combination is not quite as mature as I thought: it may take seconds (1-4, according to the FAQ) to boot an instance of Django. That may not be a problem if there is some persistance from request to request, but it seems that when there is no sustained traffic then the Django instance is shut down in a few seconds. If the system is not called every other second or so, any incoming request will take seconds(!) to be granted. This is unacceptable. As a quick fix (ugly, I know), I was thinking about having an external machine making a dummy request to the framework every second just to keep it alive.
Do you agree with this? Do you have any other approach?
Another doubt that I have is what will happen if there is enough traffic to jump from one n servers to n+1, will that request take seconds to be granted because a new Django instance has to be initiated? or Google's infrastructure doesn't work this way? I confess my ignorance on this. issue.
Help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
是的，启动时间长是使用包含大量代码的框架的一个警告。目前，除了使用更轻量级的框架（例如内置的 webapp 框架）之外，没有其他办法可以解决它们。
不建议轮询您的应用程序：它会耗尽配额，并且实际上并不能保证真正的用户请求到达轮询请求所执行的同一实例，因为应用程序在多个实例上运行。
幸运的是，有一个简单的解决方案：变得受欢迎！您的应用程序越受欢迎，需要重新启动的实例就越少，受影响的用户比例就越小。
Yes, long startup times are a caveat of using a framework with a lot of code. There's no way around them, currently, other than using a framework that is lighter-weight (such as the built in webapp framework).
Polling your app isn't recommended: It'll use up quota, and doesn't actually guarantee that the real user requests hit the same instance your polling requests did, since apps run on multiple instances.
Fortunately, there's a simple solution: Get popular! The more popular your app is, the less frequently instances need restarting, and the smaller a proportion of users it affects.
我尊重你正在尝试做的事情，但这对我来说听起来有点像不成熟的优化。您正在讨论的 py+django 补丁是 Google 推荐的，直到他们升级到“真正的”django，所以我无法想象它有那么糟糕。测试您所讨论的性能也并不难，因此我建议您这样做并在做出最终决定之前先对其运行一些指标。这样，当其他人开始抱怨时，你就会有一些数学来支持它；）
I respect what you are trying to do, but this sounds a little like pre-mature optimization to me. The py+django patch you are discussing is recommended by Google until they upgrade to "real" django so I can't imagine it's all that bad. It's also not that hard to test the performance of what you are talking about, so I suggest you do that and run a few metrics on it first before making your final decision. That way you'll have some math to back it up when someone else starts complaining ;)
他们还在常见问题解答中提到，使用 Django 的压缩版本将有助于缩短加载时间，尽管我猜测它可能仍然很长。至于你原来的问题，我同意其他人的观点，即轮询你的应用程序可能不是一个好主意，因为它可能无法解决你的问题，因为谷歌可能会在许多机器上分发你的请求，等等。
They also mention in the FAQ that using a zipped version of Django will help the load time, although I'm guessing it might still be long. As for your original question, I'd agree with others that polling your app is probably not a good idea because it likely won't solve your problem because Google may distribute your requests across many machines, etc, etc.
另外，在我看来（但如果我错了，尼克可以在这里纠正我），如果你使用内置的 Django（.97 或 1.0），加载就不成问题了。从逻辑上讲，我想说他们将内置库保留在内存中供每个人使用，或者在实例之间共享缓存的代码。但我不确定。
Also, it seems to me (but Nick can correct me here if I'm wrong) that if you use the built in Django (.97 or 1.0) the loading is less of a problem. Logically, I'd say they keep the built-in libs in memory for everyone, or share that cached code between instances. But I don't know for sure.
请参阅Takashi Matsuo 的比较 。基本上，对于几乎什么都不做的最简单的应用程序引擎补丁，他声称 webapp+Django 模板大约为 1 秒，而 webapp+Django 模板大约为 350 毫秒。
对于我们的应用程序来说，感觉比 1 秒还要长，但 Takashi 只是尝试了他能想到的最简单的应用程序。
See Takashi Matsuo's comparisons. Basically, for simplest app-engine-patch that does almost nothing, he claims about ~1s versus ~350ms for webapp+Django templates.
It feels like longer than 1s for our app, but Takashi just tried the very simplest app he could think of.