gpt4 book ai didi

python - 使用请求的响应时间极长

转载 作者:行者123 更新时间:2023-12-04 17:35:19 33 4
gpt4 key购买 nike

描述

我有一个运行 Python 应用程序的 AWS ec2 实例 (ubuntu 16)。我在其中调用了一些 Facebook Account Kit API 和 Google Play Store API。在我两周前重新启动实例之前,它们都工作得很好。

重启后,请求需要超过 5 分钟才能完成,这是完全不能接受的。我必须手动将超时设置为 10 分钟以上才能完成请求。

问题只发生在我的一台服务器上,我在另一台服务器上运行相同的环境,它运行良好,响应时间不到一秒。

临时修复

为了暂时解决这个问题,我使用代理服务器来完成请求。

  1. API Server(有超时问题的服务器)
  2. 代理服务器运行python脚本并返回结果
  3. API Server(有超时问题的服务器)返回响应给客户端

情况

  1. 我尝试在 API 服务器上使用 curl,它的响应时间也小于 1 秒。
  2. 我尝试使用 requests 在 python 环境中,响应时间很糟糕,超过 5 分钟。
    1. 如果我设置 header {'Connection' : 'keep-alive' },第二个请求将正常。
    2. 我打开了日志记录,似乎请求卡在与目标建立连接上。
  3. 我尝试使用我编写的 API,响应时间也很糟糕,超过 5 分钟。

当前代码

响应时间较慢的请求。

url_get_access_token = "https://graph.accountkit.com/v1.3/access_token?grant_type=authorization_code&code=%s&access_token=AA|%s|%s"
url_get_access_token = url_get_access_token % (token, self.facebook_app_id, self.facebook_account_kit_scert)
response = requests.get(url_get_access_token)
body = response.json()

我上面提到的代理服务器是同一个子网中的另一个实例,但是我用DNS服务器调用。

response = requests.get("https://proxyserver.com/somepath", params={})

因为它只影响其中一台服务器,那是 DNS 问题还是 AWS 配置问题?请帮忙,谢谢。

更新

定时 curl 的结果,似乎与 iPv6 的通话需要更多时间。

$ time curl -4 -s https://graph.accountkit.com/v1.3
$ time curl -6 -s https://graph.accountkit.com/v1.3

IPv4

real    0m0.665s
user 0m0.068s
sys 0m0.020s

IPv6

real    2m7.180s
user 0m0.008s
sys 0m0.000s

最佳答案

我想到了两个项目。

域名系统

调试:

$ cat /etc/resolv.conf

$ time dig aaaa graph.accountkit.com

您可能列出了多个名称服务器,并不是所有的人都有反应,所以你会遭受长时间查找的痛苦,因为它会在死者身上超时。

TCP

调试:

$ time curl -4 -s https://graph.accountkit.com/v1.3
$ time curl -6 -s https://graph.accountkit.com/v1.3

它会说“无效的 OAuth 2.0 访问 token ”,是的,是的,没关系。我们感兴趣的是连接需要多长时间,发送 GET,并检索 Web 文档。

此域同时提供 A 和 AAAA 地址。如果 IPv6 传输是 toast ,可能需要一段时间requests.get() 故障转移到 IPv4。

编辑

有人破坏了您的 IPv6 传输。这在现代互联网中是 Not Acceptable 。丢弃的数据包超时可能导致 127 秒的耗时。traceroute6ping6 等工具可以帮助您或网络专业人员诊断损失在哪里。可能是 ACL 太紧,正在丢弃它不应该丢弃的 IPv6 数据包。丢弃 ICMP 尤其糟糕。为使 TCP 正常工作,必须传送 ICMP。

tcpdump(或 Wireshark)数据包跟踪会有所帮助确定到底是什么南下。您可能患有 PMTUD black-holing .查看这是否显示任何“数据包太大”ICMP 报告:

$ sudo tcpdump -tvvvni eth0 icmp6 and ip6[40+0]==2 

只看出站端口443 TCP重传的时机会清楚地说明为什么事情会失败两分钟然后比特突然开始流动。

关于python - 使用请求的响应时间极长,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56920375/

33 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com