• JianXu
    2022-03-12
    当年蒋公领导Cms 项目,压测必须见到cpu , mem 或者IO 之一见顶,不然不算过。客户端压测必须有多机并发避免受限单机性能。需要做大小包测试,对应到cms 就是小的文档和大的文档压测。目标机也需要多机集群,因为牵涉到服务端同步。

    作者回复: 这些都很全面了:)

    
    5
  • 那时刻
    2022-03-11
    请问老师,文中提到:对于网络处理来说,主要的开销在包的头部的处理上,而载荷本身的处理是很快的。指的是内核需要处理头部信息所消耗的开销么?而载荷是由应用程序处理,不计入网络处理?

    作者回复: 因为对操作系统来说,处理报文的开销主要就是对头部的拆解和封装,而对载荷做的结构化处理就很少,对载荷的操作主要是内存复制。比如一个64字节的报文和一个640字节的报文,对CPU的开销差别不大,但是带宽上的差异就大了,所以大报文测试可能先触及带宽瓶颈;小报文测试,可能先触及CPU瓶颈。

    共 3 条评论
    5
  • holiday
    2022-04-02
    案例一的5万pck/s达到这台云主机的上限,这个老师能否详细解释一下?

    作者回复: 你好,这个数值是我们已知的瓶颈值,你们也可以用这种方式发起压测,然后用sar -n DEV查看包量。如果无论怎么压测,这个包量值就维持在某个数值(甚至有时候还会降低一些),那说明这个就是这台主机的瓶颈值了~

    共 5 条评论
    2
  • Realm
    2022-03-11
    1 iperf 和 netperf 都是最常用的网络性能测试工具; 2 也可以通过修改内核参数,优化tw的问题 #启用 timewait 快速回收。 net.ipv4.tcp_tw_recycle = 1 #开启重用。允许将 TIME-WAIT sockets 重新用于新的 TCP 连接。 net.ipv4.tcp_tw_reuse = 1

    作者回复: 你的补充很好:) 不过,tw_recycle这个配置从4.12内核开始被移除了。关于这个变更,这里有详细的说明:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4396e46187ca5070219b81773c4e65088dac50cc

    共 2 条评论
    1
  • 陈海松
    2022-05-14
    请问老师,最近我们这边遇到一个问题,2个系统建立tCP连接总是在1500个左右,超不过1600.遇到业务高峰期,就会出现连运维中心维护终端SSH都连接不上或者需要多次尝试才能登录系统。系统允许打开文件数、文件句柄数调整了,没有效果。系统负荷、内存占用率都不高,网络带宽也足够,麻烦老师协助帮忙分析分项,盼复,谢谢!

    作者回复: 您好,你提到高峰期TCP连接数不超过1600,应该是指ESTABLISHED状态的连接数吗?还是指活跃的并发连接数(比如一些网络IO库提供的连接池设置)?你可以看看出问题时候是不是有大量的连接建立和销毁,这部分隐形的开销也可能引起问题。另外可以查看SYN queue是否有溢出的情况。单纯从文字来看比较难给出准确的意见,有必要的话也可以到学习群详细讨论~

    
    
  • 汤玉民
    2022-03-30
    包量的上限是算的还是测试得到的

    作者回复: 你好,测试到极限后,无论客户端再增加多少请求量,服务端的包量数值就再也上不去了,这个时候就是包量的极限值了。也就是测出来的~

    
    
  • 那时刻
    2022-03-11
    1.测试带宽,可以使用iPerf工具 2.Linux的TIME_WAIT貌似是hard code为60秒。而阿里云的机器可以通过 sysctl -w "net.ipv4.tcp_tw_timeout=[$TIME_VALUE] 来修改TIME_WAIT。 window下可以通过修改注册表 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters] "TcpTimedWaitDelay"=dword:0000001E

    作者回复: 1.是的 2.确实,Linux的这个值要修改只能重新编译内核了,阿里云的机器提供了方便的sysctl接口来修改这个值~

    
    
  • Chao
    2022-03-11
    Idle timeout 导致连接被rest。 遇到一个相同案例, 浏览器做法是遇到这种情况 进行了重试。 虽然有http headers 里可以申明 keepalive 超时时间 。 但好像没有客户端实现其读取并主动断开。

    作者回复: 对,现代浏览器都有重试机制,可以对不少网络状况进行容错~ 关于你提到的服务端返回的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的,所以这个值一般就是被忽略了:)

    共 2 条评论
    
  • Liam
    2022-03-11
    带宽测试:iperf, pktgen 修改timewait的时间: 修改TCP_TIME_WAIT, 重新编译内核。默认2MSL是60s

    作者回复: 是的,修改TW时间需要重新编译内核。国内有云厂商提供了定制版的linux,可以用sysctl来动态修改这个参数,就方便很多了~

    共 3 条评论
    