感觉提供一个 vscode 插件会好些。

6 ，现在还用的 22.04

分享一个简单的方法。有问题直接问大模型，无论是部署还是写代码。

@asuraa 其实还好，如果用 copilot 的话，写个中文注释就自动补齐出 sql, 然后就用 sqlc 生成操作函数。

我周五放假写个推送服务，试下 ent 好不好使。

简单 crud 使用 sqlc 也挺爽的，直接写个 sql 生成函数。直接调用。

有点意思，先标记下，后面再研究。

你测试代码呢？可以把 fasthttp 也加进来一起测试下。

这边接口有问题，一看原来是腾讯云报的错。

每天。

可行，感谢。

同样，发不了消息。10 点到现在没有恢复。

我是直接开个 github issue 当博客用的。正好可以记录下碎片化的想法。

@rekulas 有一个简单的方法验证， 如果对端传过来的 gzip 包，都缓存到 bytes.Buffer ，完毕可以解出来。那就说明你的 io.Pipe 的用法不对。

因为 list.Accpet 只有新的连接过来，才会停止阻塞，所以这种写法的 go 程的个数等于连接 net.Conn 的个数。

另外聊个题外话，创建大量的 go 程，新版本 go 的 runtime 里面已经做了复用和优化。性能开销没有想象中那么大。
做过一个实验，使用 https://github.com/antlabs/quickws 这个 websocket 库，创建 100w 个 go 程，内存占用大约是 7.67GB 左右，8w tps 并发，50%的时延是 511.62ms

--------------------------------------------------------------
BenchType : BenchEcho
Framework : quickws
TPS : 86326
EER : 413.65
Min : -1ns
Avg : 573.50ms
Max : 1.44s
TP50 : 511.62ms
TP75 : 705.19ms
TP90 : 715.05ms
TP95 : 718.11ms
TP99 : 721.15ms
Used : 49.70s
Total : 5000000
Success : 4290729
Failed : 709271
Conns : 1000000
Concurrency: 50000
Payload : 1024
CPU Min : 120.52%
CPU Avg : 208.70%
CPU Max : 231.77%
MEM Min : 7.67G
MEM Avg : 7.67G
MEM Max : 7.67G

忽略我上一个回答，直接用 io.Pipe 。然后 zlib 解决套下 io.Pipe 的 reader 对象。另外收 gzip 数据的地方并发写就行。
https://pkg.go.dev/io#Pipe

把 chan 包装成一个 io.Reader, 收数据的地方直接并发 chan ， 读的地方 select chan 就行。

type myReader struct {
c chan []byte
}

func (m *myReader) Read(p []byte) (n int, err error) {

copy()
}

楼主文章写得不错。