return nil
}

func (sys *BucketTargetSys) updateBandwidthLimit(bucket, arn string, limit int64) {
	if limit == 0 {
		globalBucketMonitor.DeleteBucketThrottle(bucket, arn)
		return
	}
	// Setup bandwidth throttling

	globalBucketMonitor.SetBandwidthLimit(bucket, arn, limit)
}

// RemoveTarget - removes a remote bucket target for this source bucket.

        return -1;
    }

    /**
     * Retrieves a list of access results from the data service for processing.
     * Filters out results that are too recent based on commit margin time and manages crawler throttling.
     *
     * @param cb the consumer to customize the search request
     * @param cleanupTime the time taken for the last cleanup operation
     * @return the list of access results ready for processing
     */

			Key:         config.SiteSubSys,
			Description: "label the server and its location",
		},
		config.HelpKV{
			Key:         config.APISubSys,
			Description: "manage global HTTP API call specific features, such as throttling, authentication types, etc.",
		},
		config.HelpKV{
			Key:         config.ScannerSubSys,
			Description: "manage namespace scanning for usage calculation, lifecycle, healing and more",
		},
		config.HelpKV{

      sink.writeUtf8(name)
      sink.writeUtf8(": ")
      sink.writeUtf8(value)
      sink.writeUtf8("\r\n")
    }
    sink.writeUtf8("\r\n")
    sink.flush()
  }

  /** Returns a sink that applies throttling and disconnecting. */
  private fun Sink.withThrottlingAndSocketEffect(
    policy: MockResponse,
    socketEffect: SocketEffect?,
    expectedByteCount: Long,
    socket: MockWebServerSocket,

	// rest of the `99*9` requests.
	//
	// This essentially splits the workload properly and also allows for network
	// utilization to be optimal, instead of blindly throttling the way we are
	// doing below. However the changes that are needed here are a bit involved,
	// further discussion advised. Remove this comment and remove the worker model
	// for this function in future.

- Fixed a 1.35.0 regression by disabling the `SchedulerAsyncAPICalls` feature gate. The regression was in scheduler performance, triggered by API client throttling. ([#135904](https://github.com/kubernetes/kubernetes/pull/135904), [@macsko](https://github.com/macsko)) [SIG Scheduling]

- Azure: fix concurreny issue in lb creation ([#89604](https://github.com/kubernetes/kubernetes/pull/89604), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
- Azure: per VMSS VMSS VMs cache to prevent throttling on clusters having many attached VMSS ([#93107](https://github.com/kubernetes/kubernetes/pull/93107), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider]

- Disabled `SchedulerAsyncAPICalls` feature gate due to performance issues caused by API client throttling. ([#135903](https://github.com/kubernetes/kubernetes/pull/135903), [@macsko](https://github.com/macsko)) [SIG Scheduling]

### **Instrumentation**

#### **Audit**

*   Adjust batching audit webhook default parameters: increase queue size, batch size, and initial backoff. Add throttling to the batching audit webhook. Default rate limit is 10 QPS. ([#53417](https://github.com/kubernetes/kubernetes/pull/53417),[ @crassirostris](https://github.com/crassirostris))

- Limit use of tags when calling EC2 API to prevent API throttling for very large clusters. ([#76749](https://github.com/kubernetes/kubernetes/pull/76749), [@mcrute](https://github.com/mcrute))