首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >问答首页 >使用请求的响应时间非常长

使用请求的响应时间非常长
EN

Stack Overflow用户
提问于 2019-07-07 08:07:18
回答 1查看 1.1K关注 0票数 3

描述

我有一个运行Python应用程序的AWS ec2实例(Ubuntu16)。在其中,我调用了一些Facebook帐户工具包API,以及Google。在我两周前重新启动实例之前,它们都非常正常。

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

这个问题只发生在我的一台服务器上,我在另一台服务器上运行相同的环境,在不到1秒的响应时间内运行非常好。

临时修正

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

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

Situations

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

  1. 我尝试使用我编写的API,响应时间也很糟糕,超过5分钟。

电流码

响应时间慢的请求。

代码语言:javascript
代码运行次数:0
运行
复制
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服务器进行调用。

代码语言:javascript
代码运行次数:0
运行
复制
response = requests.get("https://proxyserver.com/somepath", params={})

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

更新

由于时间卷曲的结果,使用iPv6调用似乎需要更多的时间。

代码语言:javascript
代码运行次数:0
运行
复制
$ time curl -4 -s https://graph.accountkit.com/v1.3
$ time curl -6 -s https://graph.accountkit.com/v1.3

iPv4

代码语言:javascript
代码运行次数:0
运行
复制
real    0m0.665s
user    0m0.068s
sys 0m0.020s

iPv6

代码语言:javascript
代码运行次数:0
运行
复制
real    2m7.180s
user    0m0.008s
sys 0m0.000s
EN

回答 1

Stack Overflow用户

发布于 2019-07-07 20:58:06

想到了两件事。

DNS

调试时:

代码语言:javascript
代码运行次数:0
运行
复制
$ cat /etc/resolv.conf

$ time dig aaaa graph.accountkit.com

您可能列出了多个名称服务器,而且并不是所有的名称服务器都是响应的,因此您需要进行长时间查找,因为它会超时于死的名称服务器。

TCP

调试时:

代码语言:javascript
代码运行次数:0
运行
复制
$ 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秒的时间过去.像traceroute6ping6这样的工具可以帮助您或网络专业人员诊断损失在哪里。可能ACL太紧了,正在丢弃它不该丢弃的IPv6数据包。丢弃ICMP将是特别糟糕的。要使TCP正确工作,必须传递ICMP。

tcpdump (或Wireshark)数据包跟踪将有助于准确地识别出向南移动的信息。你有可能患上了PMTUD黑孔。看看这是否显示任何“数据包太大”ICMP报告:

代码语言:javascript
代码运行次数:0
运行
复制
$ sudo tcpdump -tvvvni eth0 icmp6 and ip6[40+0]==2 

只要看一看出站端口443的时间,TCP重传就能解释为什么事情会在两分钟内失败,然后比特就会突然开始流动。

票数 2
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/56920375

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档