作者回复: 这些都很全面了:)
作者回复: 因为对操作系统来说,处理报文的开销主要就是对头部的拆解和封装,而对载荷做的结构化处理就很少,对载荷的操作主要是内存复制。比如一个64字节的报文和一个640字节的报文,对CPU的开销差别不大,但是带宽上的差异就大了,所以大报文测试可能先触及带宽瓶颈;小报文测试,可能先触及CPU瓶颈。
作者回复: 你好,这个数值是我们已知的瓶颈值,你们也可以用这种方式发起压测,然后用sar -n DEV查看包量。如果无论怎么压测,这个包量值就维持在某个数值(甚至有时候还会降低一些),那说明这个就是这台主机的瓶颈值了~
作者回复: 你的补充很好:) 不过,tw_recycle这个配置从4.12内核开始被移除了。关于这个变更,这里有详细的说明:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4396e46187ca5070219b81773c4e65088dac50cc
作者回复: 您好,你提到高峰期TCP连接数不超过1600,应该是指ESTABLISHED状态的连接数吗?还是指活跃的并发连接数(比如一些网络IO库提供的连接池设置)?你可以看看出问题时候是不是有大量的连接建立和销毁,这部分隐形的开销也可能引起问题。另外可以查看SYN queue是否有溢出的情况。单纯从文字来看比较难给出准确的意见,有必要的话也可以到学习群详细讨论~
作者回复: 你好,测试到极限后,无论客户端再增加多少请求量,服务端的包量数值就再也上不去了,这个时候就是包量的极限值了。也就是测出来的~
作者回复: 1.是的 2.确实,Linux的这个值要修改只能重新编译内核了,阿里云的机器提供了方便的sysctl接口来修改这个值~
作者回复: 对,现代浏览器都有重试机制,可以对不少网络状况进行容错~ 关于你提到的服务端返回的Keep-Alive头部,我们可以看下MDN的解释: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive timeout: An integer that is the time in seconds that the host will allow an idle connection to remain open before it is closed. A connection is idle if no data is sent or received by a host. A host may keep an idle connection open for longer than timeout seconds, but the host should attempt to retain a connection for at least timeout seconds. max: An integer that is the maximum number of requests that can be sent on this connection before closing it. Unless 0, this value is ignored for non-pipelined connections as another request will be sent in the next response. An HTTP pipeline can use it to limit the pipelining. 也就是说,timeout值是连接保持的最短时间,但可以超过这个时间。 max是指开启了http pipeline以后才有意义,但大部分http场景是不启用Pipeline的,所以这个值一般就是被忽略了:)
作者回复: 是的,修改TW时间需要重新编译内核。国内有云厂商提供了定制版的linux,可以用sysctl来动态修改这个参数,就方便很多了~