V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lesismal  ›  全部回复第 59 页 / 共 63 页
回复总数  1248
1 ... 51  52  53  54  55  56  57  58  59  60 ... 63  
2021-02-25 13:13:08 +08:00
回复了 lesismal 创建的主题 分享创造 发布个 golang 高性能异步网络框架 nbio,单击百万不是梦!
@guotie 慢慢来吧,有需要的朋友用就行。以后有时间了我再多写些其他的,毕竟绝大多数人的需要是业务框架,多谢老铁支持!
2021-02-25 12:20:48 +08:00
回复了 lesismal 创建的主题 分享创造 发布个 golang 高性能异步网络框架 nbio,单击百万不是梦!
@lairdnote

既然回帖的各路大神画风都很自信了,我也就不谦虚了

老夫本人就是系统架构,老夫搞这些就是为了解决、优化这些问题
2021-02-25 12:18:31 +08:00
回复了 lesismal 创建的主题 分享创造 发布个 golang 高性能异步网络框架 nbio,单击百万不是梦!
@byte10 兄弟,你可以先看下我 4 楼里说的场景,还可以自己稍微测一下 go 标准库的 net.Conn 对比 epoll 这类的内存占用情况以及连接数很多时候的情况比如至少 1w 连接起步、稍微配置好点的硬件来个 5w 起步的连接数(连接数少则协程数量少、异步框架相比 go runtime 没什么优势)
你实测到一些数据,还可以再看下系统编程类的书籍,并且最好也深入理解下 go 的并发模型,20 多年前互联网早期 server 的进程池线程池模型、异步 IO 、以及异步模型比如 C/C++、同步模型比如 erlang 、golang 这些的发展史
万变不离其宗的是系统层的资源的有限,不管语言层面提供何种模型,系统资源始终是那些,语言层的同步模型需要消耗的内存和调度的 CPU 成本,对应得到的同步模型的便利,这二者在中小业务量级的场景可以兼得,但是面对大业务量级会存在一些平衡点,协程数量多时,打破了平衡,就会显得浪费、吃力
与 CAP 类似,现实中也有很多其他事情类似,影响一件事情的多个因素,此消彼长,打破了平衡,就损失了整体的收益

看一下星爷的《功夫》,看一下那个理发师小哥,然后再想想高手该怎么定义,多读书

ps:我也不是什么少年,十几年经验、奔 40 的人了,日常做系统架构、底层框架基础设施,如果标准库性能足够且好用,我就不自己手撸这些了
2021-02-24 21:26:36 +08:00
回复了 abersheeran 创建的主题 程序员 无需申明格式的跨语言高性能序列化格式有哪些?
msgpack 挺好的,数据量比 json 省一点,比 pb 多,但是方便,基本够用了
2021-02-24 21:25:37 +08:00
回复了 abersheeran 创建的主题 程序员 无需申明格式的跨语言高性能序列化格式有哪些?
你们用啥语言,如果是 golang,欢迎尝试我这个

https://github.com/lesismal/arpc
2021-02-24 20:16:11 +08:00
回复了 lesismal 创建的主题 分享创造 发布个 golang 高性能异步网络框架 nbio,单击百万不是梦!
@sujin190 兄弟,首先,等你遇到更大的业务量级,或者自己做些压测对比下不同方式下的各项资源占用,并且,不要按照做中小项目来思考,放飞一下自己,把眼光放到一个更上面的层次,去思考下更宏大的代码运行的世界,比如我上面 4 楼说的算是一个例子
2021-02-24 20:11:56 +08:00
回复了 lesismal 创建的主题 分享创造 发布个 golang 高性能异步网络框架 nbio,单击百万不是梦!
@dorothyREN 十分想改,奈何 V 站似乎没有此功能,我找了好几次了 :joy: 。。。
2021-02-24 19:22:29 +08:00
回复了 lesismal 创建的主题 分享创造 发布个 golang 高性能异步网络框架 nbio,单击百万不是梦!
@sujin190
兄弟,你这么说是对系统架构的理解有偏差了

基础设施异步不代表业务层也必须异步,比如:
网络层异步,收到数据、decode 后,把 message 丢给业务模块的协程池,业务模块的逻辑还是同步的,需要考虑的是协程池的 size 、避免因为协程池数量平静导致业务阻塞,协程池这个问题在其他基础设施也一样,比如 sql 、redis 的连接池,不够用了该排队等就排队等

golang 给我们了协程,我们不一定只能用协程的同步逻辑
同样道理,其他异步设施,也不是强制你上层必须异步
而是,多种姿势摆在这了,业务层同步还是异步逻辑,你可以自己设计
2021-02-24 17:38:29 +08:00
回复了 lesismal 创建的主题 分享创造 发布个 golang 高性能异步网络框架 nbio,单击百万不是梦!
@byte10 兄弟,java 如果足够好,go 就不会诞生了。。。
go 的协程也不是万能灵药,对于中小项目确实没必要,对于大项目,nio 还是非常有必要的
想象一下,如果你手上大厂某些业务几百甚至几万台硬件,如果 nio,可以节省很多成本,单内存占用就可以省太多太多了
云服务越来越广,高并发相关设施用 go 协程这个成本还是很可观的
2021-02-24 17:35:02 +08:00
回复了 lesismal 创建的主题 分享创造 发布个 golang 高性能异步网络框架 nbio,单击百万不是梦!
@byte10 兄弟,我已经不是少年了。。。本来没想自己撸一套,但是其他那几个,实在不好用
2021-02-24 15:30:52 +08:00
回复了 howellz 创建的主题 Go 编程语言 golang 就没有提供一个可以被 cancel 的 read 接口?
试试我的异步网络库:

https://github.com/lesismal/nbio
2021-02-02 16:31:59 +08:00
回复了 yyyfor 创建的主题 程序员 关于系统瓶颈的面试问题
真热闹,我也补充一些吧

前面的各位都只是说到丢给 redis,但是单就 redis 也有击穿、穿透、雪崩各种说法,1s 几十万全丢给 redis,也只能说各位逮到个好玩意就往死里操,还是太暴力太浪费了

缓存和持久层其实都还是局部性原理的范畴,既然局部性原理,就再进一步,内存缓存,内存缓存这块跟 redis 放一块的话也有多种实现方式,比如:
1. 热点 key 的数据,定时或者发布订阅或者其他什么更新机制,服务节点 load 到自己的内存,请求来了直接返回自己内存缓存的
2. 同 key 访问加锁串行化,上一个请求回来后把结果带回来,其他等待锁的先检查是否有结果了,有了就直接拿结果、不落到 redis 了,相当于合并了到 redis 的请求。这个过程当然也可以结合或者改成内存缓存,比如内存的 1s 过期,内存没有、再 redis 、持久层之类的

高配点的机器,如果不是大 key 、value,几十万 qps 没啥压力,我自己的 i7 PC 测自己的 arpc 都能 40 多万 qps
@guonaihong 好,我 new 个 issue
@guonaihong 你试下我 12 楼和 16 楼的代码,两个 Post,我这里测,只打印了一组 begin/complete,不知道是不是我测试代码写错了,如果写错了楼主给指正下我再试试,如果没写错应该算是丢了个请求
上一楼打错字,"第二次发剩下的 1.5" 应该是 "第二次发剩下的 0.5"
@guonaihong 楼主先淡定点,不是开火的意思

我说没返回是指标准库返回了完整的 Request 结构体,Request 内已经把 URL/Header 各字段之类的解析好了,楼主的 httpparser 虽然 setting 里可以设置回调,但也是业务层自己需要二次加工,如果是对比性能,标准库相当于比你默认的 bench 代码多做了每个字段的解析,这样 bench 对比对标准库是不公平的

另外 1.5 个包的问题,比如我在 12 楼的测试代码,两个 http post 的数据,第一次发 1.5 个,第二次发剩下的 1.5,比如 setting 的回调这样:
var setting = httparser.Setting{
MessageBegin: func() {
fmt.Println("---- begin")
},
HeadersComplete: func() {
fmt.Println("---- complete")
},
}

只打印了一组
---- begin
---- complete

我没有去做更完整的测试和调试、不敢确定,提出来你看下算不算 bug,如果我看错了你解释就好了

技术交流,心态平和,需要豁达,不要火大 ^_^
只是解析出一个个包、不解析包内各段落具体字段相对简单,但是对实际工程帮助也不大,所以离工程使用还有很长距离
我尝试了上一楼的 1.5 个包,没法返回单个包给业务层。算是 bug
@guonaihong “设计的时候支持分段传入,内部是一个状态机。”—— 试一下一次读 1.5 个包的内容

var data = []byte(
"POST /joyent/http-parser HTTP/1.1\r\n" +
"Host: github.com\r\n" +
"DNT: 1\r\n" +
"Accept-Encoding: gzip, deflate, sdch\r\n" +
"Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4\r\n" +
"User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) " +
"AppleWebKit/537.36 (KHTML, like Gecko) " +
"Chrome/39.0.2171.65 Safari/537.36\r\n" +
"Accept: text/html,application/xhtml+xml,application/xml;q=0.9," +
"image/webp,*/*;q=0.8\r\n" +
"Referer: https://github.com/joyent/http-parser\r\n" +
"Connection: keep-alive\r\n" +
"Transfer-Encoding: chunked\r\n" +
"Cache-Control: max-age=0\r\n\r\nb\r\nhello world\r\n0\r\n" +

"POST /joyent/http-parser HTTP/1.1\r\n" +
"Host: github.com\r\n" +
"DNT: 1\r\n" +
"Accept-Encoding: gzip, deflate, sdch\r\n" +
"Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4\r\n" +
"User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) " +
"AppleWebKit/537.36 (KHTML, like Gecko) " +
"Chrome/39.0.2171.65 Safari/537.36\r\n" +
"Accept: text/html,application/xhtml+xml,application/xml;q=0.9," +
"image/webp,*/*;q=0.8\r\n" +
"Referer: https://github.com/joyent/http-parser\r\n" +
"Connection: keep-alive\r\n" +
"Transfer-Encoding: chunked\r\n" +
"Cache-Control: max-age=0\r\n\r\nb\r\nhello world\r\n0\r\n")

p := httparser.New( httparser.REQUEST)
fmt.Printf("req_len=%d\n", len(data)/2)
data1, data2 := data[:600], data[600:]
sucess, err := p.Execute(&setting, data1)
if err != nil {
panic(err.Error())
}
if sucess != len(data1) {
panic(fmt.Sprintf("sucess 111 length size:%d", sucess))
}

sucess, err = p.Execute(&setting, data2)
if err != nil {
panic(err.Error())
}
if sucess != len(data2) {
panic(fmt.Sprintf("sucess 222 length size:%d", sucess))
}

p.Reset()
@guonaihong "标准库的 http.ReadRequest,每秒只能处理 124MB 。相比之下 httparser 可以 300MB,性能还是可以的。" —— 这么说不太公平,标准库的是返回了 Request 、url header body 各段落字段都做了解析的
1 ... 51  52  53  54  55  56  57  58  59  60 ... 63  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2970 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 23ms · UTC 14:17 · PVG 22:17 · LAX 06:17 · JFK 09:17
Developed with CodeLauncher
♥ Do have faith in what you're doing.