服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 只有使用cURL获取数据时，DNSparsing速度才会很慢
Intereting Posts
Web.config文件的权限 在CentOS 6.4上安装第三方应用程序包失败，原因是缺less依赖关系libcrypto.so.10和libssl.so.10 nginx proxypass鱿鱼 Postfix + PHP将发送到本地域的电子邮件地址转换为[email protected] 用户自助服务的SSL客户端证书解决scheme XCache在一天左右之后失去了性能提升 如何在bash中以较less的开销查看磁盘使用情况？ 如何通过Linux从Windows 2003 Server HP StorageWorks Ultrium 448备份恢复数据？ 最新的内核主线发布是否稳定 Phusion Passenger设置PassengerPreStart不会使用服务httpd start来激活 带宽*延迟产品 在Debian Lenny上安装系统级的PEAR 如何重复一个命令，如反向引用，在cli？ Exchange 2010邮件滞留在队列中 如何使用多个具有一个公共IP地址的虚拟Web服务器？

只有使用cURL获取数据时，DNSparsing速度才会很慢

我有我的本地bind9域“engine02.prod.qc.offercal.com”。

我不认为这是DNS服务器或TTL问题，因为基准几乎总是看起来像这样（我尝试了2分钟使用每种方法）： 

 curl -o /dev/null http://engine02.prod.qc.offercal.com:49157/void time_namelookup: 0.150 time_connect: 0.151 time_starttransfer: 0.152 ---------- time_total: 0.152 curl -o /dev/null http://192.168.100.10:49157/void # use IP directly time_namelookup: 0.000 time_connect: 0.002 time_starttransfer: 0.003 ---------- time_total: 0.003 time dig @192.168.100.4 engine02.prod.qc.offercal.com real 0m0.009s user 0m0.004s sys 0m0.004s time host engine02.prod.qc.offercal.com engine02.prod.qc.offercal.com has address 192.168.100.10 real 0m0.011s user 0m0.006s sys 0m0.004s

我的resolv.conf文件： 

 [root@gateway01 ~]# cat /etc/resolv.conf nameserver 192.168.100.4

我一直在努力解决这个问题，请帮忙：D

我刚刚在构buildupdown.io时碰到了这个问题，并仔细研究了一下（感谢@Dan的strace命令）。 这是我发现的：

条件

在我的情况下，curl有时需要65ms来解决，有时需要<5ms。 在短时间不活动（几分钟）之后似乎需要65ms，并且在重复呼叫之后<5ms。 肯定听起来像一个caching和TTL问题显然。 但我的logging有一个86400s的TTL（1天），它已经被caching在我的本地parsing器，挖掘总是花费1ms。

措施

所以我试着用strace跑卷发来看看花费的时间，这就是我发现的（为了清晰起见，我去掉了一些细节）： 

 05:57:52.303 connect(3) = 0 05:57:52.303 sendmmsg(3, ["1\26\1\0\0\1\0\0\0\0\0\0\22jarthon-architecte\3"..., "\0253\1\0\0\1\0\0\0\0\0\0\22jarthon-architecte\3"...] , 2) = 2 05:57:52.303 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 05:57:52.303 ioctl(3, FIONREAD, [56]) = 0 05:57:52.303 recvfrom(3, "1\26\201\200\0\1\0\1\0\0\0\0\22jarthon-architecte\3"...) = 56 05:57:52.304 poll([{fd=3, events=POLLIN}], 1, 4999) = 1 05:57:52.373 ioctl(3, FIONREAD, [96]) = 0 05:57:52.373 recvfrom(3, "\0253\201\200\0\1\0\0\0\1\0\0\22jarthon-architecte\3"...) = 96 05:57:52.373 close(3) = 0

这是DNSparsing部分，这里我们可以清楚的看到，发送了2个消息，一个响应很快收到，另一个响应延迟了69ms。 我认为这第二个回应可能是IPv6查询（AAAA），所以我试图在挖： 

 $ dig AAAA jarthon-architecte.com ;; AUTHORITY SECTION: jarthon-architecte.com. 180 IN SOA ns0.dnsmadeeasy.com. dns.dnsmadeeasy.com. 2008010120 43200 3600 1209600 180 ;; Query time: 86 msec ;; SERVER: ::1#53(::1)

好吧，没有答案显然，但是这个SOAlogging有180s的TTL，这看起来很像在curltesting中从5ms到65ms的时间。

说明

当没有答案时，您的DNS服务器将返回SOAlogging，并在其中包含负数TTL（可以看到的最后一个数字为180），这是任何parsing器被允许caching否定响应（无logging）的时间。 所以这意味着当您查询AAAAlogging时，您必须至less每3分钟打一次DNS服务器，以确保它仍然不存在。

固定

  1. 添加一个IPv6☺

  2. 如果你正在pipe理DNS，最简单的解决办法就是增加这个值，在我使用DNSMadeEasy的情况下，我可以创build一个具有更高TTL值的自定义SOAlogging，并将其分配给我的域： http：// help。 dnsmadeeasy.com/managed-dns/records/soa-start-authority-record/ 。 这将使大多数时间更快地解决curl问题，回到我们正确caching的Alogging上的性能水平。

  3. 如果你是一个curl但不pipe理DNS的人，可能有办法在DNSparsing器级别优化这个，通过服务陈旧的负面反应，而获取真实的价值或类似的东西，但我没有看进入那个呢。

  4. 如果您不关心IPv6，也可以使用curl命令行标志-4来禁用它

如果这是debian（即ubuntu 13+）的更新版本，则需要在您的static ip config后将dns-nameservers追加到/ etc / network / interfaces的末尾。 编辑resolv.conf只会给你带来这些linux的风味。

即。

网关线后

dns-nameservers local.dns.ip.here outside.back.ip.here