现象
应用服务器的 error_log 看到大量的 upstream timed out,网站在访问时,时不时就出现整个页面卡住的现象。
根源
之前服务器放在美国,和美国本地的其他 Web 服务通讯延迟非常低,比如 api.github.com。而 V2EX 的用户个人主页中有 GitHub 和 Dribbble 集成功能。之前这里犯的低级错误就是没有把这两个请求进行异步处理。
服务器回到国内之后,延迟变大,于是所有和 Dribbble 及 GitHub 的通讯有一定概率堵住 Tornado instance,于是造成 upstream timed out。
其实这个问题之前在美国时也存在,只是因为网络延迟太低把问题給掩盖了。
解决
将这两个 API 请求放入 RQ 进行处理。
1
sunyang 2015-04-26 16:58:01 +08:00 via Android
可以愉快的玩耍了
|
2
fecho 2015-04-26 17:02:54 +08:00
推上看到了~~真的可以愉快的玩耍了
|
3
jmu 2015-04-26 17:30:09 +08:00
good
|
4
no13bus 2015-04-26 18:17:22 +08:00 via iPhone
所以说即使用了异步框架,但是在前端渲染的时候还是会导致无法及时的通过后台获取到外部api返回的数据,导致页面卡顿。所以livid还是把获取外部数据放到了队列里面?然后加缓存就能解决问题了?
|
5
Livid MOD OP @no13bus 具体来说,就是不要在 Tornado 的 get/post 里直接用 requests 去读取外部 API
|
6
no13bus 2015-04-26 18:27:21 +08:00
@Livid 恩。一直用AsyncHTTPClient来请求外部api,然后yield下,tornado的get post请求都尽量不出现任何非异步的请求。requests还是不要用。
|
7
wwqgtxx 2015-04-26 23:08:41 +08:00 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-04-27 00:07:29 +08:00
我2个月前才接触到rq,当初要找一个python work queue,然后找到的看起来简单的、可用的就这个,然后我还一直以为它就是一个玩具,没想到真有实际使用啊。
另外感觉用起来始终有些不爽,感觉原来偏工具,于是照着改写了,改成偏lib...结果是可控度好很多,自己用起来顺手很多。 |