这是一个创建于 3926 天前的主题，其中的信息可能已经有所发展或是发生改变。
现象
应用服务器的 error_log 看到大量的 upstream timed out，网站在访问时，时不时就出现整个页面卡住的现象。
根源
之前服务器放在美国，和美国本地的其他 Web 服务通讯延迟非常低，比如 api.github.com。而 V2EX 的用户个人主页中有 GitHub 和 Dribbble 集成功能。之前这里犯的低级错误就是没有把这两个请求进行异步处理。
服务器回到国内之后，延迟变大，于是所有和 Dribbble 及 GitHub 的通讯有一定概率堵住 Tornado instance，于是造成 upstream timed out。
其实这个问题之前在美国时也存在，只是因为网络延迟太低把问题掩盖了。
解决
将这两个 API 请求放入 RQ 进行处理。
 | 1 sunyang 2015 年 4 月 26 日 via Android 可以愉快的玩耍了 |
 | 2 fecho 2015 年 4 月 26 日 推上看到了~~真的可以愉快的玩耍了 |
 | 3 jmu 2015 年 4 月 26 日 good |
 | 4 no13bus 2015 年 4 月 26 日 via iPhone 所以说即使用了异步框架，但是在前端渲染的时候还是会导致无法及时的通过后台获取到外部api返回的数据，导致页面卡顿。所以livid还是把获取外部数据放到了队列里面？然后加缓存就能解决问题了？ |
| 6 no13bus 2015 年 4 月 26 日 @Livid 恩。一直用AsyncHTTPClient来请求外部api，然后yield下，tornado的get post请求都尽量不出现任何非异步的请求。requests还是不要用。 |
 | 7 wwqgtxx 2015 年 4 月 26 日 via Android @Livid v2ex的cdn现在无法访问，之前用的 https://cdn.v2ex.com 访问正常，现在的 https://cdn.v2ex.co 无法打开，请修复 / $ ping cdn.v2ex.co PING lbr.ogslb.com (23.251.121.132) 56(84) bytes of data. 64 bytes from 23.251.121.132: icmp_seq=1 ttl=51 time=53.9 ms ^C64 bytes from 23.251.121.132: icmp_seq=2 ttl=51 time=52.8 ms --- lbr.ogslb.com ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 5871ms rtt min/avg/max/mdev = 52.885/53.409/53.934/0.573 ms / $ ping cdn.v2ex.com PING v2ex.china.zgslb.net (122.226.184.35) 56(84) bytes of data. 64 bytes from 122.226.184.35: icmp_seq=1 ttl=49 time=41.5 ms 64 bytes from 122.226.184.35: icmp_seq=2 ttl=49 time=41.7 ms 64 bytes from 122.226.184.35: icmp_seq=3 ttl=49 time=45.8 ms ^C --- v2ex.china.zgslb.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 41.561/43.041/45.816/1.977 ms / $ |
 | 8 xanpeng 2015 年 4 月 27 日 我2个月前才接触到rq，当初要找一个python work queue，然后找到的看起来简单的、可用的就这个，然后我还一直以为它就是一个玩具，没想到真有实际使用啊。 另外感觉用起来始终有些不爽，感觉原来偏工具，于是照着改写了，改成偏lib...结果是可控度好很多，自己用起来顺手很多。 |
Select Language