为什么Google地理编码即使在通话之间有结算和延迟也会提供OVER_QUERY_LIMIT？

时间：2017-04-12 04:34:08

标签： javascript google-maps google-maps-api-3

背景

我参与了一个涉及网站的项目，该网站据称在高峰负载时 200K +用户，使用纬度/经度对执行一些业务逻辑一个由用户提供的城市，而其UI要求他们在该城市中使用地址，这意味着网站需要将后者转换为前者，因此团队决定使用使用客户端Javascript的Google Maps Geocoding 。

由于他们认为他们的数据库不够强大来缓存结果，他们决定不要缓存任何，这意味着所有用户输入都会始终使用该API进行转换，因此我要求执行负载测试以使用Google API密钥测试其每日配额限制并启用结算。

设置

据我所知，还有一个速率限制，当任何一个限制点击时会抛出OVER_QUERY_LIMIT，我在其间增加了 1秒延迟地理编码API调用，意味着它将被称为每秒一次。当我返回OVER_QUERY_LIMIT时，我还添加了 30秒延迟，这意味着此类失败的请求只会在30秒后重试 。

我的测试结果如下：

  1. 连续410次成功通话 - ＆gt; OVER_QUERY_LIMIT - ＆gt;延迟30秒

  2. 连续78次成功通话 - ＆gt; OVER_QUERY_LIMIT - ＆gt;延迟30秒

  3. 连续20次成功通话 - ＆gt; OVER_QUERY_LIMIT - ＆gt;延迟30秒

  4. 连续16次成功通话 - ＆gt; OVER_QUERY_LIMIT - ＆gt;延迟30秒

  5. 连续12次成功通话 - ＆gt; OVER_QUERY_LIMIT - ＆gt;延迟30秒

  6. 不到10次连续成功通话 - ＆gt; OVER_QUERY_LIMIT - ＆gt;延迟30秒

  7. 最终达到加上30秒延迟实际上会降低吞吐量的程度

    8. 我还测试过，没有延迟30秒，在达到第一个OVER_QUERY_LIMIT时，后续调用在成功和OVER_QUERY_LIMIT之间交替，最终到在<1>成功与10+ OVER_QUERY_LIMIT 之间的替代点。

    此外，我已尝试将Geocoding API调用之间的延迟时间增加到 2秒，并在达到 60秒时达到OVER_QUERY_LIMIT，但结果是非常相似。虽然我可能会进一步显着增加这些限制，但这种增加很可能导致延迟变得<太长而不可行，所以我决定不再进行测试。

    虽然我无法披露调用API的代码，但他们基本上只使用 google.maps.Geocoder.geocode 功能，同时限制结果始终在那个城市。

    虽然他们不太关心结算，但我告诉他们他们应该准备转换到保费，我们也同意这样做不值得这样做现在只是为了测试每日配额限制。

    问题

    我已在此网站上阅读了Optimizing Quota Usage When Geocoding，What happens if I exceed the usage limits和许多类似的问题，但其中没有一个似乎甚至接近我案例，所以我想知道为什么，即使API调用和启用结算之间的延迟，实际测试结果甚至低于2500免费每日限制，让单独启用计费的100K一个？

    如果答案是负载测试本身滥用Google API ，那么还有其他方法可以确定Google API速率限制和每日配额限制确实非常可靠吗？ / p>

    修改

    我忘了提及当我刷新页面时，Google API调用将返回250-300个连续成功的结果，然后与之前的测试结果具有相同的行为 ，但我只会将清爽作为最后的手段。

    在检查API Manager Dashboard中的流量后，Google Maps JavaScript API只有几个请求（我认为这些是用于加载Google Map本身），而Google Maps Geocoding API根本没有请求，尽管我和＃39;今天已经通过 google.maps.Geocoder.geocode 调用了Google Geocoding API数千次。

    好像没有使用API​​密钥，但是浏览器返回了一条错误消息，告知我没有提供Google API密钥＆＃＆＃ 39;提供一个。

    现在浏览器根本没有返回任何错误消息，我只能认为Google API Key应该正常工作，而仪表板流量则表明相反。我不知道发生了什么以及任何帮助都非常感激。

    我已经使用了google.maps.version，它说我使用的是3.27.12版本。

2 个答案:

答案 0 :(得分：0)

经过几个小时的调查和与团队的讨论，我认为唯一可行的解​​决方案是使用客户端浏览器代码和服务器端Web服务代码的组合。

然后大多数请求将在客户端处理，但是对于返回OVER_QUERY_LIMIT的请求，它们将在服务器端重试。

这是因为根据我在互联网上阅读的内容（尤其是this one），客户端API调用的主要障碍是速率限制，而服务器端API调用的主要障碍是每日限制。

根据上述组合，每日限制将主要通过客户端API调用来缓解，而速率限制将主要通过服务器端API调用来缓解，这意味着它们有效地覆盖了彼此'限制

尽管如此，我仍然怀疑是否有更好的方法实际上解决了根本原因，而不是试图避免这个问题，同时使事情变得非常复杂。

答案 1 :(得分：-1)

我一直遇到OVER_QUERY_LIMIT，即使将其重置为更高的数字后，错误仍然存​​在。然后，我意识到我有多个配额，即使我使用的是地理编码api的单一方法。 Google配额概述中列出了配额，您需要向下滚动才能看到更多配额。

傻，但是嘿，可能会节省一些时间。

相关问题
最新问题