做性能测试有没有遇到瓶颈（性能测试遇到的瓶颈）

本篇文章给大家谈谈做性能测试有没有遇到瓶颈，以及性能测试遇到的瓶颈对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享做性能测试有没有遇到瓶颈的知识，其中也会对性能测试遇到的瓶颈进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、性能测试知多少——常见性能问题
• 2、性能测试中如何定位性能瓶颈
• 3、性能测试如何确定数据库是否是瓶颈

性能测试知多少——常见性能问题

在日常生活当中，如果你的应用运行太慢或者经常出现各种使用不方便的问题，那很多情况下用户都是会选择离开，因此性能说的简单一些就是站在用户的角度去测试实际的感受，如果说功能测试是确保软件可用，易用。那么性能测试就是让这些功能变得更流畅，用户使用的更舒服。

不过很多刚刚进入测试家庭的新同学很容易将性能测试这个过程片面的理解成找工具或者写工具进行测试最后给出一个图表结果，仅仅看中了过程而忽略了在测试过程中发现定位并解决问题的能力。针对分析问题这个步骤，我也是在网上拜读了一部分前辈的测试经验，并希望在此将一些常见的思路分享给大家。

说到性能测试，我们首先要明确性能测试的目的，只有明确测试的目的才能更好的发现软件的不足：

1.功能验证：验证某软件在一定条件下具有什么样的功能

2.能力规划：如何使系统达到我们要求的性能能力

3.应用程序诊断：比如内存泄漏，通过功能测试很难发现，但通过性能测试却很容易发现。

4.性能调优：满足用户需求，进一步进行系统分析找出瓶颈，优化瓶颈，提高系统整体性能。

性能测试的整体步骤可以按照下图划分：

其中分析结果是整个步骤中重要的一环，接下来就为大家介绍一些常见的问题：

硬件上的性能瓶颈：

一般指的是CPU、内存、磁盘I/O 方面的问题，分为服务器硬件瓶颈、网络瓶颈、服务器操作系统瓶颈（参数配置）、应用瓶颈。

应用程序上的性能问题：

一般指的是开发人员开发出来的应用程序或者新功能。例如，程序架构规划不合理，程序本身设计有问题，造成系统在用户使用时性能低下。在此处出现的问题往往是应用开发在进行功能实现上使用错误的方法而导致的（完全可以避免），因此这也是需要测试人员快速定位并解决的问题。

操作系统上的性能瓶颈：

例如iOS操作系统。例如，在进行性能测试，出现内存不足时，系统会发出对应用的低内存警告，如果应用没有及时响应系统的警告就会将程序进程终止，造成程序崩溃。这时认为操作系统上出现性能瓶颈。

网络设备上的性能问题：

一般指的是防火墙、动态负载均衡器、交换机等设备。例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络环节存在问题。

由于性能测试出现的原因及其定位都十分复杂，这里只是简单介绍常见的几种问题类型和特征，而性能测试所需要做的就是根据各种情况因素综合考虑，然后协助开发人员一起定位性能瓶颈，下次作者会结合实际测试情况和大家一起寻找定位问题的方法。

性能测试中如何定位性能瓶颈

Processor%Privileged Time该参数值一直很高，且如果在 Physical Disk 计数器中，只有%Disk time 比较大，其他值都比较适中，硬盘可能会是瓶颈。若几个值都比较大， 那么硬盘不是瓶颈。若数值持续超过80%，则可能是内存泄露。如果 Physical Disk 计数器的值很高时该计数器的值（Processor%Privileged Time）也一直很高， 则考虑使用速度更快或效率更高的磁盘子系统。 Disk sec/Transfer 一般来说，该数值小于15ms为最好，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了. --------------------------------------------- Average Transaciton Response Time（事务平均响应时间）随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势 Transactions per Second（每秒通过事务数/TPS）当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈 Hits per Second（每秒点击次数）通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。 Throughput（吞吐率）可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。

性能测试如何确定数据库是否是瓶颈

    具体问题具体分析，举例来说明为什么磁盘IO成瓶颈数据库的性能急速下降做性能测试有没有遇到瓶颈了。

   为什么当磁盘IO成瓶颈之后, 数据库的性能不是达到饱和的平衡状态，而是急剧下降。为什么数据库的性能有非常明显的分界点，原因是什么？

    相信大部分做数据库运维的朋友，都遇到这种情况。 数据库在前一天性能表现的相当稳定，数据库的响应时间也很正常，但就在今天，在业务人员反馈业务流量没有任何上升的情况下，数据库的变得不稳定了，有时候一个最简单的insert操作， 需要几十秒，但99%的insert却又可以在几毫秒完成，这又是为什么了？

dba此时心中有无限的疑惑，到底是什么原因呢? 磁盘IO性能变差了？还是业务运维人员反馈的流量压根就不对？ 还是数据库内部出问题？昨天不是还好好的吗？

 当数据库出现响应时间不稳定的时候，我们在操作系统上会看到磁盘的利用率会比较高，如果观察仔细一点，还可以看到，存在一些读的IO. 数据库服务器如果存在大量的写IO,性能一般都是正常跟稳定的，但只要存在少量的读IO,则性能开始出现抖动，存在大量的读IO时（排除配备非常高速磁盘的机器），对于在线交易的数据库系统来说，大概性能就雪崩了。为什么操作系统上看到的磁盘读IO跟写IO所带来的性能差距这么大呢？

如果亲之前没有注意到上述的现象，亲对上述的结论也是怀疑。但请看下面的分解。

在写这个文章之前，作者阅读了大量跟的IO相关的代码，如异步IO线程的相关的，innodb_buffer池相关的，以及跟读数据块最相关的核心函数buf_page_get_gen函数以及其调用的相关子函数。为了将文章写得通俗点，看起来不那么累，因此不再一行一行的将代码解析写出来。

咱们先来提问题。 buf_page_get_gen函数的作用是从Buffer bool里面读数据页，可能存在以下几种情况。

提问. 数据页不在buffer bool 里面该怎么办？

  回答做性能测试有没有遇到瓶颈：去读文件，将文件中的数据页加载到buffer pool里面。下面是函数buffer_read_page的函数，作用是将物理数据页加载到buffer pool, 图片中显示

buffer_read_page函数栈的顶层是pread64(),调用了操作系统的读函数。

buf_read_page的代码

 如果去读文件，则需要等待物理读IO的完成，如果此时IO没有及时响应，则存在堵塞。这是一个同步读的操作，如果不完成该线程无法继续后续的步骤。因为需要的数据页不再buffer 中，无法直接使用该数据页，必须等待操作系统完成IO .

再接着上面的回答提问：

当第二会话线程执行sql的时候，也需要去访问相同的数据页，它是等待上面的线程将这个数据页读入到缓存中，还是自己再发起一个读磁盘的然后加载到buffer的请求呢？   代码告诉我们，是前者，等待第一个请求该数据页的线程读入buffer pool。

试想一下，如果第一个请求该数据页的线程因为磁盘IO瓶颈，迟迟没有将物理数据页读入buffer pool, 这个时间区间拖得越长，则造成等待该数据块的用户线程就越多。对高并发的系统来说，将造成大量的等待。 等待数据页读入的函数是buf_wait_for_read，下面是该函数相关的栈。

通过解析buf_wait_for_read函数的下层函数，我们知道其实通过首先自旋加锁pin的方式，超过设定的自旋次数之后，进入等待，等待IO完成被唤醒。这样节省不停自旋pin时消耗的cpu,但需要付出被唤起时的开销。

再继续扩展问题： 如果会话线程A 经过物理IO将数据页1001读入buffer之后，他需要修改这个页，而在会话线程A之后的其他的同样需要访问数据页1001的会话线程，即使在数据页1001被入读buffer pool之后，将仍然处于等待中。因为在数据页上读取或者更新的时候，同样需要上锁，这样才能保证数据页并发读取/更新的一致性。

由此可见，当一个高并发的系统，出现了热点数据页需要从磁盘上加载到buffer pool中时，造成的延迟，是难以想象的。因此排在等待热点页队列最后的会话线程最后才得到需要的页，响应时间也就越长，这就是造成了一个简单的sql需要执行几十秒的原因。

再回头来看上面的问题，mysql数据库出现性能下降时，可以看到操作系统有读IO。 原因是，在数据库对数据页的更改，是在内存中的，然后通过检查点线程进行异步写盘，这个异步的写操作是不堵塞执行sql的会话线程的。所以，即使看到操作系统上有大量的写IO，数据库的性能也是很平稳的。但当用户线程需要查找的数据页不在buffer pool中时，则会从磁盘上读取，在一个热点数据页不是非常多的情况下，我们设置足够大的innodb_buffer_pool的size, 基本可以缓存所有的数据页，因此一般都不会出现缺页的情况，也就是在操作系统上基本看不到读的IO。  当出现读的IO时，原因时在执行buf_read_page_low函数，从磁盘上读取数据页到buffer pool, 则数据库的性能则开始下降，当出现大量的读IO，数据库的性能会非常差。

关于做性能测试有没有遇到瓶颈和性能测试遇到的瓶颈的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 做性能测试有没有遇到瓶颈的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于性能测试遇到的瓶颈、做性能测试有没有遇到瓶颈的信息别忘了在本站进行查找喔。