在最近一个月或更长时间里，我们发现读取超时错误大幅增加，以至于我们似乎无法弄清楚。我们研究了 DNS 缓存(确保我们不会遇到过时的 A 记录)，我们尝试了不同的 HTTP 传输(例如 ApacheHttpTransport 和 NetHttpTransport)，并且我们已玩过 5 秒、20 秒(默认)和 60 秒的超时范围。
这似乎并不重要:任何写入操作(我们大量使用 PATCH)似乎都有大约 30-40% 的机会导致超时。这似乎发生在我们所有的用户身上(数千个，所以它不仅仅局限于某些 Google 帐户)。我们利用指数退避，99.9% 的时间我们的请求最终都能通过，但延迟让我们的用户感到沮丧。我们还尽可能利用 If-Match header 。
对于可能导致这种情况的原因，我已经没有想法了。虽然我们在一月份首次推出产品时偶尔会遇到超时和 500 错误，但我们没有观察到任何接近这种级别的故障。
我确实想到了一个想法:由于我们产品的性质，我们可以进行大量的 API 调用，这可能会导致各种错误。例如，我们经常发出删除事件请求，但不知道它们是否已被删除，从而导致“410 gone”响应。
那么...如果您进行了太多 Google 不喜欢的调用，Google 的 API 是否可能会“惩罚”您，而不是限制我们的速率或发送一些其他结构化错误，而是决定使套接字超时？
最佳答案
我找到了我的困境的原因，这真是太棒了。在尝试了不同的帐户和用户代理 header 以及任何可以排除我们的特定请求有问题的内容之后，我完全切换到了不同的客户端库。
经过多次试验和错误，我将范围缩小到这样一个事实:官方 Google Calendar API 客户端库默认为传出请求启用 GZIP 压缩。当我关闭它时，突然一切都变得 super 顺利。
附件A:
显然，我认为一般来说，在两个方向上进行 gzip 压缩会很棒。但如果它引起我所看到的那种头痛，那就不是了!我们将向 Google 提交错误报告。我的预感是，在某些情况下，Content-Length header 的设置可能会稍有错误，从而导致请求挂起。奇怪的是，使用相同的有效负载重试效果很好，但我想每次都可能有小的变化(例如:时间戳、访问 token 等)。
关于java - 历史上的高错误率是否会导致 Google 日历 API 超时？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/62392530/