关于使用 SendBuffMsg以后，QPS下降明显，且有『僵死』连接的一些问题
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- go
- Domain
- networking
Research direction
Start in server.go at ListenTcpConn/StartConn and trace goroutine creation for connection.Start(). Then inspect connection.go (especially Start and SendBuffMsg/SendToQueue paths) to verify when reader/writer goroutines are started and where they block. Reproduce with the linked znix_demo load test for SendMsg vs SendBuffMsg and monitor goroutine counts/QPS. Done is a stable run without stalled connections and expected goroutine behavior after each request/close cycle.
Written by the indexing model from the issue text.
Description
问题一：
表现：现在服务器在有连接进来时，每个连接至少有两个协程。一个是connection.StartReader() 用来读数据，另一个是从 server.go ListenTcpConn函数里，开了一个协程来调用 StartConn(), StartConn 又调用了connection.go 的 Start(), 在 connection 的 Start里。会打开连接的读协程。这时这个协程并不会退出，而是一直等连接关闭，然后去做清理的工作。
connction 默认并不会开启Write协程，只有在每一次调用 SendBuffMsg/SendToQueue 时。才会开始写协程
现在的问题时。我在做压测时。10000连接，每个连接1000个请求与回复，如果服务器用 SendMsg，那一切正常。但如果我用 SendBuffMsg时。会发现QPS下降明显，而且经常会出现有几个连接不关闭，僵死。而且从服务器的协程数来看，用SendMsg 时，一个连接有两个协程，也是我前面提到的那两个。如果用SendBuffMsg时。一个连接就有3个协程。在我上面的说明里看，这也是正常。
想做的修改：
- 因为server.go StartConn 的协程在开启connection 读协程以后，就一直等在那里等收尾工作，有点浪费。现在想去掉这个，开始读协程以后就直接退出。然后收尾工作由 connction 自己处理。想用 RunOnce的方式，直接在 Read协程里处理或用延时协程处理。
- connection的写协程，现在有问题，不知道是不是和写超时有关，僵死的连接不知道是什么原因
- Dominant language
- Go
- Stars
- 7.8k
- Forks
- 1.3k
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from aceld/zinx
-
Difficulty 1/5 Under an hour Newbie friendliness 74/100
-
链接关闭的时候有概率发生 panic Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
-
还是 时间 hip99..9'-%/@好 Open
Difficulty 5/5 Over a week Newbie friendliness 10/100
-
阻塞 Open
Difficulty 3/5 1-2 days Newbie friendliness 46/100
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
enhancement needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100