Google App Engine何时启动或停止一个实例?

huangapple go评论90阅读模式
英文:

When does Google App Engine start or stop an instance?

问题

我们有一个App Engine应用程序,平均处理每秒0.5个请求,似乎所有这些请求都可以由运行Go应用程序作为主版本的同一个实例处理。

然而,有时候App Engine会启动第二个实例(甚至第三个实例),这些实例似乎在处理一两个请求后就不再做任何事情。以下是一个例子。

关闭该实例并不会造成任何损害,所以我的问题是,为什么App Engine在一段时间内没有收到任何请求后不会杀死该实例?(上面的例子在过去一个小时内有四个请求,通常请求/时间比例甚至更低)。

更新:

类似的情况是当一个实例在不同的版本上启动时。App Engine似乎只在多个小时没有收到任何请求后才会杀死该实例。

在应用程序设置→性能下,

  • 空闲实例设置为自动-20
  • 挂起延迟设置为150ms-250ms
英文:

We have an App Engine app that handles an average .5 requests per second, and seemingly all those requests can be handled by the same instance running a Go app as the main version.

However, sometimes App Engine kicks off a second instance (and sometimes even a third one), that doesn't seem to do anything past handling one or two requests. Here's an example.

Google App Engine何时启动或停止一个实例?

Shutting down that instance manually doesn't seem to cause any harm, so my question is, why does App Engine not kill the instance after it did not get any requests for a while? (The above example had four requests in the past hour, often the requests/age ratio gets even lower).

Update:

A similar situation is when an instance is started on a different version. App Engine only seems to kill the instance after hours of not getting any requests.

Under Application Settings → Performance,

  • Idle Instances is set to Automatic – 20
  • Pending Latency is set to 150ms – 250ms

答案1

得分: 4

我希望我知道是什么控制着何时/是否会终止空闲实例,但我看不到任何相关的文档。

为了避免过多的实例启动,我认为你可以做的主要事情是增加挂起延迟

> 挂起延迟滑块控制请求在等待队列中等待多长时间,然后由应用程序的默认版本的实例提供服务。如果最小挂起延迟较高,App Engine将允许请求等待而不是启动新的实例来处理它们。这可以减少应用程序使用的实例小时数,但可能会导致更多用户可见的延迟。

即使你平均每小时只有4个请求,如果恰好有两个请求间隔很短,可能会启动一个新的实例。

你还可以在日志中看到一些关于为什么启动新实例的少量信息。

英文:

I wish I knew what controls if/when it kills idle instances, but I can't see any documentation of it.

To avoid excess instances starting, I think the main thing you can do here is increase the pending latency:

> The Pending Latency slider controls how long requests spend in the pending queue before being served by an Instance of the default version of your application. If the minimum pending latency is high App Engine will allow requests to wait rather than start new Instances to process them. This can reduce the number of instance hours your application uses, but can result in more user-visible latency.

Even if you only average 4 requests/hour, if you happen to get two closely spaced I suppose it's possible it would start a new instance.

You can also see some small amount of information in the logs about why it started a new instance.

答案2

得分: 2

"应用程序如何扩展"部分的Google App Engine文档中提到:

实例的扩展

每个实例都有自己的请求队列。App Engine监控每个实例队列中等待的请求数量。如果App Engine检测到由于负载增加而导致应用程序队列过长,它会自动创建一个新的应用程序实例来处理该负载。

当请求量减少时,App Engine也会反向扩展实例。这种扩展有助于确保您应用程序的所有当前实例都能以最佳效率和成本效益的方式使用。

文档还提到您可以"指定最小空闲实例数",并在管理控制台中"优化高性能或低成本"。

尝试将"空闲实例"字段设置为3-5,并选择"优化低成本",看看是否会影响实例的关闭时间。

英文:

The "How Applications Scale" section of the Google App Engine documentation states:

Scaling in Instances

Each instance has its own queue for incoming requests. App Engine monitors the number of requests waiting in each instance's queue. If App Engine detects that queues for an application are getting too long due to increased load, it automatically creates a new instance of the application to handle that load.

App Engine also scales instances in reverse when request volumes decrease. This scaling helps ensure that all of your application's current instances are being used to optimal efficiency and cost effectiveness.

It also states you can "specify a minimum number of idle instances", and to "optimize for high performance or low cost" in the administration console.

Try setting the "Idle instances" field to something like 3 - 5, and "optimize for low cost" and see if that affects the instance kill time.

huangapple
  • 本文由 发表于 2013年7月23日 21:05:27
  • 转载请务必保留本文链接:https://go.coder-hub.com/17811046.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定