[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[[["\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)."]]
