历史上的高错误率会导致Google日历API超时吗？

Question

在最近一个月或者更长的时间里，我们看到读取超时错误率大幅飙升，以至于我们似乎无法弄清楚。我们研究过DNS缓存（确保我们没有打到陈旧的A记录），我们尝试过不同的HTTP传输（如 ApacheHttpTransport 和 NetHttpTransport)，我们已经玩过5s、20s(默认)和60s的超时范围。

这似乎并不重要：任何写操作（我们大量使用了 PATCH)似乎有大约30-40%的机会导致超时。这种情况似乎发生在我们所有的用户身上（1000多个，所以这不是孤立的，只是一些Google账户）。我们利用指数后退，99.9%的时间我们的请求最终都能通过，但延迟对我们的用户来说是令人沮丧的。我们还利用了 If-Match 尽可能地使用头文件。

我已经想不出是什么原因造成的了。虽然我们在一月份首次推出产品时偶尔会出现超时和500错误，但我们没有观察到任何接近这种程度的失败。

我确实想到了一个想法：由于我们产品的性质，我们可以进行大量的API调用，从而导致各种错误。例如，我们经常发出删除事件请求，却不知道是否已经删除，导致 "410走了 "的响应。

那么......如果你进行了太多它不喜欢的调用，Google的API会不会对你进行 "惩罚"，而不是限制我们的速率或者发送一些其他结构化的错误，而是直接决定超时结束socket？

Answer 1

我发现我的苦恼的原因，这是一个duozy。在尝试了不同的账户和用户代理头以及任何可以排除我们的特定请求有问题的东西之后，我就完全换了一个不同的客户端库。

经过大量的试验和错误，我把问题缩小到Google日历API官方客户端库默认为外发请求启用GZIP压缩。当我把这个功能关闭后，突然间一切都超级顺畅了。

证据A。

显然我认为一般情况下，如果能在两个方向上都有gzip压缩功能，那就太棒了。但如果它导致我所看到的那种头痛的情况，就不会了! 我们会向Google提交一份bug报告。我的直觉是，在某些情况下，Content-Length头可能会被稍微设置错误，导致请求被挂起。奇怪的是，用相同的有效载荷重试也能正常工作，但我想每次都可能会有小的变异（例如：时间戳、访问令牌等）。