activemq mysql 性能_ActiveMQ极限性能参数测试结果-Jmeter

本文介绍如何在非GUI模式下运行JMeter进行负载测试,包括准备测试计划、执行测试及停止测试的方法。此外还提供了如何分析测试结果的指南,帮助理解关键指标如平均响应时间、吞吐量等。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Apache JMeter™

Jmeter下载路径

下载Binaries文件

JMeter使用安装使用方法,参考博文:

To run JMeter, run the jmeter.bat (for Windows) or jmeter (for Unix) file. These files are found in the bin directory. After a short time, the JMeter GUI should appear.

Building a JMS Point-to-Point Test Plan

jmeter参考例子

jmeter配置成功activemq Point to Point 运行例子

运行步骤1、

apache-jmeter-3.0\bin\ApacheJMeter.jar

将 jndi.properties 文件添加到ApacheJMeter.jar里面。

java.naming.factory.initial = org.apache.activemq.jndi.ActiveMQInitialContextFactory

java.naming.provider.url = failover://(tcp://test3-dcb:61616,tcp://test2-dcb:61616,tcp://test1:61616)##这里可以是tcp或者是failover协议

(QueueConnectionFactory)context.lookup("connectionFactory")

connectionFactoryNames = connectionFactory

(Queue)context.lookup("MyQueue")

queue.MyQueue = example.MyQueue

在这里配置和步骤二中配置的 your_script.jmx可以起到一样的效果。

运行步骤二、

添加sampleer

f49d31c102e7093108ae1ecbad0c7bbf.png

4d6051e667a15ac5f224c8afb7a5fad8.png

jmeter non gui 使用

使用命令:jmeter -n -t your_script.jmx

例子:

continue

false

-1

100

0

1477399580000

1477399580000

false

connectionFactory

MyQueue

MyQueue

true

false

false

org.apache.activemq.jndi.ActiveMQInitialContextFactory

failover://(tcp://test3-dcb:61616,tcp://test2-dcb:61616,tcp://test1:61616) ####failover://(tcp://test3-dcb:61616,tcp://test2-dcb:61616,tcp://test1:61616)

obj_name

final11111

java.lang.String

obj_type

/service

java.lang.String

id

c064a027-ba94-460b-8831-8d8031fc686c

java.lang.String

created_t

1477472363

java.lang.String

old_obj_name

java.lang.String

具体细节可以参考

Dear Abby BlazeMeter, How Do I Run JMeter in Non-GUI Mode?

Do you think the JMeter GUI is a good GUI?

After all, the GUI is always considerate, shows up on time, is willing to carry it's share of the load....

On one hand, the GUI makes the program more intuitive; on the other hand, it consumes more resources.

Isn’t better to redirect these resources to the generation of useful load tests?

Yes, it is very good idea. Let's review a few typical cases of running JMeter in non-GUI mode.

Step 1. Prepare the JMeter test

Open your *.jmx file

Remove all graphic data writers

They will not work in the non-gui mode and there no need to keep them in testing scenario.

Step 2. Run the JMeter test

Go to bin folder of your JMeter installation from command prompt

Type the following command:

jmeter -n -t D:\TestScripts\script.jmx -l D:\TestScripts\scriptresults.jtl

-n [This specifies JMeter is to run in non-gui mode]

-t  [name of JMX file that contains the Test Plan]

-l  [name of JTL file to log sample results to]

-j  [name of JMeter run log file].

Besides these options, JMeter has several other parameters that can be used for running in non-GUI mode.

-R [list of remote servers] Run the test in the specified remote servers

-H [proxy server hostname or ip address]

-P [proxy server port]

These options are used for remote execution of JMeter tests and for using JMeter through a proxy server.

Step 3. Stop running the test

When running JMeter in non-GUI mode, there is no Menu, and JMeter does not react to keystrokes such as Control + '.'. So in versions post 2.3.2, JMeter non-GUI mode will listen for commands on a specific port (default 4445, see the JMeter property jmeterengine.nongui.port ). In versions post 2.4, JMeter supports the automatic choice of an alternate port if the default port is being used (i.e. by another JMeter instance). In this case, JMeter will try the next highest port, continuing until it reaches the JMeter property jmeterengine.nongui.maxport, which defaults to 4455. If maxportis less than or equal to port , port scanning will not take place.

Note that JMeter 2.4 and earlier did not set up the listener for non-GUI clients, only non-GUI standalone tests; this has been fixed.

The chosen port is displayed in the console window.

The commands currently supported are:

Shutdown - graceful shutdown

stoptest  - immediate shutdown

These commands can be sent by using the shutdown[.cmd|.sh] or stoptest[.cmd|.sh] script respectively. The scripts are to be found in the JMeter /bin directory. The commands will only be accepted if the script is run from the same host.

Note-before using shutdown.cmd or shutdown.sh CLASSPATH variable should be set to path with ApacheJmeter.jar, because inside these files we have string like

“java -cp %~dp0ApacheJMeter.jar org.apache.jmeter.util.ShutdownClient StopTestNow %*”. It means that JVM calls class file from ApacheJMeter.jar.

Look out for the next episode when we discuss interpreting how the *.jtl files feels about communication and if that is created as a result of non-GUI test.

参考博文:

9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure

JMeter Result Analysis

After executing a load test we need to interpret the result. For result interpretation we use Listeners that provide different matrices about the load test. In this post we will see the most commonly used matrices, their meanings and the how they are calculated internally from raw data.

Result matrices by Aggregate Report-

Label- Label is the name of the sample or the Transaction Controller

# Samples - The total number of samples corresponding to a given sample

Average - The average time taken (in milliseconds) to execute the requests under a given label. So, if there are 10 samples getting executed then average time taken will be-

Average = Total time taken by all samples /#samples

Median - The median is basically the middle value of response time in the sorted list of samples

90% Line - The Apache JMeter manual describes 90% line as- "90% of the samples took no more than this time". It is actually the 90 percentile of the response times of the samples -

90 percentile = (90/100)*N+1/2 where N is the number of samples

So, if there are 10 samples then 90%line will be 9.5 or 9. It means the 9th value in the sorted list of samples (sorted according to ascending order of their response times) will be the 90% line value.

Min - The minimum time (in milliseconds) taken by the sample

Max - The maximum time (in milliseconds) taken by the sample

Error % - Percentage of errors in the samples

Throughput - Throughput as we all know is output per unit time. In JMeter terms we define throughput as the amount of load applied on the server. So, numerically-

Throughput = Total number of requests to the server/ Total time

= Total number of requests to the server/(End time of last sample -Start time of first sample)

Here we just defined Total time in which load was applied on the server as time duration between Start of first sample and end of last sample.

KB/sec - The metric KB/sec is nothing but the throughput measured in terms of bytes. So,

KB/sec = (Throughput*Average bytes) /1024

Here Average bytes is the average value of the sample response in bytes and the term 1024 is used to convert the value (Throughput*Average bytes) into kilobytes.

### 性能测试环境的基本配置要求 #### 硬件配置 性能测试环境的硬件配置通常需要满足一定的标准,以确保能够模拟实际生产环境的压力和负载情况。根据常见的实践经验和具体案例[^2],以下是性能测试环境中主要组件的推荐硬件配置: - **TiDB** - CPU:8 核及以上。 - 内存:16 GB 或更高。 - 存储:无特殊要求(适用于开发及测试场景),但在高性能需求下建议使用 SSD。 - 网络:千兆网卡。 - **PD (Placement Driver)** - CPU:4 核及以上。 - 内存:8 GB 或更高。 - 存储:SAS 类型硬盘,容量至少 200 GB。 - 网络:千兆网卡。 - **TiKV** - CPU:8 核及以上。 - 内存:32 GB 或更高。 - 存储:SSD 类型硬盘,容量至少 200 GB。 - 网络:千兆网卡。 - 实例数量:最低需部署 3 个实例以保障分布式一致性。 - **TiFlash** - CPU:32 核及以上。 - 内存:64 GB 或更高。 - 存储:SSD 类型硬盘,容量至少 200 GB。 - 网络:千兆网卡。 - **TiCDC** - CPU:8 核及以上。 - 内存:16 GB 或更高。 - 存储:SAS 类型硬盘,容量至少 200 GB。 - 网络:千兆网卡。 以上配置主要用于 TiDB 数据库系统的性能测试环境搭建,其他类型的系统可以根据其特定需求调整资源分配。 --- #### 软件需求 除了硬件配置外,性能测试环境还需要考虑以下几个方面的软件需求[^1][^3]: 1. **操作系统** 需要选择适合目标应用程序的操作系统版本,并确保该版本支持所需的硬件架构(如 x86-64 或 ARM)。常用的 Linux 发行版包括 CentOS、Ubuntu 和 Red Hat Enterprise Linux (RHEL),这些发行版因其稳定性和广泛的社区支持而被广泛采用。 2. **中间件和服务依赖** 如果待测系统涉及 Web 应用,则可能需要用到 Apache Tomcat、Nginx 或 Jetty 等应用服务器;如果涉及到消息队列服务,则 Kafka、RabbitMQ 或 ActiveMQ 是常见选项。此外,还需安装并配置数据库管理系统(如 MySQL、PostgreSQL)、缓存技术(Redis、Memcached)以及其他必要的后台服务。 3. **网络设置** 正确配置防火墙规则、DNS 解析以及端口映射等网络参数至关重要。这一步骤旨在减少因外部因素引起的延迟或连接失败问题,从而获得更精确的性能指标数据。 4. **监控工具** 使用专业的 APM(Application Performance Management) 工具来跟踪整个生命周期内的各项 KPI(Key Performance Indicators),比如 JMeter、Gatling 或 LoadRunner 进行压力加载的同时配合 Grafana + Prometheus 对资源消耗情况进行可视化展示。 5. **脚本编写与执行框架** 自动化程度较高的企业可能会利用 Python/Java 编写定制化的测试脚本来覆盖复杂的业务逻辑路径,通过 Jenkins/Pipeline 将多个阶段串联起来形成完整的 CI/CD 流程链路。 综上所述,构建一个完善的性能测试环境不仅限于简单的软硬件组合,还应该综合考虑到各种潜在影响因子的作用效果评估机制建立等方面的内容[^4]。 ```bash # 示例命令用于验证 Linux 下的基础环境是否正常工作 uname -a && cat /etc/os-release && free -h && df -hT && ip addr show ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值