【问题标题】:Translate API User Rate Limit Exceeded [403] without reason无故翻译 API User Rate Limit Exceeded [403]
【发布时间】:2015-11-24 09:19:05
【问题描述】:

我通过带有付费服务的“Google.Apis.Translate.v2”版本 1.9.2.410 使用带有 C# 代码的谷歌翻译 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] ]

在此之前,从来没有。我的极限是: 总配额 50 000 000 个字符/天 剩余
49 344 849 个字符/天 98,69 % 总数 每用户限制
100 个请求/秒/用户

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

【问题讨论】:

    标签: c# google-translate


    【解决方案1】:

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

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

    简单例子:

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

    我建议始终捕获异常,并重试多次执行指数退避。这个想法是,如果服务器由于达到 100 秒间隔配额而暂时关闭,它不会被同时击中的请求淹没,直到它恢复(因此连续返回 403 错误)。您可以查看此做法的简要说明 here(该示例侧重于 Drive API,但相同的概念适用于每个基于云的服务)。

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

    【讨论】:

    • 此解决方案不起作用。因此它有效,但只是部分有效。错误计数略少,但仍然有很多。整个解决方案,即使工作是无用的,因为那样翻译时间太长了。
    • 我编辑了我的评论以更好地阐明行为。你想翻译什么?如果您正在分析大段落,是否适合将它们拆分为较小的请求?
    猜你喜欢
    • 1970-01-01
    • 2013-12-15
    • 1970-01-01
    • 2016-02-14
    • 2015-11-22
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-01-03
    相关资源
    最近更新 更多