描述
我有一个运行Python应用程序的AWS EC2实例(Ubuntu 16(。在其中我称之为一些Facebook帐户套件API和Google Play商店API。它们都可以很好地工作,直到我在两个星期前重新启动实例为止。
重新启动后,请求需要超过5分钟才能完成,这是完全不可接受的。我必须手动将超时设置为超过10分钟才能让请求完成。
问题仅发生在我的一台服务器上,我在另一台服务器上使用相同的环境运行,它的响应时间不到一秒钟。
。临时修复
要暂时解决该问题,然后我使用代理服务器来完成请求。
- API服务器(带超时问题的服务器(
- 代理服务器运行Python脚本并返回结果
- API服务器(带有超时问题的服务器(返回对客户端的响应
情况
- 我尝试在API服务器上使用curl,它的响应时间也小于1秒。
- 我使用
requests
在Python环境上尝试了,响应时间很糟糕,超过5分钟。- 如果我设置了标题
{'Connection' : 'keep-alive' }
,则第二个请求将是正常的。 - 我打开了日志记录,似乎请求粘在建立与目的地的连接上。
- 如果我设置了标题
- 我尝试了我写的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配置?请帮忙,谢谢。
update
定时卷发的结果,似乎使用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
想到了两个项目。
DNS
调试:
$ 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访问令牌",是的,是的,这很好。我们感兴趣的是连接需要多长时间发送GET并检索Web文档。
此域提供A和AAAA地址。如果IPv6运输是敬酒的,则可能需要一段时间requests.get()
将故障转移到IPv4。
编辑
有人打破了您的IPv6运输。这在现代互联网中是不可接受的。掉落的数据包超时可能导致了127秒的过去时间。traceroute6
和ping6
等工具可以帮助您或网络专业诊断损失在哪里。ACL可能太紧了,正在丢弃不应该的IPv6数据包。丢弃ICMP会特别糟糕。为了使TCP正确工作,必须交付ICMP。
a tcpdump
(或wireshark(数据包跟踪会有所帮助确切地确定向南的情况。您可能患有PMTUD黑色疾病。看看这是否显示"包太大的数据包"ICMP报告:
$ sudo tcpdump -tvvvni eth0 icmp6 and ip6[40+0]==2
仅查看出站端口443 TCP重新译本的时间安排会说出为什么事情失败了两分钟会有很大的了解然后钻头突然开始流动。