lesismal's repos on GitHub
Go · 2406 人关注
nbio
Pure Go 1000k+ connections solution, support tls/http1.x/websocket and basically compatible with net/http, with high-performance and low memory cost, non-blocking, event-driven, easy-to-use.
Go · 1010 人关注
arpc
More effective network communication, two-way calling, notify and broadcast supported.
Go · 135 人关注
go-websocket-benchmark
Go · 12 人关注
llib
Go · 6 人关注
go-net-benchmark
Go · 5 人关注
cbuffer
Go · 3 人关注
go-http-server-benchmark
1 人关注
conc
Better structured concurrency for go
1 人关注
Developer-Books
编程开发相关书籍整理分享,持续更新...
1 人关注
gg
一个支持节点与订阅链接的 Linux 命令行代理工具 | A command-line tool for one-click proxy in your research and development without installing v2ray or anything else (only for linux)
Go · 0 人关注
awesome-go
A curated list of awesome Go frameworks, libraries and software
0 人关注
cli
GitHub’s official command line tool
0 人关注
Diamond-Sutra
Github最早公开上传的《金刚经》/Diamond Sutra/LE SUTRA DU DIAMANT
0 人关注
emoji-cheat-sheet
A markdown version emoji cheat sheet
0 人关注
engineering-blogs
A curated list of engineering blogs
0 人关注
epoll
Go · 0 人关注
gevent-benchmark
Go · 0 人关注
gin
Gin is a HTTP web framework written in Go (Golang). It features a Martini-like API with much better performance -- up to 40 times faster. If you need smashing performance, get yourself some Gin.
Go · 0 人关注
go
The Go programming language
Go · 0 人关注
gopkg
Universal Utilities for Go
0 人关注
guide
The Uber Go Style Guide.
Go · 0 人关注
gws
High-Performance Go WebSocket Server & Client
0 人关注
http-parser
http request/response parser for c
Go · 0 人关注
kcp-go
A Crypto-Secure Reliable-UDP Library for golang with FEC
Go · 0 人关注
kitex-benchmark
0 人关注
lesismal
HTML · 0 人关注
lesismal.github.io
Go · 0 人关注
melody
:notes: Minimalist websocket framework for Go
Go · 0 人关注
mempooldebug
lesismal

lesismal

V2EX 第 497905 号会员,加入于 2020-07-06 13:49:58 +08:00
今日活跃度排名 2329
以明文形式存储数亿个密码, Meta 被罚 1 亿美元
互联网  •  lesismal  •  165 天前  •  最后回复来自 GeekGao
3
深圳中院首次裁定宣告一对夫妻债务人破产
生活  •  lesismal  •  161 天前  •  最后回复来自 julyclyde
6
美国宣布全面禁止竞业协议
程序员  •  lesismal  •  304 天前  •  最后回复来自 ChrisFreeMan
2
github 被人 at 说币安空投,是诈骗吗?
程序员  •  lesismal  •  2024-01-01 23:46:09 PM  •  最后回复来自 lesismal
2
取代 Vue 和 React?——期待新的前端框架 Nue
前端开发  •  lesismal  •  2023-12-06 16:25:31 PM  •  最后回复来自 forgottenPerson
7
4C-2G 来战 [ Golang Websocket 百万连接测试 ]
程序员  •  lesismal  •  2023-12-12 12:26:04 PM  •  最后回复来自 lesismal
34
lesismal 最近回复了
4 小时 2 分钟前
回复了 wysnxzm 创建的主题 程序员 请问这是在说哪一个?
> 大部分人是能够做到根据实际情况做出技术栈的选择的。但是问题在于一部分用语言圣战掩盖自身无知和懒惰的人发出了巨大的噪音。
> 这部分人无限拥护自己所支持的语言的目的不是为了使某个项目变得更好,而是为了通过语言斗兽棋强行体现自身优越。

我不知道这是不是你工作中同事在做的事情,我觉得大概分两种:
1. 那些业务量用原语言没有瓶颈的且有大量历史包袱的,没必要换语言去重构的项目,被很多人鼓吹换技术栈重构
2. 但一些明星企业搞了大量的 golang 重构也是属于刚需:性能的刚需和成本的刚需。很多 curd 的人不喜欢,但重构确实带来了很大提升

如果是因为 1 让你不爽,那确实是倒霉,但不应该根据 1 去否定 2 ,也没必要去否定某个或者某些语言的社区,真理掌握在少数人手中的情况很多,一个好的语言火起来、很多无脑拥趸跟风的人会来污染这个事物、但他们不一定是社区主流、也不应该成为社区主流,所以我个人和很多同行也是不喜欢看到很多其他语言涌入到 go 里然后用其他语言的方式去搞 go 。

> 内存安全的 rust 是很好,但是如果没有在延迟上有特定的要求,我可能更倾向于支持 GC 的语言。

强推内存安全不只是强推 rust ,java 、go 也都在推的,可能是因为 rust 自己更加突出地标榜自己的内存安全,所以很多人误以为推动内存安全就是推 rust 。性能和安全都要求特别高并且性能要求极致的 rust 是最佳,否则 rust 的开发效率也是感人、没必要。


> GO 无脑堆逻辑确实快,但是占一多半的 if err != nil return nil,errr 也确实碍眼。

这个怎么说呢,如果不是 go 这么要求,go 代码可能也不会这么健壮。

如果仅以所谓代码行数少带来的简洁性作为审美、并且用审美大于实用的标准要求自己的代码,那应该搞艺术,而不是做工程。你也提到根据实际情况做出技术栈的选择,这是务实的观点,务实不只是选择用什么,怎么用也是务实的一部分,毕竟如果不喜欢,大可以 “_” 忽略 err 和处理、可以不用去写 if err else 。

> 语言的特性是一个事实,没有一个功能或语法就是没有。至于是否属于功能缺失,我觉得判断标准确实要落在是否影响实际工程应用上。

至少我没有遇到过因为缺少其他语言的高级特性导致工程效率低,确实有一些小的麻烦,比如 err 处理的行数多些,以往用标准库 raw sql 循环 scan 麻烦些,甚至以前没有范型、要为不同类型都写几个相同实现,但这些多数归属于简单的逻辑、稍微花点时间就可以搞定了,并没有真正消耗开发效率。
5 小时 3 分钟前
回复了 wysnxzm 创建的主题 程序员 请问这是在说哪一个?
> 我最多只能说:在我遇到的某个特定场景下,使用某些语言/工具是合适的。但是绝对无法断言,这些语言/工具能满足任意场景的需要。

@CapNemo 我好像从没见过 gopher 和 ruster 去鼓吹任何项目都用 go 或者 rust 去做,至少不是这两个语言社区的主流意志。所以,很迷惑,经常无法理解为什么会有这么多人得出这种结论然后给 go 和 rust 扣上这种帽子。


> 在我看来,不管是将 GO 的"功能缺失"强行解释为"哲学优越性",还是以内存安全为由在各种项目上强行推广 rust ,这些行为都属于忽略实际条件去强行套用解决方法,本质上是编程领域的唯心主义。这种工具崇拜不仅引发争论污染公共讨论空间,也无助于提高自身水平。

没人强行推广 rust 去做 curd ,而且一些强行推广的行为已经上升到 us 政府行为,这种强行是基于安全问题日益恶化并且内存安全问题占的比例非常大、c/cpp 又无法解决这个问题。如果只考虑自己 curd 舒服,那当然无法 get 到这种强行对世界的意义,但这世界不只是为了我们 curd 服务的,而是反过来、curd 是为这个世界服务的,不要拎不清。

> 必须认识到,编程的价值在于解决实际问题。脱离工程背景无限拔高某些设计取舍只能暴露自身视野之狭隘。
保持对技术本质的清醒认知,才能在快速迭代的生态系统中构建可持续的工程能力。

这就更逗了,别人用语言是为了做工程,然后被一些用语言缺少语言自己的功能/特性扣帽子。
我就好奇了,你们那么多人都是在做开发编程语言的工作吗?所以某个语言没有某个或者某些语言特性就是“功能缺失”了?人家做工程好好的、人家语言现有特性能够做工程,怎么就功能缺失了?

为什么这么多人基础逻辑都搞不懂还要对别人务实做事的指手画脚。
5 小时 12 分钟前
回复了 bronyakaka 创建的主题 程序员 web 框架性能排名 techempower 发布 2025 最新结果
虽然能反映出很多框架的性能,但 techempower 也是我见过最逗比的没底线的 benchmark 之一了,plaintext 里包括 gnet 、evio 这种不完整 http 功能的简单拼接字符串方式的测试代码也可以放到排名结果里,甚至这种能拿个 plaintext 第一至今还贴在这种 repo 仓库里作为宣传工具误导不知情的同行。而且这样一来,助长了更多的不良之风:
https://github.com/lesismal/nbio/issues/337#issuecomment-1663771688


go 的 cpu 能力和 java 是差不多的,这种简单测试的结果不意外。

帖子里一些人觉得 gin 简单,是一种错觉、简单与复杂对比错了层面:
1. 在这个简单 http 功能测试对比 gin 和 spring 性能的场景,应该是看 http 基础部分实现的性能复杂度。单就 http 相关的实现,gin 等 go 框架在性能消耗上的浪费可能比 spring 还多,所以 fast 系能赢、gin 和其他几个基于标准库的难赢
2. 各位对比的简单是作为 http 框架甚至框架生态圈的大的功能集合的简单与复杂、但是这部分与这个性能测试是没什么关系的

实际工程中高并发场景,影响性能的重要因素之一是并发度,主要是连接数、协程池|线程池。
java 非 netty 通常的业务线程池 size 设置不会特别大,几百几千,如果遇到并发很大并且一些请求阻塞时间较长时,这些阻塞时间长的请求会持续占用线程,线程池 size 小、等待得多了甚至整个线程池的 worker 都阻塞、临时耗尽了,其他连接的请求要排队,cpu 利用率就跑不上去、业务慢了。
go 这种协程成本低,即使时 4c8g 这种硬件,随便也可以跑几万甚至 10w 级别的协程数量,对应的能服务的连接数就更多,所以部分连接的请求即使阻塞了、处理其他大部分连接的协程就被调度起来继续运行了、cpu 不用等待,因为几万甚至 10w 级别的协程数量远大于 response write 这些 syscall 、远大于下游的 db 操作、或者其他 io 等慢阻塞的并发度,所以整体上不会导致 cpu 利用率降低。

我没有仔细研究这个测试,但没有找到实际测试的连接数并发度,也没有看到各个语言框架对应的 cpu 、内存消耗。
不同的参数会有不同的阈值,如果只是一组参数测试得出结论,不能够准确说明实际业务中不同场景不同时段等的真实性能表现。
6 小时 39 分钟前
回复了 wysnxzm 创建的主题 程序员 请问这是在说哪一个?
先搞懂什么叫"功能缺失"吧。

中国人习惯用筷子和吃中餐,欧美人习惯用刀叉吃西餐。
一些人用刀叉吃西餐的人觉得自己才是吃饭正统、不用刀叉西餐就扣帽子成"功能缺失"。
和着不用刀叉不是西餐就不是吃饭了是吗?

基本逻辑都不通的所以高级工具使用者,实际工程能力如何不得而知,给别人扣帽子的狗屁逻辑倒是真的精通和显而易见
@Nugine0 #106 继续

而且,很多人无脑黑 Go 的,比如看到 nbio 搞百万连接优化,想都不想就会出来喷、说官方都可以写同步代码、你非要搞个异步非阻塞库这是倒退,但其实 nbio 对标准库是基本兼容的、使用方法还是用标准库那样的方式仍然是写同步代码;
还有些人一看 nbio 名字里的 nb 就开始“国人的项目净搞噱头”,实际效用他们可不管,张嘴就是嘲讽、阴阳。

这也是为什么我看到很多黑 Go 的或者对 Go 负面影响的评价会经常站出来反驳的原因,因为自己就被他们无脑黑或者嘲讽过很多次了
@Nugine0
我的开源项目已经发过几次帖子了,发多了也会惹人烦,而且论坛的流量也不大了,所以就很少发了。
一些优化的点倒是可以拿来说说,但是这些点我觉得都挺平常的,比如海量连接数、协程池、内存、gc 、网络哭、rpc 性能各种优化和实现策略,以前跟很多人讨论过很多次了,github repo 的 issue 里也有不少相关的都在。
最重要的,比如 nbio 是为了解决标准库海量连接数场景的弱项、1M 连接数 1k payload echo 压测 server 内存可以控在 1G 内存、4-8c 能跑 10w+ qps ,但绝大多数人用不到,绝大多数人的场景连接数都不高、用标准库足够了,少量的人用得到的自然可以找上门来;至于 rpc ,我自己的 arpc 性能和易用性里都算是 top 了,但更多人就是喜欢 grpc 、毕竟跨语言和整体生态更强谷歌背书,而且多数人是 web 领域微服务之类的、普通 rpc 也足够用了,少有人懂更多的才会考虑用 arpc 去做更多业务类型比如游戏、IM 、推送而且顺便性能提升一大截。
我个人也没那么多精力去搞更大,为爱发电成本太高了。所以也懒得去宣传这些了,有缘的人多交流就可以了
@Nugine0 #102

文人相轻,同行相轻,编程语言里的踩踏更是如此,尤其是 Go 这种定位务实不搞花哨的。
这些都是人性,我自己飘了的时候也要乱讲、毕竟不是圣人,无所谓羞愧,对了就坚持错了就承认和改变。
人性的事情确实改变不了,但是互相喷下也没啥,不想让 Go 和 Gopher 吃哑巴亏。
> 没说优秀=否定优秀=需要反驳,我觉得你不需要坚持这个链条去反驳任何人。

@Nugine0 通常没有出来反驳的必要,但是这种“不是因为 Go 多优秀”的实际效果就是“Go 不优秀”,让人挺无奈的
@godspeedyou
#93 国人爱谦虚,很多事情都会谦虚,比如自己拿了什么冠军还是要说“我还有很多可以提高的地方”。但这个案例里,他们都不是谦虚了,就是不愿意承认 Go 的好。
说好听点是他们懂得多,说不好听点就是很多人喜欢踩一脚来变相抬高自己。
@Manweill #91 是的,所以选型了一个性能给力、自带 gc 省力开发效率高、并发极大便利、底层能力、函数方式编程个方面都适合,但只要不是嘴上承认这些点都算优秀,就不是 Go 多优秀,因为别的多种语言也都分别有这些对吧?
即使别人选型 Go 了并且说明了为什么 Go 在多个方面都很适合、适合也不是因为优秀,只是因为适合,即使脱离了这个 case 本身也不用考虑 Go 本身、Go 本身就不是多优秀对吧?佩服你们的推理能力。
最适合的候选人,即使不说他多优秀也就算了,一个个的都站出来说不是因为他多优秀、不带任何至少它满足了个方面需要的前置条件,这不就是在那不屑地假装理中客地暗黑吗?

不要只觉得喜欢 Go 的人是在自 high ,无脑黑 Go 和不屑承认 Go 优点优秀的人难道不是自 high 吗?
无脑否定 Go 的人不只是自 high ,而且还很不喜欢务实的事物,不知道有什么可出来炫耀的
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2978 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 29ms · UTC 11:13 · PVG 19:13 · LAX 04:13 · JFK 07:13
Developed with CodeLauncher
♥ Do have faith in what you're doing.