http post在数据量大于8KB的时候会有问题
zhangzhui opened this issue · comments
附上一个测试文件,总共24KB
第一个8KB 0x31 0x30 ...
第二个8KB 0x32 0x30 ...
第三个8KB 0x33 0x30 ...
保存的话,保存三份0x33 0x30 ...
1.txt
Packet就是对buffer的包装,以减少字节数组的内存拷贝,这个设计类似于.NET新出来的Span。
每次收到数据时,的确是利用Packet包装一下SAEA的buffer,并且上层协议解析,也是Packet的再次包装,完美避免多次内存拷贝。
但是问题也很明显,就是这个数据包不能送给别的线程使用,也不能“缓存”下来留给下一次使用。
8k大小的问题的确欠考虑,正在分析处理!
今天看到了邮件,网络原因不方便上来回复
Packet就是对buffer的包装,以减少字节数组的内存拷贝,这个设计类似于.NET新出来的Span。
每次收到数据时,的确是利用Packet包装一下SAEA的buffer,并且上层协议解析,也是Packet的再次包装,完美避免多次内存拷贝。
但是问题也很明显,就是这个数据包不能送给别的线程使用,也不能“缓存”下来留给下一次使用。8k大小的问题的确欠考虑,正在分析处理!
今天看到了邮件,网络原因不方便上来回复
我对您追求完美以及追求极致效率很是佩服
但是这里冒昧的说一句:适当的增加内存拷贝会让程序变的更容易理解,比如下面:
SAEA里的设置buffer应该是从内核里返回的数据,每次receive的时候都会用到这个buffer,而交给上层应用层去处理的时候是不是clone一份更容易理解一点?这样二者不容易混淆。
另外这个bug应该也是同样的问题,超过了8KB(默认大小),导致后面收到的数据覆盖掉了第一个8KB的Packet,导致解析数据包失败,没有通知给上层,您看呢?
从2005年开始,这是我们第三代网络库,务必追求零拷贝ZeroCopy。尽管给上层带来了一点问题,但只要遵守独占缓冲区原则,离开本线程时拷贝,就不会有太大问题。
第三代网络库的吞吐压测峰值是2266万qps,这里的ZeroCopy就是最后一针推进剂。
嗯。了解了。
那是不是可以httpsession传递给IHttpHandler不必等所有的数据都ready,而是通过流的方式给IHttpHandler,所有业务层的数据由业务来处理。这样数据量小的业务8KB足够了,数据量大的话则自己处理。
嗯。了解了。
那是不是可以httpsession传递给IHttpHandler不必等所有的数据都ready,而是通过流的方式给IHttpHandler,所有业务层的数据由业务来处理。这样数据量小的业务8KB足够了,数据量大的话则自己处理。
的确是这样,只是目前我还没有好的思路去调整这个数据流的用法,这么做最好的用途就是文件上传