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 地址和子网的范围。