search

smallnest / gitalk

gitalk for colobu
19 stars 0 forks source link

百万 Go TCP 连接的思考: 正常连接下的吞吐率和延迟 #95

Open smallnest opened 5 years ago

smallnest commented 5 years ago

https://colobu.com/2019/02/28/1m-go-tcp-connection-3/

zhbinary commented 5 years ago

大神 差一个 goroutine per conn和reactor epoll 在100w连接下的 吞吐测评 这个是很多人想知道的 从你前面的文章 我们只是知道 goroutine per conn 比epoll占用内存多，但是我们还并不知道goroutine per conn在百万连接下吞吐和延迟是否和epoll有差别，也许这个能说明百万级goroutine上下文切换的性能是否靠谱，很期待，谢谢

smallnest commented 5 years ago

@zhbinary 大神 差一个 goroutine per conn和reactor epoll 在100w连接下的 吞吐测评 这个是很多人想知道的 从你前面的文章 我们只是知道 goroutine per conn 比epoll占用内存多，但是我们还并不知道goroutine per conn在百万连接下吞吐和延迟是否和epoll有差别，也许这个能说明百万级goroutine上下文切换的性能是否靠谱，很期待，谢谢

已加

zhbinary commented 5 years ago

@smallnest

@zhbinary 大神 差一个 goroutine per conn和reactor epoll 在100w连接下的 吞吐测评 这个是很多人想知道的 从你前面的文章 我们只是知道 goroutine per conn 比epoll占用内存多，但是我们还并不知道goroutine per conn在百万连接下吞吐和延迟是否和epoll有差别，也许这个能说明百万级goroutine上下文切换的性能是否靠谱，很期待，谢谢

已加

没看到啊，加在哪里了，第二篇都是epoll的百万测评

zhbinary commented 5 years ago

@smallnest

@zhbinary 大神 差一个 goroutine per conn和reactor epoll 在100w连接下的 吞吐测评 这个是很多人想知道的 从你前面的文章 我们只是知道 goroutine per conn 比epoll占用内存多，但是我们还并不知道goroutine per conn在百万连接下吞吐和延迟是否和epoll有差别，也许这个能说明百万级goroutine上下文切换的性能是否靠谱，很期待，谢谢

已加

看到了 在第二篇加了

jonyhy96 commented 5 years ago

大佬 对比测试为什么这里要用for不断去写而多poller方式只写一次，这个对测试结果没有影响吗？

smallnest commented 5 years ago

因为测的就是这两种方式的性能

@jonyhy96 大佬 对比测试为什么这里要用for不断去写而多poller方式只写一次，这个对测试结果没有影响吗？

jonyhy96 commented 5 years ago

@smallnest 因为测的就是这两种方式的性能

@jonyhy96 大佬 对比测试为什么这里要用for不断去写而多poller方式只写一次，这个对测试结果没有影响吗？

感谢回复，如果我没有理解错的话,多poller方式每个conn应该是只执行了一次io.Copy而多routine却在for循环内不断的执行，这样不会产生影响吗？另外请问这个的err是漏写了吗？

smallnest commented 5 years ago

@jonyhy96

@smallnest 因为测的就是这两种方式的性能

@jonyhy96 大佬 对比测试为什么这里要用for不断去写而多poller方式只写一次，这个对测试结果没有影响吗？

感谢回复，如果我没有理解错的话,多poller方式每个conn应该是只执行了一次io.Copy而多routine却在for循环内不断的执行，这样不会产生影响吗？另外请问这个的err是漏写了吗？

这就是epoll 和 goroutine处理消息的不同姿势。 goroutine在不断循环，如果没有消息自己就阻塞了。 epoll一旦有消息就会读取一条消息，如果还有消息，接下来还会处理，这是epoll edge的处理方式。 所以测试case就是测试这两种不同开发方式的性能。

err漏了，已加上。

jonyhy96 commented 5 years ago

@smallnest

@jonyhy96

@smallnest 因为测的就是这两种方式的性能

@jonyhy96 大佬 对比测试为什么这里要用for不断去写而多poller方式只写一次，这个对测试结果没有影响吗？

感谢回复，如果我没有理解错的话,多poller方式每个conn应该是只执行了一次io.Copy而多routine却在for循环内不断的执行，这样不会产生影响吗？另外请问这个的err是漏写了吗？

这就是epoll 和 goroutine处理消息的不同姿势。 goroutine在不断循环，如果没有消息自己就阻塞了。 epoll一旦有消息就会读取一条消息，如果还有消息，接下来还会处理，这是epoll edge的处理方式。 所以测试case就是测试这两种不同开发方式的性能。

err漏了，已加上。

感谢回复，之前没注意到io.CopyN对于TCPCONN来说是一个阻塞的操作

thaiwu0107 commented 4 years ago

請問可以新增測試一下 prefork 的 IO 密集的測試嗎？

huizluo commented 4 years ago

prefork + workerpool 会不会有更好的结果，大佬请指教

kudoochui commented 3 years ago

第一个问题： 多epoller服务器：

连接 tps latency(s)
百万 197814 0.9
5000 210064 23.2
200 200998 0.9

对比这组数据，看不懂了。5000连接的延迟为什么这么高？这里的延迟是最大延迟吗？是不是达到20万吞吐的时候就掉连接了？ 第二个问题： goroutine-per-connection 服务器： 同时5000连接

连接 tps latency(s)
无sleep 203038 24
sleep 10ms 203088 0.02
哈希运算 211048 0.02

这个延迟，没做io和cpu模拟的延迟反而这么高，24秒？