Disqus 用 Go 取代 Python 的经验分享

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

The Go Programming Language

› http://golang.org/

› Go Playground

Go Projects

› Revel Web Framework

这是一个创建于 3851 天前的主题，其中的信息可能已经有所发展或是发生改变。

http://highscalability.com/blog/2014/5/7/update-on-disqus-its-still-about-realtime-but-go-demolishes.html

Python

disqus

26 条回复 • 2014-05-08 22:14:32 +08:00

jjx

2014-05-08 15:55:13 +08:00

The realtime service is a hybrid of CPU intensive tasks + lots of network IO. Gevent was handling the network IO without an issue, but at higher contention, the CPU was choking everything. Switching over to Go removed that contention, which was the primary issue that was being seen.

说明gevent还是很给力的

clino

2014-05-08 16:03:23 +08:00

@jjx 怎么看起来意思是gevent在higher contention就不行了,换成go则无问题
原因应该是gevent无法利用多核,而go可以吧?

jjx

2014-05-08 16:07:22 +08:00

@clino 我觉的意思是gevent 处理网络io没有问题, 这就是gevent本身的任务所在, 而cpu, python本来就是这样 ,大家都有共识了

jjx

2014-05-08 16:15:01 +08:00

这个文章用go其实也有个场景问题. 比方说没有用来访问db, 我实际的尝试是如果用go来访问db, 做db类web应用,虽说比python提升了3~4倍的性能(实际提升有限), 但相对于python的效率. 实在是要不得, 没必要

cyberscorpio

2014-05-08 16:22:40 +08:00

gevent 对 network I0 没有问题，但 python 对 CPU 密集型的任务就掉链子了。

估计这个跟 python 的多线程实现有一定关系，另外 python 的效率毕竟不能跟 native 的 go 相比。

没有选择 node 也是同样的原因，node 对 network IO 很合适 (这点和 gevent 类似)，但是 disqus 的需求是 network IO 和 CPU 密集型任务的一个混合体，node 对后者也不擅长。

alexapollo

2014-05-08 17:07:02 +08:00

脚本语言对CPU密集型的任务都不在行
为什么 “disqus 的需求是 network IO 和 CPU 密集型任务的一个混合体”
@cyberscorpio

est

2014-05-08 17:31:00 +08:00

@cyberscorpio 。。。。跟多线程一毛线关系都没有

如果你在大型网络编程中import threading那么你已经输了。

VYSE

2014-05-08 17:33:09 +08:00

@alexapollo 当IO上去后，本来其实不怎么明显的CPU消耗就显著了，所以切换native的go去处理事务

yueyoum

2014-05-08 18:37:54 +08:00

@est 求教，那该如何？

event loop ? or erlang Actor model ?

skybr

2014-05-08 18:52:47 +08:00

调用多了, 差距再小也大

https://gist.github.com/6a895ca27c0ca98aa0df.git

skybr

2014-05-08 18:53:17 +08:00

https://gist.github.com/anonymous/6a895ca27c0ca98aa0df

alexapollo

2014-05-08 19:15:50 +08:00

@VYSE 我一直认为disqus比较像纯粹的IO密集型的，但也有道理，如果IO没有任何瓶颈，那么就是纯粹的CPU线性消耗

jjx

2014-05-08 19:16:49 +08:00

去掉print没有你测试的那样夸张,也就3~4倍的差距

skybr

2014-05-08 19:47:00 +08:00

@jjx 全部定向到/dev/null的, 加输出主要怕变量没用到会被优化掉.

dreampuf

2014-05-08 19:53:39 +08:00

@skybr

我不知道你拿系统原生Progress和goroutine比较有什么意义

dreampuf

2014-05-08 19:54:26 +08:00

typo: Progress -> Process

dreampuf

2014-05-08 19:57:15 +08:00

@skybr 看错了，抱歉。不是原生进程，是Greenlet。这个比较，有意义。

jjx

2014-05-08 19:58:26 +08:00

我去掉两段代码的print跑的,同你的差距较大

(pypy)➜ test time python test_py.py
python test_py.py 11.32s user 0.56s system 99% cpu 11.912 total
(pypy)➜ test time ./test2
./test2 2.36s user 1.79s system 99% cpu 4.148 total

jjx

2014-05-08 20:03:51 +08:00

python 2.7同pypy差别同一差不多, 相差3~4秒

(python)➜ test time python test_py.py
python test_py.py 15.09s user 0.77s system 99% cpu 15.893 total

skybr

2014-05-08 20:21:38 +08:00

@jjx 我用到了sync.Pool, 一直在跟开发版, 怀疑是版本差异导致的, 试了下1.2, 确实.

https://gist.github.com/anonymous/7bdc0e9ce839e4d51052

guotie

2014-05-08 20:26:11 +08:00

开发版本有这么nb？

上次用开发版本测试martini的性能，没有比1.2高啊

skybr

2014-05-08 20:37:01 +08:00

把python的例子改成cython, 去掉这个例子里没什么用处的wait_available, 运行结果和纯python的差距不大.
https://gist.github.com/anonymous/e531394bbda389e4990f

@guotie martini的开销主要落在运行时的反射处理上, 所以提升不大吧.

jjx

2014-05-08 21:09:55 +08:00

试了一下1.3, 得确这个提升的有点吃惊

不过我所知道的很多搞python的都随带着在用go, 也是好事

srdrm

2014-05-08 21:11:56 +08:00

@skybr 调用多了，差距再小也大。
======================
同意这个观点

est

2014-05-08 22:14:32 +08:00

@yueyoum 是的啊。

ulimit -a
stack size (kbytes, -s) 8192

一个线程8MB。多线程能撑多少连接可以直接算出来。当然你可以改pthread_attr_setstacksize之类东西弄小一点，但是也会有其他问题。

所以说posix下线程跟进程一样重。

相比而言，一个goroutine才4KB大。（Go 1.2是8KB）