GO 的性能真的是很惊人啊 · Ruby China
本帖已被设为精华帖！
据说跟C比只差10%了，简单写了个http server输出个字符串，AB测了下，-KC 100 -N 10000，双核老I3笔记本，4G内存，MINT 64位，飚到近50000 每秒，用仿SINATRA的beego框架，prod环境下用模板输出个字符串，也能飚到26000，拿来JAVA的仿SINATRA框架PLAY输出同样字符串，每秒8000多。
都不是一个重量级了。。。。。
测的太 hello world 了
你可以模板里加些拼接看看
还有就是 beego 很多地方都在偷工减料... 例如 cookie session 里根本就没签名, 作者好像没理解 CSRF 在里面用了固定字符串...
(我测过 C 比 go 快 10 倍左右...)
Golang 内建的 html/template 性能比较差, 你测试的时候输出太少是没有意义的.
以我的经验, render 较多内容时， common lisp 竟不比 Go 差多少.
另外，你可以看看我这个用
go 写的网站
在 occnet.net 我也自己实现 csrf token, 不过是保存在浏览器的 session 里, 也就是 maxage =0, 好像 rails的也是这样的, 因此在一个 session 里它是不变的, 不过登出或重新登录会更新 token. 我觉得没有必要每个 request 都更新 token .
可能不光是语言关系，纯ruby的的http server，普通 socket 和用 em ab 还差好多呢。
1楼，您说的太夸张了，10倍，您的说法很让人无语
大家到底学了多少语言？
我对 Google 的东西有点没信心了。Android 偶尔自动重启, Chrome 偶尔崩溃一下，还没 Firefox 稳定。
您说的太夸张了，10%，您的说法让人无语。——说这个话很没技术含量。
作为一门编译型的语言在性能方面向C/C++看齐有什么奇怪的。不把C甩个两三条街根本谈不上什么惊人。
Java的HTTP性能不差的。你直接拿apache去和jetty pk，java落后的也不多。
c 在 server 的话我用 libmicrohttpd + mongodb-c-driver 和 go 对比测试过的, tps 大约 10 倍左右 (已经接近硬盘 io 极限了). 虽然也很 hello world 但也比不连 db 的测试靠谱点
c 在各种 micro benchmark 里基本都是比 go 快 2 到 10 几倍不等, 代码量和 go 在一个数量级
Sinatra 2.0 会使用 Go 重写？
看过beego的csrf源码吗？签名没有？C的比Go的快10倍，呵呵，上对比代码
瓶颈往往不在 hello world .
签名指的是cookie session，首先得有一个CookieSessionStore，真的
PS. 使用HMAC生成csrf token的做法有点杀鸡用牛刀的感觉，只是生成一个随机字符串呀，有必要么。
15楼 已删除
任何用hello world来测性能的都是耍流氓
都是服务器端 session, 没找到签名 session 啊
token 的生成方法是 sha1(key + ip : nanotime) : nanotime 对吧? 不直接用随机字符串的话 总是存在可预测的隐患的.
c 和 go 的对比代码是两年前的...
现在 go 比那时快很多了, 但别忘了现在 clang 都能开 -O4 了
17楼的兄弟，你是两年前的GO，我了个去，您老还沉浸在两年前啊。。。。。。
知道GO1.1提高多大吗？
劝您重新测试下
嗯. 有空测试下. go 的设计早就定型了, 也没 llvm 的编译器专业, 估计变化不大.
你说的两个都是吃内存大户，但是GO不同。。。。不信就自己写个简单代码来测
第一，session不是保存在服务器端那保存在哪里啊？session和cookie的区别你了解吗？
第二、token的这个产生方式我不觉得存在可预测的隐患，你有什么更好的建议吗？
第三，你别拿两年前的对比出来唬人啊，看得我都惊呆了，现在你可以再用clang和Go对比一下,这个是别人的对比情况：
go比c慢10倍的场景并不少见，比如二叉树测试：
你看了对比的版本了吗？
go version go1.1.2 linux/amd64
BenchmarksGame 不是为了测试不同语言的最优性能, 而且为了测试不同语言最自然状态下编写程序的性能. 比如, binary-trees测试就是禁止自己定制专有的缓冲池的, 而C语言的版本则可以随意使用 各种优化手段(基于apr和缓冲池和openmp的并行优化).所以出现了如上的结果，你看看Go自带的测试用例的测试结果,相差就是在10%之内：
$GOROOT/test/bench/shootout/timing.sh
gcc -m64 -O2 fasta.c
0.86u 0.00s 0.87r
0.85u 0.00s 0.86r
gc_B fasta
0.83u 0.00s 0.83r
reverse-complement & output-of-fasta-
gcc -m64 -O2 reverse-complement.c 0.45u 0.05s 0.50r
gc reverse-complement
0.60u 0.05s 0.65r
gc_B reverse-complement
0.55u 0.04s 0.59r
gcc -m64 -O2 nbody.c -lm
5.51u 0.00s 5.52r
7.16u 0.00s 7.18r
gc_B nbody
7.12u 0.00s 7.14r
binary-tree 15 # too slow to use 20
gcc -m64 -O2 binary-tree.c -lm
0.31u 0.00s 0.31r
gc binary-tree
1.08u 0.00s 1.07r
gc binary-tree-freelist
0.15u 0.00s 0.15r
fannkuch 12
gcc -m64 -O2 fannkuch.c
26.45u 0.00s 26.54r
gc fannkuch
35.99u 0.00s 36.08r
gc fannkuch-parallel
73.40u 0.00s 18.58r
gc_B fannkuch
25.18u 0.00s 25.25r
regex-dna 100000
gcc -m64 -O2 regex-dna.c -lpcre
0.25u 0.00s 0.26r
gc regex-dna
1.65u 0.00s 1.66r
gc regex-dna-parallel
1.72u 0.01s 0.67r
gc_B regex-dna
1.64u 0.00s 1.65r
spectral-norm 5500
gcc -m64 -O2 spectral-norm.c -lm
9.63u 0.00s 9.66r
gc spectral-norm
9.63u 0.00s 9.66r
gc_B spectral-norm
9.63u 0.00s 9.66r
k-nucleotide 1000000
gcc -O2 k-nucleotide.c -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -lglib-2.0
2.62u 0.00s 2.63r
gc k-nucleotide
2.69u 0.01s 2.71r
gc k-nucleotide-parallel
3.02u 0.00s 0.97r
gc_B k-nucleotide
2.66u 0.01s 2.68r
mandelbrot 16000
gcc -m64 -O2 mandelbrot.c
20.95u 0.00s 21.01r
gc mandelbrot
23.73u 0.00s 23.79r
gc_B mandelbrot
23.72u 0.00s 23.79r
meteor 2098
gcc -m64 -O2 meteor-contest.c
0.05u 0.00s 0.05r
gc meteor-contest
0.06u 0.00s 0.07r
gc_B meteor-contest
0.06u 0.00s 0.06r
pidigits 10000
gcc -m64 -O2 pidigits.c -lgmp
0.77u 0.00s 0.77r
gc pidigits
1.45u 0.01s 1.44r
gc_B pidigits
1.45u 0.01s 1.43r
threadring
gcc -m64 -O2 threadring.c -lpthread
12.05u 261.20s 216.36r
gc threadring
6.61u 0.00s 6.63r
chameneos 6000000
gcc -m64 -O2 chameneosredux.c -lpthread 4.04u 21.08s 4.20r
gc chameneosredux
4.97u 0.00s 4.99r
你指的是 这样的方法吧，这个目前还在考虑中，如何更好的加入进来。第二我不觉得通过sha1加密就是用了牛刀了。
欢迎提出宝贵意见
楼上各位，Go其实除了性能之外，还有很多别的优势，我在这个里面总结了一些，很多人也补充了一些，希望对大家了解Go有帮助：
28楼 已删除
第一，你的IP变了那么csrf肯定要变，不然不算安全，第二，c.Ctx.Request.RemoteAddr 这个获取的是客户端请求IP，不存在两个IP，难道tcp协议变了？
30楼 已删除
你确信CSRF用了session？是不是你没理解清楚beego里面怎么实现csrf的啊
32楼 已删除
你好像没搞清楚什么是session，什么是cookie啊
34楼 已删除
所以我上面说了啊，你确信CSRF是放session里面的？你没理解beego的实现方式啊。然后你在看看 如何防御csrf
cookie里面不一定要放sessionID的，在beego的实现里面根本就没有session的概念在里面，所以你的理解是完全错误的
我对go不是很了解，今晚回去研究一下。
恩，还是很有趣的，欢迎多交流
token你应该设置一个超时时间啊，不然csrf就没啥意思了
性能测试的话，近期这个帖子参与的人不少：
41楼 已删除
我是担心 刚好在用户 post 的时候重置了
其实最新的是这个
看到BEEGO的作者谢大牛进来讨论，俺闪了
第一 在Go里面session是尽量不提倡的，你看Go里面默认是不带有任何的session模块的，第二 目前放在cookie里面的csrf，我们做这个的目的是防止跨站攻击，javascript不能读取跨站的cookie吧。
我知道，因为有订阅。不过之所以叫round2, 就是因为和前一个不同，这个用了并发，所以不能说最新，只是另一组测试
47楼 已删除
但是我觉得超时了就应该post不成功
说的没有错啊，是你对session的理解太狭隘了。
session和cookie本来就没有那么界限分明。session id是要通过cookie存储的，session内容也可以通过cookie存储。并且基于cookie存储的session更符合RESTful的特性。
防御CSRF的核心手段就是不可预测原则, 你把IP发生变化的请求拦截掉是在防御伪造请求？你需要的只是一个简单的随机算法，而不是签名算法。所以说是杀鸡用牛刀。
想抓Go里面的XSS还是很难写出这样的代码，因为Go的默认模板引擎就是全部XSS过滤的
51楼 已删除
52楼 已删除
看看我对于session和cookie的理解：
还有csrf的核心手段是不可预测原则没错，IP变化的请求拦截当然是基于不同的IP伪造请求拦截，我觉得这个设计没有任何问题啊。随机算法比较容易破解，为什么采用sha1主要是防止破解，md5就可以反破解
那么我就认为你的请求是不对了，没有任何的逻辑问题
现在是签名了啊
56楼 已删除
非常赞同你的说法
58楼 已删除
首先移动设备基本上应用走的是API请求方式，就不存在xsrf开启的问题，一般都是认证的方式。顺带说一下API开发也是目前Go做的最好的，用Go来写API太爽了。
如果是移动设备来操作web的话，那变了只能说页面你必须重新刷新了
session，简而言之就是在服务器上保存用户操作的历史信息
你的问题就是硬要给session加一个在服务器上这样的定语。
因此cookie存在着一定的安全隐患，例如本地cookie中保存的用户名密码被破译，或cookie被其他网站收集（例如：1. appA主动设置域B cookie，让域B cookie获取；2. XSS，在appA上通过javascript获取document.cookie，并传递给自己的appB）。
A域设置B域cookie是不可能的，浏览器会有同源策略，如果这样也可以web就乱套了。
对于XSS，有HTTP Only cookie和一楼所说的客户端session签名和加密策略防止重要cookie被篡改/窃取。
准确点说, 是这个框架没有签名 cookie 支持, 如果用了这个框架, cookie 就应该只用来存 session identifier 和存与用户身份不相干的信息. 使用时如果不知道这一点就很危险. 另外就是你的 sessionid 不支持 secure (https only) 的设定, 利用 dns 污染进行 session hijack 也是可能的, 不适合用来做电子商务收钱等安全性要求比较高的网站.
如果服务器跑在 nginx 后面, 通过 tcp 连接信息得来的 ip 都是同样的, 如果用户用了代理, 看到的 remote ip 都是同样的. 按照你的计算方式, 相同 ip, 同一时间的请求, 就会存在 csrf token 撞车的情况. 然后攻击者使用某个流行的 proxy 去访问你的网站来获取一个 token, 那么通过这个 proxy 的用户都有比较大的机会和攻击者的 token 撞车, 攻击者在他的伪造表单里自动更新这个 token 坐等鱼上钩. 你最后就只能寄希望在 nanotime 上了...
解决很简单, 增加一段随机字符串即可.
最后, 因为你没有防止篡改 cookie 的手段, 你的 csrf 不该放 cookie 而应该存在 session store 里 (你的情况就是 文件/数据库/redis/内存了), 或者继续把 csrf 放 cookie 里, 把签名附上也可以.
要挑刺是还可以给你提很多 issue 的 (flash 写成 falsh 就不提了...) ...
首先cookie是客户端的没错对吧，为了区别session现在所有的语言里面是不是都是存在服务器端的？当然我理解你的意思，你的session值存在cookie里面是不是cookie的值就变成session的值了。
appA和B的关系就是目前广告嵌入cookie的做法，在新浪的站点调用了XX的广告，然后XX的广告中了cookie。
至于XSS的问题根本就是我上面说的，在Go里面很难XSS，因为默认全部转义
第一点： 自己看到底有没有http only
第二点：nanotime我随机我觉得已经比你所谓的随机字符串好很多了
第三点：看看什么是签名
最后欢迎各种挑刺
flash 写成 falsh 就不提了
这个在哪里，我没看到啊，欢迎提啊
现代web框架 不是都把session存在客户端嘛...
对你模板默认转义就能避免XSS的观点不能认同，防御XSS需要根据外部输入所处的语境，单纯的自动转义只是防止开发者犯愚蠢的错误。
广告嵌入方式有很多种，流行的还都是第三方广告，通过iframe载入的，不存在跨域设置cookie的问题。
至于第一方广告，需要对广告提供方有足够的信任度才可以。
请仔细看... cookie 的 secure (https only) 和 httponly 不是同一个选项
那请继续这么做...
你是浪费好多 cpu 算了一段签名, 但是却不对它进行验证, 那有什么用...
只用时间作为随机因子确实不靠谱, &&白帽子讲Web安全&& 说的.
当然咯，这个需要程序员自己还要处理所有的输出，只是Go在这方面已经是最严格的输出，让开发者犯错误
这个是文档吧，谢谢
你为什么要测 gcc -O2 ... 你可以用 gcc -Og 来表明 go 更快呀
第一个、看错了，目前默认是false，确实不开放https的设置
第二个、随机时间的做法我觉得确实可以改进一下，但是目前两次随机的时间，两个用户相同是不可能的
第三个、认证这一块目前有一个pull request，目前还在review
随带说一下nginx之后的Go是可以拿到真实IP的
我觉得这个XSRF token的实现问题很大：
因子只有四个：
用户IP -& 轻易获得
时间 -& 轻易碰撞
XSRFKEY -&
算法 -& 框架开源，算法公开
所以我觉得很容易实施定向CSRF攻击的。
unixnano用了两个是不会碰撞的，XSRFKEY是用户可以设置的，除非破解了sha1算法
nginx 之后的 go 当然可以拿到 real ip, 但是
说的代理的情况, 甚至是一个路由下面的 ip 都是一样的.
nanotime 虽然不 那么 靠谱, 但是还不能说 轻易 碰撞, 况且两次更难, 但不那么严谨.
对于作者说, 换个 ip 就掉线, 我觉得对于普通用户都会觉得奇怪, 更别说了解 web 的程序员了.
gcc -Og这是什么命令啊？没听过
要对两种语言都有充分了解才能真正了解性能差别哦
好吧 有道理
是的，我还是觉得，IP放在里面除了添乱没起到任何防御CSRF的作用。
其实CSRF Token设置过期时间也是没什么必要的。
回家吃饭...
那啥CSRF token放在cookie里面有啥问题么？ 话说AngularJs就要求服务端设置一个csrf cookie（实际上除了放cookie根本没别的地方可以放啊，服务端整个页面都是静态模板，渲染是在客户端进行的）……另外为啥API就不需要CSRF？
拿secure cookie当session在ruby、php、python、node甚至go(gorilla)都很常见
ruby、php、python、node的主流模板默认对变量auto escaping已经是老黄历了
消息不对称很可怕
看到高手们热烈讨论，又学到了很多东西
我还是说清楚点... gcc 编译器 -O2 的优化程度一般般, 你可以试试 -O3, 如果是 clang 还可以 -O4 . -Og 的意思是加入了调试符号, 作用是让编译出来的 C 程序跑得更慢点.
C / ObjC / C++ 程序员基本不会上 Go 这条船的: 没有动态加载能力, 没有 macro, 没有 generic type, 没有 typed exception, 不支持手动内存管理, 欠缺抽象能力, 没有消息 dispatch 能力, 不支持函数式的 idiom, 代码里面大量 if (err != nil), 编译器做不了跨 obj file 分析, 运行时能力太弱, GC 太挫, 缺少丰富的 literal 语法... Go 代码其实是很底层的, 直接 1:1 映射到 assembler, 比起 C 的唯一优势是有字符串...
说起字符窜， 前阵还见人吐槽Go的大道至简就是把java和python里的bytes和unicode折腾成了bytes, utf-8 string和runes...
Go 里面函数是可以被当作参数传递，或者为返回值的，当然也支持匿名函数
难道C不可以？
C传的是函数指针，要模拟出closure还要另外传个void*之类的东西。如果要返回得传个void**。可以是可以不过麻烦得多
只是对 83楼 说不支持函数式的 idiom而言，C 语言里面指针这个东西，我不知道该不该算作弊。。。
不总是需要void *
golang的好处不在性能，在并发模型、库、工具链这些。
其实我认为web开发这类拼接下字符串的工作，用golang感觉和用C差不多，本身就没啥语法糖，对于重复性的体力劳动不像ruby那样能搞出各种DSL来提高表达效率。
麻烦你，gcc没有-Og命令，-o2，-o3我当然是怎么回事，麻烦看看gcc的命令啊
93楼 已删除
clang我没有用过，所以我不评价
版本原因？我的有
gcc (GCC) 4.7.2
(Red Hat 4.7.2-8)
一个刚冒出来的语言也好意思说库、工具链 ...
哇，你都用这么新了啊，我的确实没有
那应该就是4.8才引入的了
gcc 4.4这么老的版本估计连最新版的clang都比不过...
我用archlinux，挺激进的发行版
新版本我学习学习
我用vagrant装一个去
继续驳斥你各种观点：准确点说, 是这个框架没有签名 cookie 支持, 如果用了这个框架, cookie 就应该只用来存 session identifier 和存与用户身份不相干的信息. 使用时如果不知道这一点就很危险.
这一点的危险在哪里？为什么不能存类似csrf签名加密的cookie，你目前的cookie存都是怎么做的，签名cookie我自己签名过了存不可以嘛？
另外就是你的 sessionid 不支持 secure (https only) 的设定, 利用 dns 污染进行 session hijack 也是可能的, 不适合用来做电子商务收钱等安全性要求比较高的网站. 这个功能可以加，而且不是那么难的事情，你不用说的好像很严重的bug问题。
如果服务器跑在 nginx 后面, 通过 tcp 连接信息得来的 ip 都是同样的, 如果用户用了代理, 看到的 remote ip 都是同样的. 你不了解nginx吧
按照你的计算方式, 相同 ip, 同一时间的请求, 就会存在 csrf token 撞车的情况. 然后攻击者使用某个流行的 proxy 去访问你的网站来获取一个 token, 那么通过这个 proxy 的用户都有比较大的机会和攻击者的 token 撞车, 攻击者在他的伪造表单里自动更新这个 token 坐等鱼上钩. 你最后就只能寄希望在 nanotime 上了. 双重的unixNano能冲突的概率几乎没有，但是你们说的通过IP来做token认证确实可以改进的更好，例如uuid之类的，这一块后期我可以改进
最后, 因为你没有防止篡改 cookie 的手段, 你的 csrf 不该放 cookie 而应该存在 session store 里 (你的情况就是 文件/数据库/redis/内存了), 或者继续把 csrf 放 cookie 里, 把签名附上也可以. 目前的cookie是已经签名加密的，用户篡改的话能通过认证嘛？csrf不一定非得放session就是安全的。
IP的做法确实有待改进，我打算接下来用UUID来做这个认证，但是我还是觉csrf放在cookie是目前Go里面实现比较好的方法，不然引入session有点过度
105楼 已删除
采用securitycookie的话应该不会有很大的问题
107楼 已删除
所以在csrf里面增加过期时间
109楼 已删除
你们又聊回来了啊.???
目前的一个pull里面的代码其实已经有认证这一块了，只是这个代码我们还在review
欢迎大家各种意见啊，这样才能把框架做的更好
但是我觉得这个放的位置需要改进，还有一些实现的方式
还有目前时间的认证已经有了的
昨天本来去采购书籍，本来想买go的书来着...结果看了几页受不了了有点不符合我之前的逻辑，于是只好先弄了几本nodejs的书回去...lz推荐几本go的书呗？
116楼 已删除
我写了一本开源书，凑合着看看
uuid就可以啊
一个从讨论性能的帖子一下变成了讨论某策略实现上了。。。
你很懂, 没什么好讨论的了...
亲，不要这样嘛，讨论讨论还是很有帮助的，至少我知道了session需要增加https的支持，csrf里面的IP作为认证不可取，其实通过讨论还是学习到很多东西
谢谢各位的讨论，针对大家提出的一些意见，我努力改进了一下目前beego的csrf的做法
csrf在表单中存的是一个随机字符串，cookie采用了GetSecureCookie的方式，如下所示：
func (c *Controller) XsrfToken() string {
if c._xsrf_token == "" {
token, ok := c.GetSecureCookie(XSRFKEY, "_xsrf")
expire := 0
if c.XSRFExpire & 0 {
expire = c.XSRFExpire
expire = XSRFExpire
token = GetRandomString(15)
c.SetSecureCookie(XSRFKEY, "_xsrf", token, expire)
c._xsrf_token = token
return c._xsrf_token
至于 提出的session需要支持https的支持，目前已经增加额外的参数支持
虽然跑题了，但是跑的让人感觉学到不少东西。
谢老大写的就不错啊，正在学习中
嗯……打算学完node就学go……
，可以买两本，一本是许大牛的，一本是谢大牛的，侧重点不同，一个偏重基本语法，一个偏重
昨天看了一点go的东西，感觉不应该拿来和ruby比较，完全不是一种类型的语言。
go更像是简化了的，外加一些额外的语法糖的c，做为系统级别的语言更合适。
其实这个帖子也没有和ruby对比，但是你真要说和ruby对比，那ruby完全不能比，ruby是动态语言，Go是静态语言，所以不具有对比性，但是你可以了解一下Go，用来开发ruby擅长的Web方面，也不输多少。下面这个是ruby迁移到Go的经典案例：
Iron.io从Ruby迁移到Go：减少了28台服务器并避免了连锁故障：
减少了28台机器，go作为静态语言在速度上有优势是一方面，用ruby写的原本的那堆东西没有优化或者架构好也是一方面。我对web不是特别懂，以我有限的知识的角度来说，制约web性能的多数在IO上而不是语言层面。
另外虽然理论上ruby会比c这类静态语言慢十几倍，但实际应用场景下并没有这么大的差距，多数执行时间还是耗费在本身就是用c写的一些库上。ruby的优势是对程序员友好，弱点是慢。go作为系统级别的语言，和c比较更好，能说说和c比的优劣势么？
下面这些摘抄自《》 ，然后这一篇详细介绍了为什么设计Go 。
Go 中对 C 和 C++ 进行的重要简化的清单：
规范的语法（无需用于解析的符号表）
垃圾收集（唯一）
没有头文件
无循环依赖
常量只能为数字
int 和 int32 是不同的类型
字母大小写设定可见性
任何类型都可以有方法（没有类）
没有子类型继承（没有子类）
包级别初始化和定义好的初始化顺序
文件编译到一个包中
包级别的全局表达与顺序无关
没有算数转换（常量做了辅助处理）
隐式的接口实现（无需“implements”定义）
嵌入（没有向父类的升级）
方法如同函数一样进行定义（没有特的别位置要求）
方法就是函数
接口仅仅包含方法（没有数据）
方法仅通过名字匹配（而不是通过类型）
没有构造或者析构方法
后自增和后自减是语句，而不是表达式
没有前自增或前自减
赋值不是表达式
按照赋值、函数调用定义时的顺序执行（没有“sequence point”）
没有指针运算
内存总是零值初始化
对局部变量取地址合法
方法没有“this”
分段的堆栈
没有静态或其他类型注解
内建 string、slice、map
数组边界检查
除了这个简化清单和一些未提及的琐碎内容，我相信，Go 相比 C 或者 C++ 是更加有表达力的。少既是多。
据说吵来了，来看一下哈.
还有我觉得robbin的这一篇博客，也详细分析了ruby存在问题，我觉得对于rubyer来说，应该挺适合的，
其实是有意义的讨论，我们都是好孩子
其实大家不用过分纠结app server的性能吧，只要够用就行了，就算是GO的，就算是CGI的，能飙到好几万，但是后面还有其他很多瓶颈的地方，比如数据库、调用相关其他系统的API等，所以说，应该从整体系统架构来优化，该上cache的上cache，该集群的集群，该读写分离的读写分离等等，才能真正提高整体网站性能。
session只是一种概念吧，懂英文的都知道是会话的意思
Go这么复杂也好意思说简单
我宁愿用node.js~
这篇帖子讨论的很有意义，刚开始
态度不是很好，其实没必要这么紧张，别人能指出的一些不足，说明他们都认真去研究了你的作品，应该感到高兴。
这个页面上
beego 构建于 Go HTTP 服务器之上，而 Go 在最近的 性能评测 中显示其可同时服务多于 Rails 三至十倍 的请求。
这句话能不能改一下！
艾玛，Go这个还算复杂啊
go确实简单不少，相比c歧义也少，不过灵活性也降低了。
真的是太复杂太复杂了，概念那么多，一天都讲不完啊...
我没有紧张，也没有态度不好，我一直都是这样直来直去的性格，也许说的过了，但是我觉得激烈的讨论很有帮助啊，我是很欢迎大家一起来挑刺，帮我找出各种问题，因为毕竟靠一个人做框架是做不好的，大家的力量才能做好。所以我很跑到这里来很乐意和大家一起来探讨。
针对性能对比的话，这个上面的对比性能确实是这样，而且你看我上面提的iron的例子，都是ruby迁移到Go的案例，我觉得没必要修改吧
那些概念啊？我觉得一天应该可以了解基本了啊，你看浩哥写了两篇文章，我觉得你花个一下午应该就可以入门了：
都是从 rails 迁移过去的，然后报道一换就变成了从 ruby 迁移，把框架当成语言都是为了吸引眼球。换作其他 ruby 写的非阻塞的来做的话不一定就慢很多，可以看看这个
robbin 写的是讲做 ruby 开发的不应该老是看 rails，还有其他更适合的 ruby 框架
我没说ruby一定是性能差，robin写的文章里面也分析了rails存在的问题:总之，无论是Linkedin的移动API网关还是Iron.io的后台任务系统，用Ruby来编写，本身并不是问题，实践也有大量案例证明使用Goliath或者Sinatra编写高性能Web Service都是可行的。问题只是在于我们应该： Ruby off rails 了。
不过给你展示一下，sinatra的作者最近在写Go的代码， 所以我们需要的是拥抱变化，Go的并发比用ruby内部实现的多线程不知道简单多少
但是你拿 golang 跟 rails 这个 ruby 的框架 比较说快 三至十倍 的请求，能否直接写上使用的 golang 的框架的名字呢，这样才是框架跟框架之间比较嘛
这个对比里面什么都有，sinatra、rails，各种框架，各种语言
不是说那是个玩笑么
我没说sinatra要用Go写，而是作者在用Go写一些东西，最近一直在做这方面的研究开发，所以才会出来这样的笑话
我说的是那个http://beego.me/about里面同步并发的介绍，直接写上 beego 比 rails 快不就妥了，
是写了rails啊，没写ruby啊，但是比ruby也快啊
哦不对，写错引用了，应该是高性能这里。
不过点开那个链接看到Framework有个叫做go的，语言也是go，莫非在 golang 里面还真有个叫做 go 的框架么？
Go本身就是一个框架啊，内置的包足够强大
cookie直接用gorilla的securecookie就挺好的
二叉树对比测试，那个网站的作者说：目的是测试gc，不允许使用任何第三方和自定义的pool，而c语言的实现版本却使用了pool有作弊嫌疑，有人使用slice实现了一个版本的二叉树，在那个网站的单核32位评测下，C的速度是:12.84,Go的速度是:14.24,相差无几(链接： )，
可是那个网站评测作者拒绝采纳，更多细节可以去golang-nuts讨论。
Go 1.1相比之前版本性能提升非常明显，你可以抽空试试。Go现在的gc和调度器还比较落后(相比jvm)，gc到1.3才会成为100%精确的gc，而有了精确的gc才有实现分代、压缩，可移动gc的可能，这些都在不断开发中(想想ruby都多少年了最近的2.1才宣布实现了分代式的gc，汗～～搞gc的人才真不好找)，调度器目前也只有函数实体实现了抢占式调度,所以底层编译器这些优化的还有很多，这些都是影响性能的关键，所以性能这东西说实在的还得靠时间去优化，比的就是编译器效率，静态编译的语言发展到最后性能应该不是问题。相比llvm，6g/8g还有很多工作要做，另外一点：Go编译器的其中一个设计目标是快速的编译速度，这个可能会影响编译出代码的性能，具体看以后的优化程度了，像llvm这种，目前已经优化到极致，JVM也是优化了10多年了，JIT技术也非常成熟了，Go目前比这些肯定要差点。但差C语言10倍，这个不太可能，可以pprof一下Go代码找出瓶颈，部分测试情况下出现2-3倍还可以接受。
路过.. 按照ko1的说法, ruby不好搞generational GC主要是因为要和现存大量c extension保持兼容造成的，所以2.1才想出来个restricted generational GC。如果没有这个包袱，做个generational的出来不会如此困难。
Go有些库的性能确实比不完全是C写的极端优化的库性能要慢很多.
但是, 拿这个来证明Go语言比C语言慢10倍就比较扯了.
Go编译器的性能在2012年底已经和C很靠近(GCC测试10%差距).
但是, Go1.1和1.2在runtime和很多库的改进还是很大的(包含网络部分).
LLVM是很厉害, 有些测试也可以甩GCC很多.
go比c慢10倍的场景并不少见，比如二叉树测试：
你知道这个测试为什么Go比C慢10倍吗? 你看过2个语言的测试代码没有?
我是看过的. C语言是基于apr的pool实现, 而已还开启了openmp优化(这是标准C语言吗?).
Go语言是基于GC(不可否认Go语言的GC性能确实还有优化的余地),
如果也改用pool实现Go的测试就和C持平(17和15的差异).
各种实现的对比在:
Pool的实现代码在:
这个测试的性能很不公平, 因为C使用了apr_pool和openmp.
那如果用Go写个汇编或opencl的版本是不是也可以呢?
gcc 的 o2/o3 差别不大, 有个别的 o3 还不如 o2 快.
实际项目中，瓶颈都在数据库查询那块了，你数据库不可能只有一台服务器。。。。
所以最终瓶颈在网络。
所以其实平台架构更关键啊。。
我之前玩php，现在完全转到nodejs了～～
现在是 expressjs + rethinkdb做后端，前端AngularJS
..........
初步测试跟c++性能差不多
每次想看都删一堆
瓶颈不在语言，在各种IO上。。。。。简单的输出hello world的话随便起个httpserver都能飚这么高。。。
很赞同。这种抛开业务谈性能就是耍流氓。你把golang的各种库，数据库访问都加上，会发现差别并不大。Golang 如果非要往 web 上靠（P.S. 其实这货搞web是搞错了方向，先天不足，很难和其他web框架竞争，单纯的写点 REST API 还是可以的)，那么还会有很长的路要走。另外写后台服务，如果要保证7*24运行的服务，这种有异常也不允许挂掉的服务，没有 try catch 结构的语言是很不方便的，到处都要 if err != nil 引出异常，感觉很蛋痛，反正最近写 Golang worker 就很烦躁。接触Golang时间不长，一点挫见。
后方可回复, 如果你还没有账号请点击这里 。
共收到 168 条回复