这两种实现方式都能在 24 小时内高效利用配额。如果请求在 24 小时内持续大幅超出默认配额，则可以为 Cloud Healthcare API 服务分配更大的资源池。额外资源分配仅根据请求进行，并根据具体情况确定。
资源用量保持一致有助于 Google Cloud 更轻松地了解您的配额要求，并为您提供所需的配额。
为了有效管理容量和配额，您需要了解组织的容量需求。如果您正在规划容量需求，并且认为 Google Cloud 项目投入生产后需要大幅增加配额，请向Google Cloud 客户服务申请增加配额。在 Google Cloud 项目的测试和发布阶段，客户服务团队可以协助您分配和增加配额。
您无需拥有付费 Customer Care 服务即可申请增加配额。部分配额增加请求会在 2-3 个工作日内完成，但我们建议您预留更长的时间。如果您的配额增加幅度较大，则可能需要 10 个工作日或更长时间才能完成配额增加请求。规划的一部分必须包括分配时间来回复客户服务团队，以解决有关请求的任何问题或未解决的问题。如果您确保初始配额增加请求足够详细，或许可以缩短等待请求得到满足的时间。
预测配额需求的最佳实践
在 Google Cloud 项目投入生产之前，请预测并规划您需要的配额。规划配额需求可防止日后资源消耗意外受到限制。
以下部分将介绍规划配额时需要考虑的事项。
预测所有数据存储区和客户端的总用量
了解所有 Cloud Healthcare API 数据存储区的总使用量，以及向您的Google Cloud 项目发出请求的所有客户端的总使用量。
某些 Google Cloud 项目实现了多个 Cloud Healthcare API 使用场景。例如，您的 Google Cloud 项目可能会使用多个 Cloud Healthcare API 数据集和数据存储区来存储不同类型的数据，从而增加您的总配额用量。
配额按Google Cloud项目和区域强制执行。确保您在多个区域准确衡量了所需的配额。如果您有多个 Google Cloud 项目，可能需要更准确地衡量各个项目的效果。如需详细了解如何规划各区域的配额，请参阅预测各区域的用量。
Cloud Healthcare API 不会在客户端、数据集或数据存储区之间进行配额负载平衡。客户端必须确定是否实现优先级划分方案，以确保最关键的流量不会遇到 429 RESOURCE_EXHAUSTED 错误。
预测每个区域的用量
Cloud Healthcare API 按Google Cloud项目和区域衡量配额。配额通常按分钟计算，这样一来，每秒的小幅请求高峰就可以在每分钟的范围内得到平衡。
如果您的 Google Cloud 项目使用多个区域，您可以设置每个区域的配额。
如果您的 Cloud Healthcare API 数据集位于 us 多区域位置，并且您想申请增加配额，请在配额申请中说明该配额适用于“美国元区域”。us 多区域位置包含以下子区域：
us-central1
us-east1
us-west1
如果您已在任何 us- 子区域中使用配额产生 Cloud Healthcare API 流量，请务必在为 us 多区域提出配额增加请求时，将这些子区域中的现有流量考虑在内。例如，如果您在 us-central1 和 us 中都有数据集，并且您在 us 中申请增加配额，请在申请中指明您在 us-central1 中有数据集。
持续偏好低交易量
以下情形说明了持续发送少量流量的重要性，而不是发送交易间隔时间较长的大量交易。
流量量的计算公式为 request payload * time = traffic volume。
高容量交易是指在短时间内向 Cloud Healthcare API 发送的一个或多个包含大型载荷的请求。如果短时间内发送了大量请求，无论载荷大小如何，一系列请求也可视为大容量。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-25。"],[[["\u003cp\u003eThis page outlines best practices for managing Cloud Healthcare API quotas, especially for projects with high traffic volumes that exceed the default quotas.\u003c/p\u003e\n"],["\u003cp\u003eManaging quota involves monitoring usage through the Service Quota Model, which accounts for admin, producer, and consumer overrides to accurately assess available quota.\u003c/p\u003e\n"],["\u003cp\u003eImplementing exponential backoff and client-side rate limiting can reduce overall quota needs by spreading out load spikes and ensuring efficient resource utilization over time.\u003c/p\u003e\n"],["\u003cp\u003eBefore requesting additional quota, users should anticipate their total usage across all data stores and clients, as well as per-region requirements, since quotas are enforced per-project and per-region.\u003c/p\u003e\n"],["\u003cp\u003eFavoring consistent, low-volume transactions over infrequent, high-volume bursts helps avoid \u003ccode\u003e429 RESOURCE_EXHAUSTED\u003c/code\u003e errors and resource contention, leading to more stable operations.\u003c/p\u003e\n"]]],[],null,["# Quota management best practices\n\nThis page describes best practices for managing Cloud Healthcare API\n[quota](/docs/quotas/overview). Use this page if your Google Cloud project has, or might\nhave, a large amount of traffic and you need more quota than what the\nCloud Healthcare API provides by default.\n\nCloud Healthcare API default quotas\n-----------------------------------\n\nThe [default Cloud Healthcare API quotas](/healthcare-api/quotas)\naren't designed for all use cases, particularly if your Google Cloud project\nhas a large amount of traffic. The Cloud Healthcare API\ndoesn't automatically grow quota. You must plan and monitor your quota usage.\n\nBest practices for monitoring and viewing quota\n-----------------------------------------------\n\nThere are several methods for [viewing your quota usage](/docs/quotas/view-manage).\nWhen estimating and viewing quota for the Cloud Healthcare API, we recommend\nthat you use the [Service Quota Model](/service-usage/docs/service-quota-model).\nThe model lets you accurately assess the available quota you have based on the\nfollowing criteria:\n\n- Whether an *admin override* is present. A principal granted the [Quota Administrator](/iam/docs/understanding-roles#servicemanagement.quotaAdmin) role in an organization can apply an admin override to quota in Google Cloud projects within the organization. An admin override supersedes default limits and producer overrides.\n- Whether a *producer override* is present. A service owner grants a producer override\n to a consumer of a service. Google Cloud is the\n service owner of the Cloud Healthcare API service. Any quota\n override that Google Cloud provides is a producer override.\n\n | **Important:** Admin overrides supersede producer overrides. If you have been granted additional quota using a producer override, but you have an existing admin override, the producer override might not take effect.\n- Whether a *consumer override* is present. Someone who makes requests to the\n Cloud Healthcare API is a consumer of the Cloud Healthcare API service. You can\n apply consumer overrides for various situations, such as limiting quotas in your\n Google Cloud project as a cost-control measure to prevent going over your\n budget.\n\nIf you have any of these overrides in effect, you can [compute your consumer quota limit](/service-usage/docs/service-quota-model#computing_quota_limit)\nto get an accurate assessment of your available quota.\n\nBest practices for requesting additional quota\n----------------------------------------------\n\nGoogle Cloud has procedures to\n[request a higher quota value](/docs/quotas/help/request_increase).\nTo learn how quota adjustment requests are processed, see\n[About quota adjustments](/docs/quotas/overview#about_increase_requests).\n\nBefore requesting additional quota, ensure that you've implemented\nboth of the following:\n\n- [Exponential backoff](/healthcare-api/docs/best-practices-data-throughput#use-exponential)\n- [Client-side rate limiting](/healthcare-api/docs/best-practices-data-throughput#implement-client-side)\n\nThese implementations might reduce the amount of quota you require for the\nfollowing reasons:\n\n- Both implementations spread load spikes out across several hours or minutes, rather than seconds.\n- Both implementations make efficient use of quota over a 24 hour period. If requests that significantly exceed the default quota are consistent over a 24 hour period, larger pools of resources can be allocated to the Cloud Healthcare API service. The additional allocation of resources is by request only and is determined on a case-by-case basis.\n- Consistent resource usage makes it simpler for Google Cloud to understand your quota requirements and provide you with the quota you need.\n\nTo manage your capacity and quota effectively, you need to know your\norganization's capacity requirements. If you're planning your capacity requirements\nand think that you'll need a large quota increase when your Google Cloud project is in production,\nrequest an increase from [Google Cloud Customer Care](/support). Customer\nCare can assist you with allocating and increasing quota during the testing\nand rollout phases of your Google Cloud project.\n\nYou don't need to have a paid Customer Care service to request a quota increase.\nSome quota increase requests are completed within 2-3 business days, but\nwe recommend that you plan for longer. If your quota increase is large, it can take 10 business days or\nmore for the quota increase request to be completed. Part of your planning\nmust involve allocating time to respond to Customer Care to resolve any questions\nor open issues about the request. If you ensure that your initial quota increase\nrequest is sufficiently detailed, you might be able to reduce the time spent\nwaiting for the request to be fulfilled.\n\nBest practices for anticipating quota needs\n-------------------------------------------\n\nBefore your Google Cloud project goes into production, anticipate and plan\nfor how much quota you will need. Planning your quota requirements prevents\nunexpected limiting of your resource consumption later.\n\nThe following sections explain what to consider\nwhen planning for quota.\n\n### Anticipate total usage for all data stores and clients\n\nUnderstand your total usage across all Cloud Healthcare API [data stores](/healthcare-api/docs/concepts/projects-datasets-data-stores#datasets_and_data_stores),\nand understand the total usage of all clients that make requests to your\nGoogle Cloud project.\n\n- Some Google Cloud projects implement multiple Cloud Healthcare API use cases. For example, your Google Cloud project might use multiple Cloud Healthcare API datasets and data stores for different types of data, thus increasing your total quota usage.\n- Quotas are enforced on a per-Google Cloud-project and per-region basis. Ensure that you have accurate measurements of your required quota across multiple regions. If you have multiple Google Cloud projects, you might need more accurate measurements across the projects. For more information on planning for quota per-region, see [Anticipate per-region usage](#anticipate-region-usage).\n- The Cloud Healthcare API doesn't load balance quota across clients, datasets, or data stores. The client must determine whether to implement a prioritization scheme to ensure that the most critical traffic doesn't encounter `429 RESOURCE_EXHAUSTED` errors.\n\n### Anticipate per-region usage\n\nCloud Healthcare API measures quotas at a per-Google Cloud-project and per-region basis. Quotas\nare typically measured per minute, which allows for small spikes of requests\nper second to balance out on a per-minute scale.\n\nIf your Google Cloud project uses multiple regions, you can set per-region\nquotas.\n\nIf your Cloud Healthcare API dataset is in the [`us`](/healthcare-api/docs/concepts/regions#multi-regional_locations)\nmulti-regional location, and you want to request additional quota, state\nin your quota request that the quota is for the \"US meta region\". The `us`\nmulti-regional location consists of the following subregions:\n\n- `us-central1`\n- `us-east1`\n- `us-west1`\n\nIf you already have Cloud Healthcare API traffic using quota in any of the\n`us-` subregions, ensure that you take the existing traffic in those subregions\ninto account when making a quota increase request for the `us` multi-region.\nFor example, if you have datasets in `us-central1` and `us`,\nand you request a quota increase in `us`, specify in your request that you\nhave datasets in `us-central1`.\n\n### Favor low-volume transactions on a consistent basis\n\nThe following scenario explains the importance of\nsending smaller amounts of traffic on a consistent basis instead of sending\nhigh-volume transactions with a longer interval between transactions.\n\nTraffic *volume* is calculated using the formula `request payload * time = traffic volume`.\nA *high-volume* transaction is one or more requests to the\nCloud Healthcare API in a short interval that contain a large payload.\nA series of requests can also be considered *high-volume* if there are\nmany requests sent over a short interval, regardless of the payload size.\n\nSuppose that a client collects high-volume transactions and sends the\ntransactions to the Cloud Healthcare API in a burst every five minutes. The\nfollowing occurs:\n\n1. The initial burst of traffic consumes quota in the first minute (dependent on minute rollovers) until all quota is exhausted.\n2. Any remaining burst traffic receives `429 RESOURCE_EXHAUSTED` errors. If configured, all affected requests encounter exponential backoff.\n3. Some percentage of requests that encountered the initial exponential backoff are rescheduled to be tried again in the next minute. Some requests are attempted multiple times in a single minute, and then are retried the next minute.\n4. If the request volume is high enough, retried requests might encounter `429 RESOURCE_EXHAUSTED` errors and exponential backoff again. Certain bursts of traffic might encounter exponential backoff at different times, and the attempts to send traffic again might converge on the same minute in the future.\n5. If the request volume is still high, some traffic is retried when the next burst of traffic begins. The issue is exacerbated because more traffic is added to the existing backlog of requests. Your application might have difficulty maintaining the backlog of requests and sending them consistently to the Cloud Healthcare API.\n\nThis scenario shows the importance of knowing the volume of your traffic on\na per-minute basis. Implement your traffic volume and backoffs to prevent\nnetwork congestion and ensure that your application doesn't encounter\nmany failures that require retries.\n\nReview DICOM and FHIR quotas\n----------------------------\n\nTo view the Cloud Healthcare API quotas associated with\nFHIR and DICOM stores and operations, see [Quota limits](/healthcare-api/quotas#quota-limits)."]]
