S*A
发帖数: 7142 | 1 理论上用 goroutine 来替代 thread，
用 channel 协助调度是比较干净的一个模型。
但是实际中发现，如果每个 tcp 连接都是一个
goroutine 来处理，如果同时很多个 tcp 连接
同时并发发送数据，很容易就出现 tcp connection
reset。
google 了一下，发现有其他人抱怨类似的问题。
解决办法是用什么work pool 之类的限制并发
同时发送的数量。如果这么搞反而就比较麻烦了，
因为 goroutine 本来就是隔离了和 thread
这些打交道，用 work pool 这些其实就是变相
用 thread 来调度。隔靴挠痒的感觉。
求指点。
另外一个发现的问题是，go 貌似不能直接用 raw
data。从网络来到数据包需要经过 decode 过程
才能包裹到 go 的 struct。这个过程需要一个一个
byte shift 到其他类型的type 里面去。不知道
有没有其他好点办法.反正用 native go 貌似没
有好办法的，因为要 box go 的类型。低带宽的数据
可以这么搞，高带宽的数据这么过一下手会浪费一些
CPU。 |
s********k
发帖数: 6180 | 2 raw data应该有很成熟的JSON unmarshall包了啊，不是太大问题，TCP connection
reset确定是跟连接数有关吗？还是timeout，还是其他原因？理论上TCP连接和go
channel完全是独立事件，除非你哪里channel block了？
【在 S*A 的大作中提到】
: 理论上用 goroutine 来替代 thread，
: 用 channel 协助调度是比较干净的一个模型。
: 但是实际中发现，如果每个 tcp 连接都是一个
: goroutine 来处理，如果同时很多个 tcp 连接
: 同时并发发送数据，很容易就出现 tcp connection
: reset。
: google 了一下，发现有其他人抱怨类似的问题。
: 解决办法是用什么work pool 之类的限制并发
: 同时发送的数量。如果这么搞反而就比较麻烦了，
: 因为 goroutine 本来就是隔离了和 thread
|
S*A
发帖数: 7142 | 3 我没有解释清楚，raw data 经过打包是可以用的，但是打包
过程需要 copy 一次数据。这个看看https://golang.org/src/encoding/binary/
binary.go
这个貌似是最接近的了，里面要根据接受方的类型一个 byte 一个
byte 来拼凑数据。
tcp reset 这个这个问题直观上是并发的网络数目相关的。
这里用到的网络比较类似群讨论，server 上面挂一大堆 client。
server收到一个 message 就直接 forward 给一大堆 client。
不是 time out,直接 tcp reset 那个 connection 断了。
Anyway，google 看了一下，很多其他地方有提到，对于高并发这
些直接用 goroutine 来处理每个 tcp 连接是不合适的。
例如这里他们的解决办法是抛弃 goroutine 用 work pool：
http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/
goroutine 这个愿望是美好的，可惜现实是残酷的。
【在 s********k 的大作中提到】
: raw data应该有很成熟的JSON unmarshall包了啊，不是太大问题，TCP connection
: reset确定是跟连接数有关吗？还是timeout，还是其他原因？理论上TCP连接和go
: channel完全是独立事件，除非你哪里channel block了？
|
w********m
发帖数: 1137 | 4 不知道你怎么实现的，不好说。
每个client对应的是server上的一个channel。
如果reset太快，把channel改成buffered的channel可能好点。
有时候是资源耗尽了，disk IO，network IO，memory，etc
这时候要加semaphore控制并发。
你可以把The Go Programming Language 里面的chatroom编译一遍，看看能有多少并发。
【在 S*A 的大作中提到】
: 我没有解释清楚，raw data 经过打包是可以用的，但是打包
: 过程需要 copy 一次数据。这个看看https://golang.org/src/encoding/binary/
: binary.go
: 这个貌似是最接近的了，里面要根据接受方的类型一个 byte 一个
: byte 来拼凑数据。
: tcp reset 这个这个问题直观上是并发的网络数目相关的。
: 这里用到的网络比较类似群讨论，server 上面挂一大堆 client。
: server收到一个 message 就直接 forward 给一大堆 client。
: 不是 time out,直接 tcp reset 那个 connection 断了。
: Anyway，google 看了一下，很多其他地方有提到，对于高并发这
|
w***g
发帖数: 5958 | 5 是bug吧。如果是go的bug, 修好了可是大credit。不过我觉得是楼主参数没设好，资源
用光了。
：理论上用 goroutine 来替代 thread，
：用 channel 协助调度是比较干净的一个模型。 |
S*A
发帖数: 7142 | 6 channel 不是问题，每个 tcp socket 要对应一个 goroutine。
因为 go 鼓励的是 blocking 的编程模式。需要用 goroutine
来 block。感觉这个 goroutine 对应一个 socket 是不能上
大并发的。
network IO 是不可能耗尽的，就是 blocking 慢而以。
内存应该还好。
发。
【在 w********m 的大作中提到】
: 不知道你怎么实现的，不好说。
: 每个client对应的是server上的一个channel。
: 如果reset太快，把channel改成buffered的channel可能好点。
: 有时候是资源耗尽了，disk IO，network IO，memory，etc
: 这时候要加semaphore控制并发。
: 你可以把The Go Programming Language 里面的chatroom编译一遍，看看能有多少并发。
|
S*A
发帖数: 7142 | 7 内存还是大大的有。其他还能有什么资源。
感觉是 go 的编程模式的问题。
比较正规的解法是用 epoll 这种 call back 的方式来处理的。
go 用那个 non blocking mode IO 和goroutine 在即将要
block 的时候才去换goroutine。这种方式上不了比较大规模。
anyway。 网上看来有不少分享都是要上大并发要去掉 goroutine。
这个我感觉应该是 go 本身编程模式的问题。go 自己的 scheduler
并不适合干大并发。你想想每个 goroutine 都有自己的context
内存。连接多了这个很费的。
【在 w***g 的大作中提到】
: 是bug吧。如果是go的bug, 修好了可是大credit。不过我觉得是楼主参数没设好，资源
: 用光了。
:
: ：理论上用 goroutine 来替代 thread，
: ：用 channel 协助调度是比较干净的一个模型。
|
w********m
发帖数: 1137 | 8 哦，我大概知道原因了。
你可能把server对client的读和写放到一个goroutine了，造成blocking。
每个client应该对应server上面两个goroutine，一个读，一个写。
这样server上minimal goroutine number应该是2*N + 2
N是client的数目。
还要有个main goroutine和一个scheduler。
goroutine很便宜，一个只要2KB内存，多开几个无妨。
【在 S*A 的大作中提到】
: channel 不是问题，每个 tcp socket 要对应一个 goroutine。
: 因为 go 鼓励的是 blocking 的编程模式。需要用 goroutine
: 来 block。感觉这个 goroutine 对应一个 socket 是不能上
: 大并发的。
: network IO 是不可能耗尽的，就是 blocking 慢而以。
: 内存应该还好。
:
: 发。
|
S*A
发帖数: 7142 | 9
我 double check 了一下，已经是读和写分别一个 goroutine 了。
所以不是这个问题。
多开几个无妨，我也是这么想的。但是实际情况不是这样。
我感觉上是多开了 goroutine 会影响schedule 到那个
tcp socket 的相应时间。或者有什么其他的bug。
在了解到一些 goroutine 的内部实现细节以后，例如是
基于 non blocking io 这些。 我越来越觉得这个 goroutine
对付简单情况可以，很多 goroutine 不太能 scale 的。
【在 w********m 的大作中提到】
: 哦，我大概知道原因了。
: 你可能把server对client的读和写放到一个goroutine了，造成blocking。
: 每个client应该对应server上面两个goroutine，一个读，一个写。
: 这样server上minimal goroutine number应该是2*N + 2
: N是client的数目。
: 还要有个main goroutine和一个scheduler。
: goroutine很便宜，一个只要2KB内存，多开几个无妨。
|
w***g
发帖数: 5958 | 10 你这个情况，大并发，是go的核心竞争力。如果这都搞不定，还要go干嘛。如果只是几
千个thread, pthread就够了啊。
：
：【 在 walkrandom (walkrandom) 的大作中提到: 】 |
|
|
w********m
发帖数: 1137 | 11 那server上面，有多少个channel？
如果少于client的数目，也可能造成堵塞。
【在 S*A 的大作中提到】
:
: 我 double check 了一下，已经是读和写分别一个 goroutine 了。
: 所以不是这个问题。
: 多开几个无妨，我也是这么想的。但是实际情况不是这样。
: 我感觉上是多开了 goroutine 会影响schedule 到那个
: tcp socket 的相应时间。或者有什么其他的bug。
: 在了解到一些 goroutine 的内部实现细节以后，例如是
: 基于 non blocking io 这些。 我越来越觉得这个 goroutine
: 对付简单情况可以，很多 goroutine 不太能 scale 的。
|
L*******k
发帖数: 42 | 12 题外话。你们这样一会儿go一会儿coroutine的搞高并发是不是在钻牛角尖走火入魔？
就算是你
们看不上的java+thread，拿台c3.2xlarge也随便处理几个K的qps啊。问题是你能有几
个K的qps？几十个K？又换句话说你都几十个K的在线业务量级了，公司起码也是若干B
的市值了吧，你拿go折腾来折腾去一年能省多少几块钱下来。
说白了就是钻技术不要太深，还是要最终outcome/impact为主导。
话说我们公司前几年就有个部门的一帮人装逼用Go写rpc server，结果问题一大堆，
跟公司其他Java为主的后端工程开发格格不入，怨声载道。 |
g****t
发帖数: 31659 | 13 你们公司写go rpc替代java的不是为了装逼。
是为了取代java的人，自己往上走。竞争是血腥残酷的。不出问题是不可能的。
不怨声载道也是不可能的。
后端新人要上位，靠java是不可能的。这不是技术问题。技术业务政治一起卡
位的老师傅多的是。
B
【在 L*******k 的大作中提到】
: 题外话。你们这样一会儿go一会儿coroutine的搞高并发是不是在钻牛角尖走火入魔？
: 就算是你
: 们看不上的java+thread，拿台c3.2xlarge也随便处理几个K的qps啊。问题是你能有几
: 个K的qps？几十个K？又换句话说你都几十个K的在线业务量级了，公司起码也是若干B
: 的市值了吧，你拿go折腾来折腾去一年能省多少几块钱下来。
: 说白了就是钻技术不要太深，还是要最终outcome/impact为主导。
: 话说我们公司前几年就有个部门的一帮人装逼用Go写rpc server，结果问题一大堆，
: 跟公司其他Java为主的后端工程开发格格不入，怨声载道。
|
w********m
发帖数: 1137 | 14 一台server上，如果用docker container，java大概比go多两百兆。十个container，
就是2G。
看公司规模，大概几千台server就可以省出一个程序员的工资了。
B
【在 L*******k 的大作中提到】
: 题外话。你们这样一会儿go一会儿coroutine的搞高并发是不是在钻牛角尖走火入魔？
: 就算是你
: 们看不上的java+thread，拿台c3.2xlarge也随便处理几个K的qps啊。问题是你能有几
: 个K的qps？几十个K？又换句话说你都几十个K的在线业务量级了，公司起码也是若干B
: 的市值了吧，你拿go折腾来折腾去一年能省多少几块钱下来。
: 说白了就是钻技术不要太深，还是要最终outcome/impact为主导。
: 话说我们公司前几年就有个部门的一帮人装逼用Go写rpc server，结果问题一大堆，
: 跟公司其他Java为主的后端工程开发格格不入，怨声载道。
|
g****t
发帖数: 31659 | 15 You can always assume and explain some application scenarios to defend any
opinions and that was the art of business.
Overall, I think Golang would be unstoppable because Rob Pike
and google had already built these fake/true application user cases for you.
Who was still doing same things for Java? Oracle?
【在 w********m 的大作中提到】
: 一台server上，如果用docker container，java大概比go多两百兆。十个container，
: 就是2G。
: 看公司规模，大概几千台server就可以省出一个程序员的工资了。
:
: B
|
L*******k
发帖数: 42 | 16 几千的container你这是Million/sec级别的业务吞吐吧，公司得有成百上千程序员吧，
省下来那点点远不能成为你justify language层面的决策
：
：一台server上，如果用docker container，java大概比go多两百兆。十个container， |
S*A
发帖数: 7142 | 17
你去看看我前面引用的文章讨论了这个问题而且给出了
解决办法。
http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/
简单的说，就是不能用简单的goroutine 对应一个 tcp
socket 的方法。需要搞 server pool 这些。避免
太多 goroutine 来处理并发。
不是说 go 不能搞，是不能简单粗暴用 goroutine 和
tcp connection 对应的阻塞方式指望 go 的 scheduler
能解决大并发问题。
【在 w***g 的大作中提到】
: 你这个情况，大并发，是go的核心竞争力。如果这都搞不定，还要go干嘛。如果只是几
: 千个thread, pthread就够了啊。
:
: ：
: ：【 在 walkrandom (walkrandom) 的大作中提到: 】
|
S*A
发帖数: 7142 | 18 channel 绝对没有少于 client 数目，可能是几倍，
至少两倍以上，一个读一个写，还有其他的我没有仔细数。
最开始写这个的哥们完全是按照 go 的精神来写的。
【在 w********m 的大作中提到】
: 那server上面，有多少个channel？
: 如果少于client的数目，也可能造成堵塞。
|
S*A
发帖数: 7142 | 19 这个我们的确有这个需求，至少要 demo 能够处理这样的流量。
如果是我一个人写和维护就直接 C + epoll 橹了，而且保证是最优化的。
这个 go 的头不是我开的，但是也不是完全没有解就是了。
其实说白了就是放弃 goroutine N：1 tcp 的对应关系。
然后把 go 当 C 写，自己处理 server pool，epoll 这些。
网上有人讨论这个基本上是这个结果。
java 就算了吧。我这个不是典型的 web 后段应用，
有其他考虑，java 基本上不考虑了。
B
【在 L*******k 的大作中提到】
: 题外话。你们这样一会儿go一会儿coroutine的搞高并发是不是在钻牛角尖走火入魔？
: 就算是你
: 们看不上的java+thread，拿台c3.2xlarge也随便处理几个K的qps啊。问题是你能有几
: 个K的qps？几十个K？又换句话说你都几十个K的在线业务量级了，公司起码也是若干B
: 的市值了吧，你拿go折腾来折腾去一年能省多少几块钱下来。
: 说白了就是钻技术不要太深，还是要最终outcome/impact为主导。
: 话说我们公司前几年就有个部门的一帮人装逼用Go写rpc server，结果问题一大堆，
: 跟公司其他Java为主的后端工程开发格格不入，怨声载道。
|
S*A
发帖数: 7142 | 20 这个项目 java 是不太能用的，有其他的考虑。
如果是我自己写最爱是 C，这个我很精通。
但是如果不能用 C 的话，go 大概是最接近的一个了。
其他相关的人和项目有用 go 的话，对我来说
是可以接受的选择。
Anyway， 讨论 go vs java 这个非技术层面的
东西大概不会有什么结果。
you.
【在 g****t 的大作中提到】
: You can always assume and explain some application scenarios to defend any
: opinions and that was the art of business.
: Overall, I think Golang would be unstoppable because Rob Pike
: and google had already built these fake/true application user cases for you.
: Who was still doing same things for Java? Oracle?
|
|
|
w***g
发帖数: 5958 | 21 你这个我知道的。我是说go当年试图解决的pain point就是
能无脑concurrency。我也一直以为它能实现的。一旦需要
手工模拟线程，就一点意思也没有了啊。像docker这种用go，
其实是在当python用，跟性能没关系。
其实做高性能网络服务不是编程语言的问题，而是操作系统
甚至网卡驱动的问题。从你这个帖子看这些知识还是有用的。
现在做超高吞吐量是DPDK这一路。seastar和腾讯的f-stack。
go这一路确实比较尴尬。
吹牛容易，真做点东西都挺难的。
【在 S*A 的大作中提到】
: 这个项目 java 是不太能用的，有其他的考虑。
: 如果是我自己写最爱是 C，这个我很精通。
: 但是如果不能用 C 的话，go 大概是最接近的一个了。
: 其他相关的人和项目有用 go 的话，对我来说
: 是可以接受的选择。
: Anyway， 讨论 go vs java 这个非技术层面的
: 东西大概不会有什么结果。
:
: you.
|
s********k
发帖数: 6180 | 22 Go哪里算鼓励blocking编程啊，完全相反吧，channel你不能理解成block，理解成更好
manage的lock更合适，你这么一说感觉是不是你的channel buffer没有开够啊，比如你
的req和rsp各自goroutine，但是中间用一个channel share info，如果channel
buffer不够，总是会出现producer、consumer这样问题吧
【在 S*A 的大作中提到】
: channel 不是问题，每个 tcp socket 要对应一个 goroutine。
: 因为 go 鼓励的是 blocking 的编程模式。需要用 goroutine
: 来 block。感觉这个 goroutine 对应一个 socket 是不能上
: 大并发的。
: network IO 是不可能耗尽的，就是 blocking 慢而以。
: 内存应该还好。
:
: 发。
|
w***g
发帖数: 5958 | 23 这个说法靠谱。我在stack overflow也查到了类似的答案，不过我不懂不敢乱说。
【在 s********k 的大作中提到】
: Go哪里算鼓励blocking编程啊，完全相反吧，channel你不能理解成block，理解成更好
: manage的lock更合适，你这么一说感觉是不是你的channel buffer没有开够啊，比如你
: 的req和rsp各自goroutine，但是中间用一个channel share info，如果channel
: buffer不够，总是会出现producer、consumer这样问题吧
|
s********k
发帖数: 6180 | 24 感觉你有点混淆了：goroutine和channel是两回事，理论上你开无数个goroutine只要
没有数据交互一个channel不开都可以，当然实际上基本不可能。你的问题是一个TCP连
接对应一个goroutine，不应该是channel。
所以channel的数量也不是关键，关键是channel的buffer size，看我上一个回复，如
果有producer consumer问题，你开很多channel，但是每个channel都没有buffer，那
还是会blocking。
【在 S*A 的大作中提到】
: channel 绝对没有少于 client 数目，可能是几倍，
: 至少两倍以上，一个读一个写，还有其他的我没有仔细数。
: 最开始写这个的哥们完全是按照 go 的精神来写的。
|
S*A
发帖数: 7142 | 25
Go 和 python 性能还是强太多，不是一个级别的东西。
我就是想说这个，goroutine 直接简单粗暴上了数量
效果是不好的。
还没有到 DPDK 这样变态。而且 DPDK 移植性比较弱。
调硬件平台。
【在 w***g 的大作中提到】
: 你这个我知道的。我是说go当年试图解决的pain point就是
: 能无脑concurrency。我也一直以为它能实现的。一旦需要
: 手工模拟线程，就一点意思也没有了啊。像docker这种用go，
: 其实是在当python用，跟性能没关系。
: 其实做高性能网络服务不是编程语言的问题，而是操作系统
: 甚至网卡驱动的问题。从你这个帖子看这些知识还是有用的。
: 现在做超高吞吐量是DPDK这一路。seastar和腾讯的f-stack。
: go这一路确实比较尴尬。
: 吹牛容易，真做点东西都挺难的。
|
S*A
发帖数: 7142 | 26 buffer 足够，内存不是问题。
就算你有足够buffer，网卡不是一次能传完的，
还是回到调度问题。如果你有很多 goroutine，
如何在几万个goroutine 里面调度不是一个容易的
事情。
go 的编程模式是让 goroutine 写成连续的一个
类似进程的东西。这个方式看来是没法上大规模的。
你看看 go 为什么拒绝提供 net 上的 epoll API。
就是觉得 epoll 这种 event + callback
驱动 IO 的方式和 go 的精髓不合。
我觉得是个 goroutine 调度问题，你一定要说是
channel 问题我也没法。你去仔细看看我提供的
那个连接，连接里有提到这个问题和解决的。非常印证
我的直观理解。
【在 s********k 的大作中提到】
: Go哪里算鼓励blocking编程啊，完全相反吧，channel你不能理解成block，理解成更好
: manage的lock更合适，你这么一说感觉是不是你的channel buffer没有开够啊，比如你
: 的req和rsp各自goroutine，但是中间用一个channel share info，如果channel
: buffer不够，总是会出现producer、consumer这样问题吧
|
S*A
发帖数: 7142 | 27 这个不是我混淆了，我很清楚goroutine 和channel 两回是。
是前面那位一定要拿 channel 数和 goroutine 的关系来说。
我是想说，这个 channel 和 goroutine 关系不是问题。
关键问题是 goroutine 对应 tcp 连接这个不能 1：1.
1：1 的话上量会出问题的。
【在 s********k 的大作中提到】
: 感觉你有点混淆了：goroutine和channel是两回事，理论上你开无数个goroutine只要
: 没有数据交互一个channel不开都可以，当然实际上基本不可能。你的问题是一个TCP连
: 接对应一个goroutine，不应该是channel。
: 所以channel的数量也不是关键，关键是channel的buffer size，看我上一个回复，如
: 果有producer consumer问题，你开很多channel，但是每个channel都没有buffer，那
: 还是会blocking。
|
s********k
发帖数: 6180 | 28 我说的buffer不是内存buffer，是go channel buffer：https://gobyexample.com/
channel-buffering
或者这么简单说，你的几万个goroutine之间需要互相交换什么信息吗？如果整个设计
上很多地方就是需要blocking，那么确实go没有办法做到最高效。所以我理解对于大规
模 I/O交互的应用，可能Go并不一定比epoll + event callback高效这是确实，
看看这个？https://eklitzke.org/goroutines-nonblocking-io-and-memory-usage
【在 S*A 的大作中提到】
: buffer 足够，内存不是问题。
: 就算你有足够buffer，网卡不是一次能传完的，
: 还是回到调度问题。如果你有很多 goroutine，
: 如何在几万个goroutine 里面调度不是一个容易的
: 事情。
: go 的编程模式是让 goroutine 写成连续的一个
: 类似进程的东西。这个方式看来是没法上大规模的。
: 你看看 go 为什么拒绝提供 net 上的 epoll API。
: 就是觉得 epoll 这种 event + callback
: 驱动 IO 的方式和 go 的精髓不合。
|
n******7
发帖数: 12463 | 29 说得太对了，特地登陆赞一个
就是我这种职场新人，其实也类似心思
我就总想整点新玩意
觉得那些老人技术精，业务熟，也混了多年会来事
不另起炉灶全没机会
不过你不点明我自己都没清楚意识到
【在 g****t 的大作中提到】
: 你们公司写go rpc替代java的不是为了装逼。
: 是为了取代java的人，自己往上走。竞争是血腥残酷的。不出问题是不可能的。
: 不怨声载道也是不可能的。
: 后端新人要上位，靠java是不可能的。这不是技术问题。技术业务政治一起卡
: 位的老师傅多的是。
:
: B
|
s********k
发帖数: 6180 | 30 go毕竟去掉了JVM这层东西，直接native，这个不光是效率，而且其中专利，各种利益
在JVM上太多。天朝J20性能再好用的是鹅毛发动机，都不会放心，必须自己搞出来
某种意义上确实是卡位竞争，不光是纯粹技术决定
【在 n******7 的大作中提到】
: 说得太对了，特地登陆赞一个
: 就是我这种职场新人，其实也类似心思
: 我就总想整点新玩意
: 觉得那些老人技术精，业务熟，也混了多年会来事
: 不另起炉灶全没机会
: 不过你不点明我自己都没清楚意识到
|
|
|
n******7
发帖数: 12463 | 31 可是看各种benchmark，GO跟JAVA/C#一个水平啊
基本都是C的一半速度
【在 s********k 的大作中提到】
: go毕竟去掉了JVM这层东西，直接native，这个不光是效率，而且其中专利，各种利益
: 在JVM上太多。天朝J20性能再好用的是鹅毛发动机，都不会放心，必须自己搞出来
: 某种意义上确实是卡位竞争，不光是纯粹技术决定
|
h**********c
发帖数: 4120 | 32 这就是说书前面提到，搞桥梁公路风镐气锤用什么，似乎不是因果关系。
【在 n******7 的大作中提到】
: 可是看各种benchmark，GO跟JAVA/C#一个水平啊
: 基本都是C的一半速度
|
s********k
发帖数: 6180 | 33 速度还是大部分情况快于JAVA。C#，内存更是省。当然就像前面说的，性能只是一方面
，处理dependency，deploy这些上Go和container的方法还是太方便了。然后就是更多
卡位，大公司的斗争都是起作用甚至更大作用。
我个人感觉抛开政治，卡位这些，Golang最合适的还是做中间层，比如exchange这些，
业务逻辑上Java、C#这些OO的还是好点，更多底层和IO，OS打交道的C，C++用的更多。
【在 n******7 的大作中提到】
: 可是看各种benchmark，GO跟JAVA/C#一个水平啊
: 基本都是C的一半速度
|
n******7
发帖数: 12463 | 34 忘记内存了，这个确实是个巨大优势
另外deployment也是巨大优势
就是没有operator overloading是个巨大劣势
还是看干什么吧
我琢磨琢磨有没有什么事情可以用上
【在 s********k 的大作中提到】
: 速度还是大部分情况快于JAVA。C#，内存更是省。当然就像前面说的，性能只是一方面
: ，处理dependency，deploy这些上Go和container的方法还是太方便了。然后就是更多
: 卡位，大公司的斗争都是起作用甚至更大作用。
: 我个人感觉抛开政治，卡位这些，Golang最合适的还是做中间层，比如exchange这些，
: 业务逻辑上Java、C#这些OO的还是好点，更多底层和IO，OS打交道的C，C++用的更多。
|
L*******k
发帖数: 42 | 35 所以说你折腾来折腾去其实跟go不go，并发大不大，没有半毛钱关系，就是想把老司机
也拉回起跑线而已。
公司上规模了，也轮不到你来决定用什么语言。
【在 n******7 的大作中提到】
: 说得太对了，特地登陆赞一个
: 就是我这种职场新人，其实也类似心思
: 我就总想整点新玩意
: 觉得那些老人技术精，业务熟，也混了多年会来事
: 不另起炉灶全没机会
: 不过你不点明我自己都没清楚意识到
|
S*A
发帖数: 7142 | 36
我知道这个 ：-），不是这个问题。
发送的不需要交互，拿到新的 message 需要尽快 publish 给所有其他的 client 。
client 会根据收到的东西发回一个 reply message。这个 reply message
需要有点交互，例如 server 端 update 某些信息要上锁这些。
可以用 Go 自己做 epoll + event。我正在实验。我已经看出来会比
goroutine 好很多。
直接用 goroutine 1：1 socket 不适合做大并发，这个是我想讨论的事情。
其实远远没有到大并发简单的就不行了，大家有兴趣可以试试。这个是我用了
了一下 go 觉得比较坑的地方。
【在 s********k 的大作中提到】
: 我说的buffer不是内存buffer，是go channel buffer：https://gobyexample.com/
: channel-buffering
: 或者这么简单说，你的几万个goroutine之间需要互相交换什么信息吗？如果整个设计
: 上很多地方就是需要blocking，那么确实go没有办法做到最高效。所以我理解对于大规
: 模 I/O交互的应用，可能Go并不一定比epoll + event callback高效这是确实，
: 看看这个？https://eklitzke.org/goroutines-nonblocking-io-and-memory-usage
|
n******7
发帖数: 12463 | 37 对，一定程度是这样，也有自己个人的偏好
我们这里还是有一定自由度的，我的头应该可以决定什么语言
他前几天还说某个team里面居然有人用erlang
【在 L*******k 的大作中提到】
: 所以说你折腾来折腾去其实跟go不go，并发大不大，没有半毛钱关系，就是想把老司机
: 也拉回起跑线而已。
: 公司上规模了，也轮不到你来决定用什么语言。
|
S*A
发帖数: 7142 | 38 我对用语言做卡位和政治斗争这些非常不感兴趣。
对 JAVA 非常不感兴趣，个人偏见和固执。
然后对技术细节和如何用比较好的技术手段达到
技术上的目的感兴趣。
希望大家多往技术方向讨论哈。 |
w********m
发帖数: 1137 | 39 java没有问题，只是有些人态度有问题。
最近有个例子，把java的logstash换到go的filebeat，performance可以提高十倍。
搞java的人说，不换也没有关系，可以加机器啊。
然后要他们维护多出来的机器，又不愿意干。
所以，对于不想学，也不想做的人，没法改变。 |
s********k
发帖数: 6180 | 40 你自己配置这个肯定更好，因为IO交互性应用，goroutine的schedule不一定会比epoll
这个更好，个人感觉你的问题不是goroutine 1：1 socket 不适合做大并发， 而是IO
密集型go不如手动好，就像开车自动车舒服省心，但是追求极致性能就需要手动档，go
的目的就是为了给大多数手动觉得麻烦人提供便利
话说你的go+epoll，现在最新的go1.9是不是也在做了？你是打算用C写底层，然后
signal去go吗？
【在 S*A 的大作中提到】
: 我对用语言做卡位和政治斗争这些非常不感兴趣。
: 对 JAVA 非常不感兴趣，个人偏见和固执。
: 然后对技术细节和如何用比较好的技术手段达到
: 技术上的目的感兴趣。
: 希望大家多往技术方向讨论哈。
|
|
|
s********k
发帖数: 6180 | 41 看了下你的逻辑，你现在这样实现？
go func(recv socket)?
如果成这样是不是更好？
func recv(socket){
for pub in range publishers{
go func(service)
}
}
就是说把goroutine用在业务逻辑，不是IO上？
epoll
IO
go
【在 s********k 的大作中提到】
: 你自己配置这个肯定更好，因为IO交互性应用，goroutine的schedule不一定会比epoll
: 这个更好，个人感觉你的问题不是goroutine 1：1 socket 不适合做大并发， 而是IO
: 密集型go不如手动好，就像开车自动车舒服省心，但是追求极致性能就需要手动档，go
: 的目的就是为了给大多数手动觉得麻烦人提供便利
: 话说你的go+epoll，现在最新的go1.9是不是也在做了？你是打算用C写底层，然后
: signal去go吗？
|
S*A
发帖数: 7142 | 42
epoll
是一定更差啦。关键是差的比较远，我有点吃惊而以。
IO
goroutine 太多 go 自己调度不过来，这个的确会是个问题。
go
go 1.9 的 epoll不知道啊，新的 goroutine 可能已经用 epoll了，
但是还是不如直接控制 epoll + callback。 goroutine 太多我意识到
是个无解的问题。
go 可以直接 system call 调用的。可以用全部 go 来做。
如果我 C 写底层我就直接 C 全部橹了，只考虑 Linux epoll 其实不复杂，
我写过。复杂的是想上面包各种各样东西兼容 kqueue 这些。
【在 s********k 的大作中提到】
: 你自己配置这个肯定更好，因为IO交互性应用，goroutine的schedule不一定会比epoll
: 这个更好，个人感觉你的问题不是goroutine 1：1 socket 不适合做大并发， 而是IO
: 密集型go不如手动好，就像开车自动车舒服省心，但是追求极致性能就需要手动档，go
: 的目的就是为了给大多数手动觉得麻烦人提供便利
: 话说你的go+epoll，现在最新的go1.9是不是也在做了？你是打算用C写底层，然后
: signal去go吗？
|
S*A
发帖数: 7142 | 43
不知道你想如何改这个。现在问题是有 N 个 tcp 连接。
每一个发送都会有可能 block。如果你里面那个 for
loop 也是 N 个元素的话，并没有节省 goroutine。
如果里面那个 for loop service， << N 的话，那就是
发送的时候是等一个 tcp 发完了才发下一个，失去了
并发性。发送的数据包比一个Ethernet 包大多了。
一个 tcp 发玩一组才发下一个的带宽用不满。
【在 s********k 的大作中提到】
: 看了下你的逻辑，你现在这样实现？
: go func(recv socket)?
: 如果成这样是不是更好？
: func recv(socket){
: for pub in range publishers{
: go func(service)
: }
: }
: 就是说把goroutine用在业务逻辑，不是IO上？
:
|
s********k
发帖数: 6180 | 44 可能没写清楚，就是不用go做TCP recv这一套交给epoll，你不是接受回来数据之后要
发送到message queue/pub service？把这一部分做成goroutine？
【在 S*A 的大作中提到】
:
: 不知道你想如何改这个。现在问题是有 N 个 tcp 连接。
: 每一个发送都会有可能 block。如果你里面那个 for
: loop 也是 N 个元素的话，并没有节省 goroutine。
: 如果里面那个 for loop service， << N 的话，那就是
: 发送的时候是等一个 tcp 发完了才发下一个，失去了
: 并发性。发送的数据包比一个Ethernet 包大多了。
: 一个 tcp 发玩一组才发下一个的带宽用不满。
|
S*A
发帖数: 7142 | 45 哦，如果 epoll 不是 go 做的话，如何交接收到的数据是个问题。
需要按照 go 的规则把收下的数据包打包成 go 的 object。
这个如果 epoll 用 go 来写也需要有同样的过程。
所以我现在看看纯 go 来写 epoll call back如何。
上层用 goroutine 来写是没有问题的。但是同样要限制数目。
goroutine 太多其实没有帮助，只能帮倒忙。因为你的 CPU
个数是有限的，一次能真正同时做的东西有限。多出来的
goroutine 之间的调度是浪费。相比之下，call back 的代
价要小很多，没有切换 context 的问题。没有 goroutine
霸占的 context 的内存问题。
【在 s********k 的大作中提到】
: 可能没写清楚，就是不用go做TCP recv这一套交给epoll，你不是接受回来数据之后要
: 发送到message queue/pub service？把这一部分做成goroutine？
|
s********k
发帖数: 6180 | 46 golfing poll, 看看这个？https://github.com/mailru/easygo/blob/master/netpoll
/epoll.go
goroutine根据业务需要来开就可以，确实没有必要开太多，如果一个pod上开太多本来
资源就不够啊（假设你用k8s的话）
【在 S*A 的大作中提到】
: 哦，如果 epoll 不是 go 做的话，如何交接收到的数据是个问题。
: 需要按照 go 的规则把收下的数据包打包成 go 的 object。
: 这个如果 epoll 用 go 来写也需要有同样的过程。
: 所以我现在看看纯 go 来写 epoll call back如何。
: 上层用 goroutine 来写是没有问题的。但是同样要限制数目。
: goroutine 太多其实没有帮助，只能帮倒忙。因为你的 CPU
: 个数是有限的，一次能真正同时做的东西有限。多出来的
: goroutine 之间的调度是浪费。相比之下，call back 的代
: 价要小很多，没有切换 context 的问题。没有 goroutine
: 霸占的 context 的内存问题。
|
S*A
发帖数: 7142 | 47
netpoll
现在试的就是这个。感受就是，你基本上要很熟悉 C 的那个 epoll
是如何写的，然后再等价转换到 go 去。如果写不出 C 的 epoll
完整玩法，也没法理解这个 go 的 epoll 是如何玩的。基本上类似
隔着 go 写 C 代码。那个 netpoll 只是 epoll 部分的 API。
不少复杂的地方在上层什么时候用这个 read，有没有把 socket
读干净这些。（读干净才会重新 arm edge trigger）。
那个 netpoll 基本上就是个 epoll 的系统调用的接口而以，
然后包了其他古古怪怪的 API 名字，没有太多东西。
是的，所以觉得比较坑上来抱怨一下。Go 其他设计还是感觉大体合理的。
【在 s********k 的大作中提到】
: golfing poll, 看看这个？https://github.com/mailru/easygo/blob/master/netpoll
: /epoll.go
: goroutine根据业务需要来开就可以，确实没有必要开太多，如果一个pod上开太多本来
: 资源就不够啊（假设你用k8s的话）
|
