Google App Engine和Azure认知搜索之间的127延迟
我们的大多数服务都在Google Cloud上，但是我们连接到Azure认知搜索以进行全文搜索。
由于一个月前，随机延迟开始出现在App Engine和认知搜索之间，请求始终需要127.2-127.3秒，即比正常请求多127秒。这是专门针对认知搜索的请求，而不是下文或代码的任何其他部分。
奇怪的是，这些延迟不会从本地测试，VM，K8或其他任何地方出现。尽管如此，在花了3周的时间回答之后，Google坚持认为这是由“数据包丢失”引起的“ azure问题”。它们确实表明某些请求连接到IPv4，而其他请求连接到IPv6地址，但我在这里也没有发现相关性。
什么样的问题可能会导致如此特别的延迟？
Most of our services are on Google cloud, but we connect to Azure Cognitive search for full text searches.
Since around a month ago, random delays started appearing between app engine and cognitive search, with requests consistently taking 127.2-127.3 seconds, i.e. exactly 127 seconds more than normal requests. This is specifically on the request to cognitive search, and not any other part of the infra or code.
Strangely, these delays do not appear from local testing, vms, k8s or anywhere else. Still, after taking 3 weeks to answer, google insists this is 'an azure problem' caused by 'packet loss'. They do indicate that some requests connect to an ipv4 and others to an ipv6 address, but I have found no correlation here either.
What kind of problem could cause such an extremely specific delay?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
看来这是由于IPv6问题，并且请求库（或基础Python基础架构）在经过多个指数备份后的重新恢复后将其切换到IPv4，从而导致〜2^7-1秒延迟。
强迫使用此丑陋的黑客完成IPv4连接可以完成：
It appears this is due to IPv6 problems, and the requests library (or underlying python infrastructure) switches to IPv4 after a number of exponentially backed-off retries, leading to ~2^7-1 seconds delay.
Forcing an IPv4 connection canbe done using this ugly hack: