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

本文涉及的产品
性能测试 PTS,5000VUM额度
简介:

性能测试学习过程中,坚持思想与工具(分开)并行,当前面世面上的性能测试书籍大多把理论与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进行规格选择与性能压测。
目录
相关文章
|
2天前
|
缓存 监控 测试技术
全网最全压测指南!教你如何测试和优化系统极限性能
大家好,我是小米。本文将介绍如何在实际项目中进行性能压测和优化,包括单台服务器和集群压测、使用JMeter、监控CPU和内存使用率、优化Tomcat和数据库配置等方面的内容,帮助你在高并发场景下提升系统性能。希望这些实战经验能助你一臂之力!
12 3
|
10天前
|
开发者 容器
Flutter&鸿蒙next 布局架构原理详解
本文详细介绍了 Flutter 中的主要布局方式,包括 Row、Column、Stack、Container、ListView 和 GridView 等布局组件的架构原理及使用场景。通过了解这些布局 Widget 的基本概念、关键属性和布局原理,开发者可以更高效地构建复杂的用户界面。此外,文章还提供了布局优化技巧,帮助提升应用性能。
73 4
|
12天前
|
缓存 监控 数据挖掘
C# 一分钟浅谈:性能测试与压力测试
【10月更文挑战第20天】本文介绍了性能测试和压力测试的基础概念、目的、方法及常见问题与解决策略。性能测试关注系统在正常条件下的响应时间和资源利用率,而压力测试则在超出正常条件的情况下测试系统的极限和潜在瓶颈。文章通过具体的C#代码示例,详细探讨了忽视预热阶段、不合理测试数据和缺乏详细监控等常见问题及其解决方案,并提供了如何避免这些问题的建议。
34 7
|
10天前
|
存储 Dart 前端开发
flutter鸿蒙版本mvvm架构思想原理
在Flutter中实现MVVM架构,旨在将UI与业务逻辑分离,提升代码可维护性和可读性。本文介绍了MVVM的整体架构,包括Model、View和ViewModel的职责,以及各文件的详细实现。通过`main.dart`、`CounterViewModel.dart`、`MyHomePage.dart`和`Model.dart`的具体代码,展示了如何使用Provider进行状态管理,实现数据绑定和响应式设计。MVVM架构的分离关注点、数据绑定和可维护性特点,使得开发更加高效和整洁。
145 3
|
23天前
|
容器
Flutter&鸿蒙next 布局架构原理详解
Flutter&鸿蒙next 布局架构原理详解
|
1月前
|
存储 分布式计算 druid
大数据-155 Apache Druid 架构与原理详解 数据存储 索引服务 压缩机制
大数据-155 Apache Druid 架构与原理详解 数据存储 索引服务 压缩机制
49 3
|
1月前
|
消息中间件 分布式计算 druid
大数据-154 Apache Druid 架构与原理详解 基础架构、架构演进
大数据-154 Apache Druid 架构与原理详解 基础架构、架构演进
27 2
|
1月前
|
消息中间件 监控 Java
大数据-109 Flink 体系结构 运行架构 ResourceManager JobManager 组件关系与原理剖析
大数据-109 Flink 体系结构 运行架构 ResourceManager JobManager 组件关系与原理剖析
58 1
|
8天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
5天前
|
监控 安全 应用服务中间件
微服务架构下的API网关设计策略与实践####
本文深入探讨了在微服务架构下,API网关作为系统统一入口点的设计策略、实现细节及其在实际应用中的最佳实践。不同于传统的摘要概述,本部分将直接以一段精简的代码示例作为引子,展示一个基于NGINX的简单API网关配置片段,随后引出文章的核心内容,旨在通过具体实例激发读者兴趣,快速理解API网关在微服务架构中的关键作用及实现方式。 ```nginx server { listen 80; server_name api.example.com; location / { proxy_pass http://backend_service:5000;
下一篇
无影云桌面