javascript - 为什么Google Geocoding即使在计费和通话之间存在延迟的情况下仍能提供OVER_QUERY_LIMIT？

Question

背景

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

由于他们认为自己的数据库不够强大，无法缓存结果，因此他们决定不缓存任何内容，这意味着所有用户输入都将始终使用该API进行转换，因此，我被要求执行负载测试以每天对其进行测试启用Google API密钥和计费的配额限制。

设定

据我所知，还有一个速率限制，当达到任何一个限制时都会抛出OVER_QUERY_LIMIT，我在Geocoding API调用之间添加了1秒的延迟，这意味着每秒将调用一次。当返回OVER_QUERY_LIMIT时，我还添加了30秒的延迟，这意味着此类失败的请求将仅在30秒后重试。

我的测试结果如下：


连续410次成功呼叫-> OVER_QUERY_LIMIT->延迟30秒
连续78次成功呼叫-> OVER_QUERY_LIMIT->延迟30秒
连续20次成功通话-> OVER_QUERY_LIMIT->延迟30秒
连续16次成功通话-> OVER_QUERY_LIMIT->延迟30秒
连续12次成功呼叫-> OVER_QUERY_LIMIT->延迟30秒
少于10次连续成功呼叫-> OVER_QUERY_LIMIT-> 30秒延迟
最终达到了增加30秒延迟实际上会降低吞吐量的地步


我还测试了，在没有第30个延迟的情况下，到达第一个OVER_QUERY_LIMIT时，后续调用只是在成功和OVER_QUERY_LIMIT之间交替，最终使它在1个成功和10个以上OVER_QUERY_LIMIT之间交替。

此外，我尝试将Geocoding API调用之间的延迟增加到2秒，而将OVER_QUERY_LIMIT上的延迟增加到60秒，但是结果令人惊讶地相似。尽管我可能还希望进一步显着增加这些限制，但是这种增加很可能会导致延迟变得太长而无法实现，因此我决定不再进行测试。

尽管我无法公开调用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速率限制和每日配额限制的确高度可靠吗？

编辑

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

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

好像没有使用API​​密钥，但是浏览器返回了一条错误消息，当我不提供API密钥时，没有提供Google API密钥。

由于现在浏览器根本不返回任何错误消息，我只能认为Google API密钥应该可以正常工作，而仪表板流量却恰恰相反。我不知道发生了什么，也非常感谢任何帮助。

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

Answer 1

在与团队进行了数小时的调查和讨论之后，我认为唯一可行的解​​决方案是结合使用客户端浏览器代码和服务器端Web服务代码。

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

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

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

尽管如此，我仍然想知道是否还有更好的方法可以真正解决根本原因，而不是在使事情变得非常复杂的同时避免发生此问题。