土耳其小土豆2020-07-01高老师，网络队列的截图的具体命令能告知以下嘛？我想打印跟你那一样的作者回复: netstat -naop就可以。
13- Geek_9e9d562021-11-23高老师，应用和数据库服务器带宽截图的具体命令能否告知一下？谢谢
作者回复: 我最常用的就是iftop。
5 
Geek_237b862020-03-31老师swapping标黄的是什么工具？作者回复: spotlight。
4
糯糯2021-04-30老师 有个问题，如果说要找到系统上限，是找到系统瓶颈呢，还是尽可能的压测至服务器资源沾满呢作者回复: 瓶颈是上限的绊脚石，得先解决，再把资源占满才有意义。
3- bettynie2020-04-13高老师，我们做内网测试时采用直连的方式，是不是可以更好的避免内网的网络问题，只考虑网卡的限制，这样可以把精力放在程序本身，先找出比较严重的性能问题再来考虑网络影响？
作者回复: 如果有必要的话，可以这样做。只是在内网中，网络设备的背板吞吐都是很大的。你的应用有这么大的流量吗？
3 
Geek_Jean2021-09-02高老师，谢谢您给大家分享这么多的干货，真的受益非浅，但看完这讲后，我有3个问题没明白： 1. 我有这样一个认知：服务端Send-Q如果有积压，那实时查看网络带宽的时候服务端的发送量和客户端的接收量不会对等。这个认知对吗？ 如果上面说的是对的，那我又有一个新问题： 服务端网络资源接收 900KB/s 左右，发送 11M 左右；然后通过查看压力机上的网络接收流量可以看到是93Mbps，换算之后也就是11M左右, 这么看服务端的发送量和客户端的接收量是一样的，带宽是对得上的。依据这样的推断服务端的Send-Q应该不会有积压才对。这个怎么理解呢？ 如果上面的认知不对：那我有另外一个新问题： 实时查看服务端的时候Send-Q都有积压了，那说明这些数据还没有到达客户端，那客户端的接收量就不会接近服务端的发送量了。但实际上他们都是93Mbps.这是怎么回事呢？作者回复: 有积压时，发送方和接收方的值确实不会对等，但这个偏差很小，你可以查看一下发送方的发送缓冲区大小和内核限制的写缓冲区最大值、以及接收方的接收缓冲区大小和内核限制的读缓冲区大小。 如果你可以在两边抓到同一时刻（记住是同一时刻）的网络带宽，那就会看到区别。 不过我觉得你不用纠结这一点。因为这个队列要长期有值才说明阻塞严重，偶尔有值或间歇性有值是不用关心的。
2
大拇哥2020-02-211）查看服务器发包数量，客户端接口数据包的量是不基本一致，如果出现明显的差别，可以基本确定客户端网络问题 2）查看jmeter聚会报告上面客户端接口数据量是否已经接近宽带的限制 队列： 服务端消息发送队列 客户端接收数据的队列 服务端超时队列作者回复: 1，当网络有问题的时候，主要看队列，不用再对比流量了，因为已经没有意义了。 2，对。
2- Geek_a8d2eb2021-02-27压测时在应用服务上执行命令netstat -naop，发现Recv-Q和send-Q都有间歇性的非0状态，5秒内就恢复0了。网上搜说可接受短暂的非0情况，短暂的Send-Q队列发送pakets非0是正常状态。请问这种说法靠谱么，观察tps和响应曲线也会出现相应的锯齿状
作者回复: 短暂的非0确实是可能接受的。如果tps和响应时间跟网络队列相关，这就要有证据才可以了。那你需要的是拆分响应时间，看有没有在网络上消耗。
1 
😂2020-12-08老师，如何判断带宽不够呀？1.服务器接受和发送的流量接近或超过带宽，说明带宽不够？2.压力机接受和发送的流量接近或变过带宽，说明带宽不够？作者回复: 看队列。
共 2 条评论1- nelson2020-05-11文稿中提及“综上现象就是，单业务场景执行起来并不慢，但是一混合起来就很慢，应用服务器和数据库服务器的系统资源使用率并不高。请问慢在哪？” 经过一系列分析，没有给出单业务为什么不慢，如果是带宽问题，单业务也一定会慢
作者回复: 这里提的单业务不慢，是因为对于同样的带宽来说，单业务的TPS是没有业务限定的。而混合场景中会有业务目标限定。
1