管理应用资源

App Engine 会生成关于应用性能和资源利用率的使用情况报告。下面列出了可更有效地管理资源的潜在策略。如需了解详情,请参阅价格页面。

查看使用情况报告

在评估应用性能时,您应该检查应用运行的实例数以及应用的资源消耗情况。

查看信息中心使用情况报告

查看“实例”页面

以下部分推荐了一些资源管理策略。

管理动态实例调节

缩短延迟时间

应用延迟时间会影响处理流量所需的实例数。您可以通过缩短延迟时间来减少用于处理应用的实例数。Cloud Trace 是一种实用的工具,不但可用于查看有关延迟时间的数据,还可让您了解有助于缩短延迟时间的可行更改措施。

使用 Cloud Trace 查看延迟时间后,请尝试采用下面一些策略来减少延迟时间:

  • 增大频繁访问的共享数据的缓存 - 换句话说,就是使用 App Engine Memcache。此外,设置应用的 Cache-Control 标头会对服务器和浏览器缓存数据的效率产生重大影响。即使缓存几秒钟也会对应用处理流量的效率产生影响。
  • 更高效地使用 App Engine Memcache - 以批量调用的方式执行 get、set、delete 等操作,而不是执行一系列单独的调用。请考虑使用 Memcache Async API
  • 将任务用于非请求绑定功能 - 如果您的应用执行的工作可以超出面向用户的请求范围,请将此工作放入任务中!将此工作发送到任务队列而不是等待此工作完成再返回响应,这样可以显著缩短面向用户的延迟时间。随后,您可以借助任务队列更好地控制执行速率并调节负载。
  • 更高效地使用 Datastore 模式的 Firestore (Datastore) - 如需了解详情,请参阅下文。
  • 并行执行多个 URL Fetch 调用
    • 批量处理多个 URL Fetch 调用,而不是在单个面向用户的请求中单独处理调用,然后通过异步 URL Fetch 在离线任务中并行处理调用。
    • 使用异步 URL Fetch API
  • 对 HTTP 会话采用异步写入方式 - 在 Java 中,您可以通过将 <async-session-persistence enabled="true"/> 添加到 appengine-web.xml,将应用配置为向 Datastore 异步写入 HTTP 会话数据。始终会将会话数据同步写入 App Engine Memcache;如果请求尝试在 App Engine Memcache 不可用时读取会话数据,则会将其故障切换到可能尚没有最新更新的 Datastore。这意味着您的应用有可能会看到过时的会话数据,但对于大多数应用而言,延迟时间的优势远远超过风险。

更改自动调节性能设置

您可以使用 appengine-web.xml 配置文件包含的数种设置,针对您的应用的特定版本,在性能和资源负载之间权衡取舍。如需获取可用自动扩缩设置的列表,请参阅扩缩元素。如需了解这些设置的效果,请观看 App Engine 新调度器设置视频。

在 Java 中启用并发请求

启用此设置将减少处理应用流量所需的实例数,但您的应用必须具备线程安全性才能使此设置正常运行。了解如何通过在 appengine-web.xml 文件中启用线程安全来使用并发请求。

配置任务队列设置

任务队列的默认设置已针对性能进行了调整。如果采用这些默认设置,当您将多个任务同时放入队列时,这些任务可能会导致新的前端实例启动。下面提供了一些有关如何调整任务队列以节省实例小时数的建议:

  • 为对延迟时间不敏感的任务设置 X-AppEngine-FailFast 标头。如果现有实例不可用,则此标头会指示调度器立即使请求失败。任务队列将重试并执行退避,直到现有实例可用于处理请求为止。但请务必注意,如果设置了 X-AppEngine-FailFast 的请求占用现有实例,则没有设置该标头的请求仍可能会导致新实例启动。
  • 配置任务队列的设置
    • 如果将“rate”参数设置为较小的值,则任务队列将以较慢的速率执行您的任务。
    • 如果将“max_concurrent_requests”参数设置为较小的值,则同时执行的任务会比较少。

尽可能传送静态内容

Java 中的静态内容传送由专用的 App Engine 基础架构处理,因此不会消耗实例小时数。如果您需要设置自定义标头,请使用 Blobstore API。Blob 响应的实际传送不会消耗实例小时数。

管理应用存储空间

App Engine 会根据 Datastore 中实体的大小、Datastore 索引的大小、任务队列中的任务大小以及 Blobstore 中存储的数据量来计算存储空间费用。您可以执行以下操作来确保仅存储必要的数据:

  • 删除应用不再需要的任何实体或 Blob。
  • 移除所有不必要的索引,以降低索引存储空间费用(请参阅下面的“管理 Cloud Datastore 使用情况”部分)。

管理 Datastore 使用情况

App Engine 会考虑 Datastore 中执行的操作次数。使用如下所列的一些策略,可以减少 Datastore 资源使用量,以及缩短向 Datastore 发送的请求的延迟时间:

  • Google Cloud 控制台数据查看器会显示在您的本地 Datastore 中创建每个实体所需的写入操作次数。您可以使用此信息来了解写入每个实体的费用。如需了解如何解读此数据,请参阅了解写入费用
  • 移除所有不必要的索引,这将减少存储空间费用和实体写入费用。使用“获取索引”功能查看针对您的应用定义的索引。您可以在 Google Cloud 控制台“搜索”页面中查看当前用于您的应用的索引。
  • 设计数据模型时,您或许可以通过完全避免使用自定义索引的方式来编写查询。如需详细了解 App Engine 如何生成索引,请阅读查询和索引文档。
  • 尽可能将已编入索引的属性(默认值)替换为没有编入索引的属性 (Java),这将减少您在放入实体时 Datastore 执行的写入操作次数。请注意,如果您日后决定确实需要能够查询未编入索引的属性,则不仅需要修改代码以再次使用已编入索引的属性,而且还必须针对所有实体运行 map reduce 以重新放入这些实体。
  • 由于在 App Engine 1.5.2 和 1.5.3 版本中改进了 Datastore 查询规划器,因此与以前相比,您的查询现在可能需要更少的索引。出于性能原因,您可能仍会选择保留某些自定义索引,但建议您删除其他自定义索引,以便降低存储空间费用和实体写入费用。
  • 重新配置您的数据模型,以便将查询替换为按键提取,从而节省费用并提高效率。
  • 尽可能使用仅限于键的查询来取代实体查询。
  • 如需缩短延迟时间,请将多个实体 get() 替换为批量 get()
  • 使用 Datastore 游标(而不是偏移)进行分页。
  • 通过 Async Datastore API 并行处理多个 Datastore RPC。

注意:Datastore 小规模操作包括用于分配 Datastore ID 的调用操作或仅限于键的查询。如需详细了解费用,请参阅价格页面。

管理带宽

如需减少传出带宽,您可以在响应中设置适当的 Cache-Control 标头并为静态文件设置合理的到期时间。如果以这种方式使用公共 Cache-Control 标头,代理服务器和客户端浏览器就可以在指定的时间段内缓存响应。

传入带宽是您的用户发送到您的应用的数据量,因此较难控制。但是,您可以使用 App Engine 防火墙规则来允许或限制 IP 地址和子网的范围。

管理其他资源

审核 Email API 使用情况的一项最佳策略是使用 Cloud Trace 来确保仅执行必要的调用。建议您务必检查错误率,并留意您可能正在进行的任何无效调用。在某些情况下,或许可以尽早发现这些无效的调用。