【转】关于loadrunner中设置进程和线程的区别

本文探讨了LoadRunner中Vuser的两种运行模式:按进程运行和按线程运行。分析了两种模式下Vuser的具体行为、内存占用情况及可能带来的问题。并对比了进程与线程在资源分配、执行过程等方面的区别。

loadrunner中,在进行运行设置中有一项选择,是按进程运行Vuser或按线程运行Vuser?下面进行分别来讲:

1.按进程运行Vuser:Controller将使用驱动程序mdrv运行Vuser。如果按进程方式运行每个Vuser,则对于每个Vuser实例,都将启动一个mdrv进程。如果设置了10个Vuser,则在任务管理器中出现10个mdrv进程。多个mdrv进程肯定会占用大量内存及其他系统资源,这就限制了可以在任一负载生成器上运行的Vuser的数量。

2.按线程运行Vuser:及设置了10个Vuser,其只会调用一个驱动程序mdrv.而每个Vuser都按线程运行,这些线程Vuser将共享父进程的内存段。这就节省了大量内存空间,从而可以在一个负载生成器上运行更多的Vuser。

   任何选择都是有两面性的。选择线程方式运行Vuser会带来一些安全问题。因为线程的资源是从进程资源中分配出来的,因此同一个进程中的多个线程会有共享的内存空间,这样可能会引起多个线程的同步问题,调度不好,就会出问题,比如A线程要用的资源就必须等待B线程释放,而B也在等待其他资源释放才能继续。这就会出现这样的问题:同一个测试场景,用线程并发就会超时失败或报错,而用进程并发就没错。

    虽然会有区别,但两种方式的运行都会给服务端造成的压力是一样的。

进程(Process)和线程(Thread)的关系和区别

 

Definition定义
-------------
Process
进程是应用程序的一次运行活动;
从操作系统核 心角度来说,进程是操作系统分配和调度系统内存资源、cpu时间片等资源的基本单位,为正在运行的应用程序提供

运行环境。

Thread
线程是程序内部有并发性的顺序代码流。是cpu调度资源的最小单元。


Units单位大小
------------
Process
进程是操作系统分配和调度系统内存资源、cpu时间片 等资源的基本单位;一个进程至少包括一个线程。
进程是操作系统资源管理的实体。
Thread
线程是cpu调度资源的最小单元。
线 程是进程的实体。


Resource系统资源分配上
-------------
Process
每个进程都有自己的内存地址空间。
Thread
线 程没有自己独立的内存资源,它只有自己的执行堆栈和局部变量。但是在同属一个进程的多个线程中他们可以共享进程的内存

资源。

Running执行过程中
-------------
执行过程中,进程有内存单元的初始入口点,在存活阶段里拥有独立的地址空间。
A process has the initial entrance of Memory Units and room of address.

进程是应用程序的一次运行活动,独立地执行;所以某一个进程崩溃以后,在保护模式下不会影响其他的进程,
健壮性好。
A process is activity of application.

父进程与子进程 的关系待研究深入中……

每个已创建的进程都可以创建进程,创建进程的进程称为父进程,被创建的新进程为子进程,这样便形成一个进程树。父进程与子进程可并行执行;父进程等 待子进程终止执行。父进程终止后,所有的子进程也都必须要终止。

Thread
而线程不能独立地执行,它必须依附在一个运行中的应用程序上。
但是,同一个进程中的多个线程可以并发地执行,并发性 高,系统在数据交换上花费的资源少,运行效率高。

主线程与其他线程 的关系待研究深入中……

每个进程里都会有一个主线程,由它创建其他线程。

======================================================

Common ground 共同点
--------------
Process和Thread都有生命周期:
create 创建,ready就绪,running运行,waitSleepJoin阻塞,suspend挂起,stoped死亡

<think>嗯,用户再次询问LoadRunnerJMeter的区别,看来ta对这两个工具的核心差异特别关注。之前已经给过基础对比,但用户引用了站内资料要求更深入分析,尤其是架构层面的特性。 用户引用的资料点出了关键:JMeter基于Java线程模型,每个进程开销大,需要更多负载机;而LoadRunner进程式架构更轻量。这确实是本质区别之一。不过用户似乎更想系统化了解,需要从多个维度展开。 从技术角度看,应该补充几个核心差异点:首先是协议支持,LoadRunner对传统企业级协议(如Citrix、Tuxedo)的支持是JMeter缺乏的;其次是监控能力,LoadRunner的深度诊断模块明显更强;还有资源消耗模型,JMeter的线程架构在Windows下确实容易成瓶颈。 用户可能是个测试工程师,正在做工具选型。ta连续追问区别,说明需要实际落地建议。除了技术参数,还得考虑成本因素——JMeter开源免费的优势对中小团队很关键,而LoadRunner的投入通常要百万级。 上次回答提到的分布式差异需要强化:JMeter的Agent配置更灵活但管理稍弱,LoadRunner的负载控制器更成熟但扩展成本高。这个点用户引用了资料[1][2],可以重点展开。 啊,脚本开发体验也很重要。JMeter的BeanShell对Java开发者友好,而LoadRunner的C语言脚本性能更好。这个对比要体现在回答里,用户似乎没意识到语言选择的影响。 最后资源监控部分,用户引用的资料[3]提到LoadRunner的监控深度,这点要突出——比如它能直接监控数据库中间件,而JMeter需要插件。 </think> 以下是 LoadRunner 与 JMeter 的核心区别对比,结合技术架构实际应用场景分析: --- ### **1. 架构与执行模型** | **维度** | **JMeter** | **LoadRunner** | |----------------|-------------------------------------------|-------------------------------------------| | **底层技术** | 基于 Java,运行于 JVM | 基于 C/C++,原生进程执行 | | **虚拟用户模型** | **线程级虚拟用户**<br>(单进程线程,受限于 JVM 线程内存) | **进程级虚拟用户**<br>(独立进程运行,资源隔离性更好)[^1] | | **资源开销** | 高并发时内存消耗大,需更多负载机支持 | 单机可承载更高并发,资源利用率更优 | > 💡 **关键差异**:JMeter 的线程模型在 Windows 下易受线程数限制(通常 ≤ 1000 线程/进程),而 LoadRunner进程模型可绕过此限制,适合超大规模测试。 --- ### **2. 分布式测试能力** | **功能** | JMeter | LoadRunner | |------------------|---------------------------------------------|------------------------------------------| | **实现方式** | 通过 Master-Agent 架构远程控制多台负载机 | 通过 Load Generator 集群分发任务 | | **管理复杂度** | 需手动配置 Agent 节点,扩展灵活但维护稍复杂 | 集中式控制台管理,自动化程度高 | | **适用场景** | 中小规模分布式测试(成本低) | 企业级超大规模测试(万级并发+)[^2] | --- ### **3. 协议与协议支持** | **类型** | JMeter | LoadRunner | |------------------|-----------------------------------|-----------------------------------------| | **常见协议** | HTTP/HTTPS, FTP, JDBC, JMS, SOAP | 覆盖 50+ 协议,包括 **Citrix, SAP, Oracle** | | **企业级支持** | 依赖插件扩展(如 WebSocket) | 原生深度支持企业级协议(如 ERP、中间件)[^3] | | **移动端测试** | 需集成 Appium 或第三方工具 | 内置 Mobile Recorder 录制移动端脚本 | --- ### **4. 脚本开发与扩展** | **能力** | JMeter | LoadRunner | |------------------|---------------------------------------------|---------------------------------------------| | **脚本录制** | 通过 HTTP(S) 代理录制 | 支持 **无侵入录制**(网络抓包级录制) | | **脚本语言** | BeanShell/Groovy(Java 生态) | C/Javascript(高性能,贴近底层) | | **扩展性** | 开源插件丰富(500+ 插件库) | 需购买特定协议支持包,定制成本高 | | **调试能力** | 基础日志断言 | 内置 **深度调试器**(运行时变量跟踪) | --- ### **5. 资源监控与分析** | **功能** | JMeter | LoadRunner | |------------------|---------------------------------------------|---------------------------------------------| | **监控粒度** | 基础服务器指标(CPU/内存)需插件扩展 | 深度监控 **应用服务器/DB/中间件**(如 WebLogic, SQL Server) | | **诊断工具** | 依赖第三方集成(如 Prometheus+Grafana) | 内置 **Diagnostics** 模块(自动定位性能瓶颈) | | **报告生成** | 基础 HTML 报告,需定制 | 专业级 **Analysis** 报告(关联事务与资源指标)[^3] | --- ### **6. 成本与适用场景** | **维度** | JMeter | LoadRunner | |----------------|---------------------------------------------|---------------------------------------------| | **授权费用** | 开源免费 | 商业授权(约 $10,000+/年) | | **学习曲线** | 入门简单,社区资源丰富 | 需专业培训,掌握成本高 | | **最佳场景** | 中小项目、API/Web 测试、预算有限团队 | 企业级复杂系统(银行/电信)、超高压测试 | > ⚠️ **统计参考**:单机 JMeter 通常支持 500-1000 并发,LoadRunner 可达 3000-5000 并发(同硬件配置)[^1]。 --- ### **总结选择建议** - **选 JMeter 当**:测试以 HTTP/API 为主,预算有限,需要快速上手灵活扩展。 - **选 LoadRunner 当**:涉及企业级协议(如 SAP),需万级并发压测或深度诊断能力,且预算充足。 ```python # JMeter 分布式测试配置示例(部分伪代码) jmeter_master.configure( agents=["192.168.1.101:1099", "192.168.1.102:1099"], test_plan="web_test.jmx" ) # LoadRunner 脚本片段(C语言) vuser_init() { web_set_user("user", "password", "example.com:443"); lr_start_transaction("login"); web_url("login", "URL=https://example.com/login", LAST); lr_end_transaction("login", LR_AUTO); } ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值