[性能测试实战30讲」之问题问答整理十九

问题

讲完了今天的内容，你能说一下为什么通过抓包可以判断出响应时间的拆分吗？以及，数据分布不均衡还会带来哪些性能问题？

先简单介绍下：

谷歌浏览器请求数据看法：

选择一个网页，单击右键选择检查：

不同颜色的横向柱条表示不同的含义:

（1）.Stalled（阻塞）

浏览器得到要发出这个请求的指令，到请求可以发出的等待时间，一般是代理协商、以及等待可复用的TCP连接释放的时间，不包括DNS查询、建立TCP连接等时间等。

（2）DNS Lookup（域名解析）

请求某域名下的资源，浏览器需要先通过DNS解析器得到该域名服务器的IP地址。在DNS查找完成之前，浏览器不能从主机名那里下载到任何东西

（3）Initial connection（初始化连接）

TCP建立连接的三次握手时间

（4）Request sent（发送请求）

请求第一个字节发出前到最后一个字节发出后的时间，也就是上传时间。 发送HTTP请求的时间（从第一个bit到最后一个bit）

（3）Waiting（等待响应）

请求发出后，到收到响应的第一个字节所花费的时间(Time To First Byte)。 　　通常是耗费时间最长的。从发送请求到收到响应之间的空隙，会受到线路、服务器距离等因素的影响。

（4）Content Download（下载）

收到响应的第一个字节，到接受完最后一个字节的时间，就是下载时间。下载HTTP响应的时间（包含头部和响应体）

读者：

抓包就只会用fillder，拿到接口基本数据，但是老师我还是不明白为什么抓包可以判断出响应时间？

作者回复: 看前面的时间戳。

读者：

数据分布和生产不一致，压出来性能结果很难预估生产真实性能的情形

作者回复: 理解的很正确。

老师经典总结：

不管是什么样的性能问题，其实从分析思路上仍然逃不开我一直提到的思路——那就是一个分析的完整链路。当你一层一层往下找问题时，只要抓住了重点，思路不断，找到根本原因就可以解决问题。

在这个 I/O 的问题中，难点在于怎么能知道 jbd2 的原理和参数。应该说，不管是谁，都不能保证自己的知识体系是完整的，那怎么办呢？查资料，各种学习，看源码，看逻辑。实在看不懂，那也没办法，接着修炼基础内功呗。

所以说性能测试行业中，经常只测不分析，也是因为做性能分析需要的背景知识量有点大，还要不断分析各种新的知识点。不过也就是因为如此，性能测试和性能分析才真的有价值。只测不调只是做了一半工作，价值完全体现不出来。

思考题

最后问你两个问题吧：为什么 TPS 上不去时，资源用不上才是更让人着急的问题？以及为什么要在 CPU 高时查看 CPU 热点函数呢？

读者：

高老师，您好，以下是我的思考： 第一个问题：为什么 TPS 上不去时，资源用不上才是更让人着急的问题？ 该问题我从正面角度思考假设TPS上去了，资源使用也上去了，此时资源情况与TPS正相关，符合常理。但若TPS上不去时，肯定是有多方面原因导致，通常资源的使用是一个定位问题的好方向。根据文章中所述，要进行一次完整的链路分析，要有充足的知识储备量。若此时资源也用不上，那么肯定会导致排查难度极度增大，不宜分析与定位问题。 第二个问题：为什么要在 CPU 高时查看 CPU 热点函数呢？ 在CPU高时，查看CPU热点函数，能使我们深究原因时的整体方向不会偏离。在宏观方向不出错的前提下，找到根本原因及提出相应的解决方案才能真正的解决CPU高的问题。

作者回复: 非常正确。

读者：

问题一：为什么 TPS 上不去时，资源用不上才是更让人着急的问题？ 资源以及TPS上不去，说明压力的流量没有完整的打到服务器上，资源没有能够有效的利用，可能存在很多种原因导致的这个问题，也不知道我们系统到底能支持什么量级。举个例子就像我们有一个电视，但是一年下来只看了几个小时，那么这个电视是没有什么用的，白花了钱。 问题二：为什么要在 CPU 高时查看 CPU 热点函数呢？ 因为通过CPU热点函数可以看到系统哪个模块的CPU利用率高，也就是全局-定向的分析思路，逐步分析，找到问题并且解决问题

作者回复: 得到真传。可以出师了。??

总结

在性能分析的道路上，我们会遇到各种杂七杂八的问题。很多时候，我们都期待着性能测试中的分析像破案一样，并且最好可以破一个惊天地泣鬼神的大案，以扬名四海。

然而分析到了根本原因之后，你会发现优化的部分是如此简单。

其实对于 PostgreSQL 数据库来说，像 buffer、log、replication 等内容，都是非常重要的分析点，在做项目之前，我建议先把这样的参数给收拾一遍，不要让参数配置成为性能问题，否则得不偿失。

思考题

最后问你两个问题吧。为什么加大 buffer 可以减少磁盘 I/O 的压力？为什么说 TPS 趋势要在预期之内？

读者：

分享下自己学习体会： 为什么缓存可以加速I/O的访问速度？ 老师说的缓存应该有两个：操作系统的缓存和PostgreSQL的缓存。它俩作用都是为了把经常访问的数据（也就是热点数据），提前读入到内存中。这样，下次访问时就可以直接从内存读取数据，而不需要经过硬盘，从而加速I/O 的访问速度。 因为没接触过PostgreSQL,在做思考题时找了些资料，下面是延伸的学习。 PostgreSQL缓存跟操作系统的缓存有啥联系？ 1.在访问数据时，数据会先加载到操作系统缓存，然后再加载到shared_buffers，这个加载过程可能是一些查询，也可以使用pg_prewarm预热缓存。 2.当然也可能同时存在操作系统和shared_buffers两份一样的缓存（双缓存）。 3.查找到的时候会先在shared_buffers查找是否有缓存，如果没有再到操作系统缓存查找，最后再从磁盘获取。 4.操作系统缓存使用简单的LRU（移除最近最久未使用的缓存），而PostgreSQL采用的优化的时钟扫描，即缓存使用频率高的会被保存，低的被移除。 PostgreSQL缓存读顺序share_buffers -> 操作系统缓存 -> 硬盘。那么也可能是操作系统缓存不足，而不定是share_buffers。通过文章中vmstat命令看到cache有260G，free值也很稳定，所以应该检查PostgreSQL的缓存。（老师执行vmstat是不是埋了个伏笔）。

作者回复: 认真的同学，必须赞！

读者：

CPU的处理速度与磁盘的处理速度不同，Buffer能起到协调和缓冲的作用，增加Buffer增加了缓冲的空间，故磁盘I/O的压力就会减少。

作者回复: 理解合理。

读者：

高老师，您好，以下是我对两个问题的思考： 第二个问题，为什么说 TPS 趋势要在预期之内？ 此问题类比测试人员设计测试用例，每条用例你要知道它对应的预期结果是什么。若执行后，预期结果与实际结果一致，那么就通过；反之，异常则需要提Bug，分析定位问题的原因，然后解决。

作者回复: 更为关键的是对tps的理解和对系统的把握能力。

读者：

老师，在分析过程中，对数据量的计算是否不准确？ 磁盘的块大小为4096B，那么30万个磁盘块的数据量应该是： 300,000 * 4096B / 1024 / 1024 = 1172M

作者回复: 这个不是30万个block。而是kB，你看上面的标头。

读者：

刚开始分析时使用vmstat，发现bi高。 如果这时看top命令的话，iowait应该也高吧？

作者回复: 是的，iowait在top中也可以看到，只是在这个例子中没有用top这个命令分析而已。

读者：

老师，1jmeter tps是150 2jmeter tps是200能说明什么？在场景对比中增加jmeter数量我怎么觉得是压力不够呢，怎么能说明server哪个节点有瓶颈

作者回复: 你觉得压力不够就再加压力看tps能不能增加。