性能测试知多少---性能测试工具原理与架构

简介:

性能测试学习过程中,坚持思想与工具(分开)并行,当前面世面上的性能测试书籍大多把理论与loadrunner融为一体讲解,这样做是正确的,因为有一些性能名词概念也源于工具。但是,性能测试不是loadrunner,所有的作者也是这么认为的。但他们在讲性能测试的时候讲的就是loadrunner有,只是讲的多少不同罢啦。

  你是否觉得我对loadrunner有仇?我之所以将其分开来学,只是希望自己在学习性能测试的时候不要被loadrunner局限了而已。只是觉得在做性能测试时不要带loadrunner的思维,这样更容易把握性能测试的本质。

  性能测试工具,从广义上讲,在性能测试过程中使用到的所有工具都可以称其为性能测试工具。从狭义上来讲,我们可以把性能测试工具分为服务器端性能测试工具与前段性能测试工具。

  服务器端性能测试工具也我们测试人员通常所认为的性能测试工具。LoadRunner、JMeter、SilkPerformance、服务器端压力性能工具需要支持产生压力和负载,录制和生成脚本,设置和部署场景,产生并发用户和向系统施加持续的压力。

  前端性能测试工具应用比较广泛,开发人员,前端开发人员、测试人员都会经常用到。Firebug 、fildder2、Yslow 、前端性能测试工具只需要关于心浏览器等客户端工具对具体需要展现的页面的处理过程。

  服务器性能测试工具原理

  性能测试工具的主要作用是通过模拟生产环境中的真实业务操作,对被测试系统实行压力负载测试,监视被 测试系统在不同业务、不同压力性能下的性能表现,找出潜在的性能瓶颈进行分析、优化。

  客户端与服务器相当于两个人,通过信息来进行交流。由于初次见面不好意思直接交流,与是找来了中间传话人,客户端把信息告诉给传话人,由传话人来转达给服务器。那么服务器反馈的信息也由传话人转达给客户端。一般性能测试工具都需要录制或编写客户端行为脚本。

  这样传达人就有了客户端的行为能力,从而假扮客户端来欺骗服务器,与之进行通信。有了客户端行为了传达人可以进行自我复制。从而变出N多个传达人对服务器进通信。---这个传达人的行为和能力也就是性能测试工具的基本特质。(突然觉得性能工具像第三者插足,而且是可以自我复制疯狂变态的第三者,哈哈!)

  对于目前流行的性能测试工具,他们的基本工作原理都是一致的。在客户端通过多线程或多进程模拟虚拟用户访问,对服务器端施加压力,然后在过程中监控和收集性能数据。

  性能测试工具应该具备什么的特质呢?

  1、工具本身占用系统资源少,可扩展性好,可用性强。

  2、能模拟真实业务事务操作,在并发时能真正产生业务压力。(这一点是核心)

  3、对压力测试结果能很好地进行性能分析,快速找出被测试系统的瓶颈。

  4、测试脚本的重复性强。

  服务器性能测试工具的架构

  用户行为生成部分

  我为什么说的这么朦胧,对于熟悉loadrunner的朋友,我说成虚拟用户脚本生成器,你更容易理解,这个脚本,我们可以录制,也可以手工编写。你不要以为这是生成用户行为的唯一方式。因为在JMeter成中是添加各种组件,通过对组件的配置来完成用户行为的,当然也可以通过录制。而在相对简陋的性能测试工具curl_loader(linux环境下的运行的),他是通过编写配置文件的形式来描述用户形为的。

  我前面也有提了,虽然性能测试工具由不同的形式来描述,但他们的原理是一样的,都是通过Proxy方式来实现,具体来说,Proxy作为客户端和服务器之间的中间人,接收客户端的数据包。

  压力产生器

  压力产生器用于根据脚本内容产生实际的负载,在性能测试工具中,压力产生器扮演着“产生负载”的角色。也就根用户的设置,进行自我复制来生成多个客户端向服务器发送请求。对于工具来说,每复制出来的一份就是一个进程或线程,进程和线程的运行是要占用系统资源的。所以,对一台压力测试机来说能运行的虚拟用户数也是有限的。根基测试机的配置而定。那么这个时候就要通过多台测试机合作,来模拟更多的虚拟用户向服务器发请求。

  那么,对于性能测试来说,很重要的一点就是产生“并发”的请求,不然就不会对服务器产生压力。那多台机子如何产生“步调一致”的虚拟用户呢?使用“用户代理”

  用户代理

  用户代理是运行在负载机上的进程,该进程与产生负载压力的进程或线程协作,接收调度系统的命令,调度产生负载压力的进程或线程,从这个意义上看,用户代理也是压力产生器的一部分。

  调度能力

  我们在做复杂的性能测试时,常常会设计各种场景,不同的虚拟用户数,不同事务的用户比例,运行时间,设置同步点等,这个时候也需要我们的测试工具有压力调度能力。从而才能更真实的模拟我们所设计的运行场景。

  监控系统

  监控系统是性能测试工具直接与用户进行交互的主要部分,监控系统,主要用户在压力测试过程中对各种软硬件进行监控,如对数据库、应用服务器,服务器的主要性能表现情况进行监控。用于判断系统当前处于什么状态。

  当然,监控系统不是性能工具必须的部分,可以通过软硬件系统自身的监控工具或者第三方监控工具进行监控。但是否有强大的性能计数器监控系统是衡量性能测试工具是否强大的指标之一。

  压力结果分析

  压力结果分析工具可以用来辅助进行测试结果的分析,性能测试工具一般都能将监控系统获取的性能技术数器值生成曲线图,折线图等各种图表。通过展现性能测试过程中的各种参数指标,来供测试人员进行分析。

  但这里需要强调的是,压力结果分析工具本身不能代替分析者进行性能结果分析,而只是提供多种不同的数据揭示和呈现方法而已。对于这些数据进行分析必然要依靠测试工程师对系统性能分析的知识和经验。

  对上面介绍的性能测试工具架构的组成部分,不是第一个性能测试工具都具备,而所具备的强大程度也不相同。比如,有些性能测试工具不具备用户代理能,有些监控系统能监控的资源很有限或简陋,有些结果分析数据的呈现不够详尽等。








====================================分割线================================



最新内容请见作者的GitHub页:http://qaseven.github.io/

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
目录
相关文章
|
1月前
|
JavaScript jenkins 测试技术
这10款性能测试工具,收藏起来,测试人的工具箱!
这10款性能测试工具,收藏起来,测试人的工具箱!
|
1月前
|
存储 搜索推荐 数据挖掘
ElasticSearch架构介绍及原理解析
ElasticSearch架构介绍及原理解析
84 0
|
1月前
|
存储 运维 负载均衡
MFS详解(二)——MFS原理和架构
MFS详解(二)——MFS原理和架构
30 0
|
20天前
|
设计模式 安全 Java
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
23 0
|
11天前
|
人工智能 分布式计算 Kubernetes
人工智能,应该如何测试?(三)数据构造与性能测试篇
本文探讨了人工智能场景中的性能测试,区别于传统互联网测试,其复杂性更高。主要关注点包括两类AI产品——业务类和平台类,后者涉及AI全生命周期,测试难度更大。测试重点是模型训练的性能,特别是数据模拟。需要构造大量结构化数据,如不同规模、分布、分片和特征规模的数据,以评估算法效率。此外,还涉及模拟设备规模(如视频流)和节点规模(边缘计算),以测试在大规模负载下的系统性能。文中提到了使用工具如Spark、ffmpeg、流媒体服务器和Kubernetes(K8S)的扩展项目,如Kubemark,来模拟大规模环境。最后,文章介绍了使用Golang进行异步IO操作以构建海量小文件,优化IO性能。
26 0
|
20天前
|
存储 Java 应用服务中间件
【分布式技术专题】「架构实践于案例分析」盘点互联网应用服务中常用分布式事务(刚性事务和柔性事务)的原理和方案
【分布式技术专题】「架构实践于案例分析」盘点互联网应用服务中常用分布式事务(刚性事务和柔性事务)的原理和方案
42 0
|
1月前
|
算法 Java 测试技术
性能工具之代码级性能测试工具ContiPerf
【2月更文挑战第23天】性能工具之代码级性能测试工具ContiPerf
265 1
性能工具之代码级性能测试工具ContiPerf
|
1月前
|
消息中间件 存储 SQL
Flume【基础知识 01】简介 + 基本架构及核心概念 + 架构模式 + Agent内部原理 + 配置格式(一篇即可入门Flume)
【2月更文挑战第18天】Flume【基础知识 01】简介 + 基本架构及核心概念 + 架构模式 + Agent内部原理 + 配置格式(一篇即可入门Flume)
447 0
|
1月前
|
存储 分布式计算 Hadoop
一文了解Apache Hudi架构、工具和最佳实践
一文了解Apache Hudi架构、工具和最佳实践
70 0
|
1月前
|
缓存 监控 安全
Istio架构及工作原理
【2月更文挑战第17天】从 Istio 的设计和实现原理可以看出,它是采用模块化设计,并且各个模块之间高度解耦,Proxy 专注于负责服务之间的通信,Pilot 专注于流量控制,Mixer 专注于策略控制以及监控日志功能,而 Citadel 专注于安全。