求助！内存使用问题

[JHue58]

在服务端消费过慢时，会导致服务端内存堆积导致服务炸掉。
目前netpoll有提供什么可行的限流方案嘛，求解答！谢谢

[joway]

@Nana-Miko #298

已经实现了read限流，正在测试这个pr，你也可以直接用这个分支试试？

[JHue58]

@Nana-Miko #298

已经实现了read限流，正在测试这个pr，你也可以直接用这个分支试试？

好的谢谢

[JHue58]

刚刚看了一下read-throttle这个分支，如果通过inputBuffer.Len()进行限流的话，感觉不是很妥当
比如onRequest那边需要进行数据分包，就像官网的例子

var conn netpoll.Connection
	// reading
	reader := conn.Reader()
	for {
		... unpacking & handling ...
		pkg, _ := reader.Slice(pkgsize)
		go func() {
			... handling pkg ...
                        <-time.After(50*time.Microsecond)
			pkg.Release()
		}
	}

由于Slice会进行recalLen，但实际上pkg并没有被消费完毕，就会导致限流无效

[ppzqh]

对于netpoll而言，我理解slice操作属于是消费了buffer，返回了一个新的link buffer供用户来按需读取。

[ppzqh]

关于限流，是否有别的建议来解决这个问题？

[JHue58]

关于限流，是否有别的建议来解决这个问题？

我后来想了一下，像上面的代码那样来一个pkg就开一个协程去处理是错误的，换成channel+一个process协程就行

[joway]

@Nana-Miko yes，无论什么实现方式，都需要你自己也主动控制下消费buffer的速度，进而才能控制对端速度。实现方式只是在「控制方法」这有差异，目前的实现方式是通过buffer本身的读取消费来控制

[JHue58]

@Nana-Miko yes，无论什么实现方式，都需要你自己也主动控制下消费buffer的速度，进而才能控制对端速度。实现方式只是在「控制方法」这有差异，目前的实现方式是通过buffer本身的读取消费来控制

嗯，确实是这样的，受教了！