毫无疑问地超过了API用户速率限制[403] [英] Translate API User Rate Limit Exceeded [403] without reason

问题描述

我通过带有付费服务的"Google.Apis.Translate.v2"版本1.9.2.410使用带有C#代码的google translation API.

代码类似于:

var GoogleService = new Google.Apis.Translate.v2.TranslateService(
 new BaseClientService.Initializer
{
    ApiKey = Context.ConfigData.GoogleApiKey,
    ApplicationName = "Translator"
});
...

  var rqr = GoogleService.Translations.List(item, 'de');
  rqr.Source = "cs";

  var result = await rqr.ExecuteAsync();

此代码带有异常:

超出用户速率限制[403]错误[消息[用户速率限制 超出]位置[-]原因[userRateLimitExceeded] 域[usageLimits]]

在此之前，从来没有.我的极限是: 配额总数 每天5亿个字符 剩余
每天49344849个字符 占总数的98,69％ 每用户限制
每用户每秒100个请求

请求数肯定少于每秒100个请求 请怎么了?

解决方案

Translate API现有未记录的配额.此配额将每位用户每100秒的字符数限制为10,000(又名10,000个字符/100秒/用户).

这意味着，即使您将大文本分成不同的请求，也无法在100秒的间隔内绕过10,000个字符.

简要示例:

• 如果在前5秒内绕过1万个字符，则需要等待95秒才能继续分析字符.
• 如果您在50秒后达到此配额，则需要再等待50秒.
• 如果您在第99秒钟击中它，则需要等待1秒钟才能继续工作.

我建议始终捕获异常，然后重试多次以进行指数补偿.这个想法是，如果服务器由于达到100秒的间隔配额而暂时关闭，则直到它恢复正常(直到连续返回403错误)，它才不会被同时命中的请求所淹没.您可以在此处看到对此做法的简要说明(此示例着重于在Drive API上使用，但相同的概念适用于每个基于云的服务.

或者，您可以捕获异常，并且每当遇到403错误时，请应用100秒的延迟，然后重试.这不是最省时的解决方案，因为100秒的间隔是连续的(达到配额后不会开始)，但是它将确保您不会因相同的请求而两次达到限制.

I use google translate API with C# code via "Google.Apis.Translate.v2" version 1.9.2.410 with paid service.

Code is some like:

var GoogleService = new Google.Apis.Translate.v2.TranslateService(
 new BaseClientService.Initializer
{
    ApiKey = Context.ConfigData.GoogleApiKey,
    ApplicationName = "Translator"
});
...

  var rqr = GoogleService.Translations.List(item, 'de');
  rqr.Source = "cs";

  var result = await rqr.ExecuteAsync();

This code take Exception:

User Rate Limit Exceeded [403] Errors [ Message[User Rate Limit Exceeded] Location[ - ] Reason[userRateLimitExceeded] Domain[usageLimits] ]

Before that, it never was. My limit it's: Total quota 50 000 000 characters/day Remaining
49 344 849 characters/day 98,69 % of total Per-user limit
100 requests/second/user

The number of requests is certainly less than 100 request per second Please what's wrong?

解决方案

There is an existing undocumented quota for Translate API. This quota limits the number of characters per 100 seconds per user to 10,000 (aka 10,000 chars/100seconds/user).

This means that, even if you’re splitting large texts into different requests, you won’t be able to bypass 10,000 characters within a 100-seconds interval.

Brief examples:

• If you bypass 10k characters within the first 5 seconds, you will need to wait 95 seconds to continue analyzing chars.
• If you hit this quota after 50 seconds, you will need to wait another 50.
• If you hit it on the second 99th, you will need to wait 1 second to continue the work.

What I would recommend is to always catch exceptions, and retry a number of times doing an exponential backoff. The idea is that if the server is down temporarily due to hitting the 100-seconds interval quota, it is not overwhelmed with requests hitting at the same time until it comes back up (and therefore returning 403 errors continuously). You can see a brief explanation of this practice here (the sample is focused on Drive API, but the same concepts apply to every cloud-based service).

Alternatively, you could catch exceptions, and whenever you get a 403 error, apply a delay of 100 seconds and retry again. This won't be the most time-efficient solution, as the 100-seconds intervals are continuous (not started when the quota is reached), but it will assure that you don’t hit the limit twice with the same request.

这篇关于毫无疑问地超过了API用户速率限制[403]的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！