带宽问题是性能分析中常见的问题之一，其难点就在于，带宽不像 CPU 使用率那么清晰可理解，它和 TCP/IP 协议的很多细节有关，像三次握手，四次挥手，队列长度，网络抖动、丢包、延时等等，都会影响性能，关键是这些判断点还不在同一个界面中，所以需要做分析的人有非常明确的分析思路才可以做得到。而且现在的监控分析工具中，对网络的判断也是非常薄弱的。
思考题：
结合今天的内容，你能说一下网络的瓶颈如何判断吗？有哪几个队列？
读者：
对于性能分析来说，带宽能不能对得上非常重要。比如，客户端接收了多少流量，服务端就应该是发出了多少流量。如果服务端发了很多包，但是客户端没有接收，那就是堵在队列上了。 关于这一段话，我想请问下，为什么没有提到客户端发出请求的流量大于服务端接收的情况？这种情况需要考虑吗？如果要考虑的话，通常会出现哪几种现象，要如何分析
作者回复: 对于网络来说，不分客户端，服务端。只要分发送和接收端就可以。
并且，也不会出现某一端发的大，另一端接的少的这种情况，接收端接不了，发送端肯定就排队去了。
所以，你说的其实是一种现象。
读者：
1）查看服务器发包数量，客户端接口数据包的量是不基本一致，如果出现明显的差别，可以基本确定客户端网络问题 2）查看jmeter聚会报告上面客户端接口数据量是否已经接近宽带的限制 队列： 服务端消息发送队列 客户端接收数据的队列 服务端超时队列
作者回复: 1，当网络有问题的时候，主要看队列，不用再对比流量了，因为已经没有意义了。
2，对。
思考题：
这一篇文章延续上一篇的分析思路，你能讲一下 Swap 的原理和逻辑，以及分析思路吗？另外，慢 SQL 如何定位出来呢？
读者：
在虚拟机或dock环境中可进行性能测试吗？
作者回复: 这个问题过于宽泛了，但是本着认真的态度，还是回复一下吧。
对于性能测试环境，只有一个可信的答案，那就是：和生产一致。
生产用什么配置，测试就用什么配置是最靠谱的。
但是我们经常会遇到的是硬件环境会有区别。所以经常会有人在硬件不同上钻牛角尖，而不去考虑系统特性以及什么资源影响最大。
如果是CPU资源使用最多，我们只要去对比CPU能力也能比较个大概。
而虚拟机和docker能不能用于性能测试？当然可以。不管什么环境，都可以用于性能测试。
而现在我们用于应用级别的机器基本上都是虚拟机和docker。这必然是可以用的。
其核心是，这套硬件能提供的能力到底是什么样。而不用纠结是虚拟机还是docker还是物理机。
读者：
高老师，请教下JVM配置是用哪种测试场景去调优呢。比如系统有好几个应用，测试场景也有基准测试、混合测试，那是测基准测试时去调优JVM配置？还是混合测试时？还是所有的场景都要去做这个JVM调优配置？如果出现多个场景JVM的最佳配置不一样，是以哪个为准？
作者回复: 这个没有区分，什么场景下发现问题就什么时候调。
思考题：
这是个刁钻的案例，你能说一下为什么在本例中，最后想到了看防火墙呢？以及，为什么说 timewait 的 TCP 链接只是问题的现象呢？
读者：
读完老师的文章，有下面几点疑惑 1. TCP 四次挥手中，主动断开链接的一方才会处于 TIME_WAIT 状态呢，老师在文中有说 客户端主动断开，服务端也会出现 TIME_WAIT 状态，这是什么情况呢？ 2. nf_conntrack 模块对 TCP 链接进行追踪，然后 nf_conntrack 的表有限制，表满了就丢包，这个因导致了服务器出现大量的 TIME_WAIT 状态，但为什么反应到 TPS 是锯齿状呢？一会儿好，一会儿坏，就算是 nf_conntrack 表会释放，难道还会瞬时释放很多，这样 TPS 就上去了，然后又满了，TPS 又下降？ 思考题 1.如何在分析一通后，最后定位到防火墙？ 因为老师在经过对操作系统的 CPU、IO、内存等资源还有数据库、Tomcat、Nginx 等监控数据没有发现什么问题，最后定位到网络连接状态有问题，即出现了大量的 timewait 状态的链接，然后老师想通过修改 TCP 相关的参数来达到复用处于 timewait 状态的链接（这些参数的本质是释放服务端的句柄和内存资源，但不能释放端口，而 源IP 源端口 目的IP 目的端口 协议号才是 TCP 五元组），修改完后没有解决问题 然后老师分析客户端主动断开时，服务端也会处于 timewait 状态（这块是我疑惑的，应该是主动断开链接的一方才会处于 timewait 状态），然后打开了 Nginx 的 proxy_ignore_client_abort 配置，即让 Nginx 忽略掉客户端主动断开时报的错，但问题还是没有解决，然后把 Nginx 和 Nginx 所在服务器也换了，问题没有解决。 开始考虑操作系统层面，网络收发数据那儿可以通过查看发送端和接收端的 Recv_Q 和 Send_Q 这四个队列是否有值，来判断瓶颈点，然后没有发现问题。 在最后才考虑防火墙了 2.为什么 timewait 的 TCP 链接只是问题的现象？ 因为能引起链接处于 timewait 状态的原因还是有很多的，这就需要不断透过现象看本质，根据不断地排查锁定最根本的原因
作者回复:
问题1，由于客户端异常断开，未发送fin包。服务端并不知道。当服务端探测到客户不在时，只能自己主动断开，故而有timewait出现。
问题2，nf_conntrack表满了会被清理，而tcp会重连，这时响应时间会增加，所以tps掉下后会再上升。
