国产系统下的软件性能测试（麒麟系统+Apache Jmeter安装+MariaDB安装+简单性能测试全流程+保姆级教程）

一、实验目的

熟悉并掌握软件性能测试的常用指标和方法

熟悉Apache Jmeter用法

二、实验环境

国产操作系统统信OS或者麒麟，其他linux系统其实也可，但本文主要介绍国产系统下的流程。

Apache Jmeter

三、实验内容

四、实验过程

1.完成在国产操作系统下Apache Jmeter的安装并熟悉其使用方法

1.1 安装国产操作系统虚拟机（我使用的银河麒麟Kylin-Desktop-V11，直接从麒麟官网下载即可，这里不再赘述）

1.2安装JDK

1.2.1更新系统软件包

打开终端（快捷键：Ctrl+Alt+T），先更新系统依赖，确保安装环境稳定：

sudo apt update  # 更新软件源索引

sudo apt upgrade -y  # 升级已安装软件（-y自动确认）

1.2.2安装 OpenJDK 11

执行以下命令安装 OpenJDK 11（无需手动下载，统信 UOS 通过 apt 直接获取）：

sudo apt install openjdk-11-jdk -y

1.2.3验证 JDK 安装成功

安装后需确认 Java 环境配置正常，执行两个命令验证：

（1）查看 Java 版本：java -version成功提示（版本号可能略有差异，只要是 11.x 即可）

（2）查看 Java 编译器版本：javac -version成功提示（需与 java 版本一致）

1.2.4 配置 JAVA_HOME 环境变量

查找 JDK 安装路径：输入命令update-alternatives –config java，复制输出中「/usr/lib/jvm/」后的路径（如/usr/lib/jvm/java-11-openjdk-amd64）。

（1）编辑系统环境变量文件：

sudo vim /etc/profile

（2）在文件末尾添加（将路径替换为实际查找的 JDK 路径）：

export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64

export JRE_HOME=${JAVA_HOME}/jre

export CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib

export PATH=${JAVA_HOME}/bin:$PATH

（3）激活环境变量：

source /etc/profile

验证配置：输入echo $JAVA_HOME，输出 JDK 路径即配置成功。

1.3Apache JMeter 安装与配置（实验核心工具）

1.3.1终端中使用wget命令下载最新稳定版（以 5.6.3 为例，适配 JDK11）

wget https://dlcdn.apache.org/jmeter/binaries/apache-jmeter-5.6.3.tgz

1.3.2 解压与目录配置

（1）解压压缩包到/opt目录（系统级目录，方便管理）：

sudo tar -zxvf apache-jmeter-5.6.3.tgz -C /opt

（2）重命名目录（简化路径）

sudo mv /opt/apache-jmeter-5.6.3 /opt/jmeter

1.3.3配置 JMeter 环境变量

（1）编辑/etc/profile文件：

sudo vim /etc/profile

（2）在文件末尾添加：

export JMETER_HOME=/opt/jmeter

export PATH=$PATH:$JMETER_HOME/bin

（3）激活环境变量：

source /etc/profile

（4）验证安装：

输入jmeter –version，输出 JMeter 版本信息（如Apache JMeter 5.6.3）即安装成功。

1.3.4启动 JMeter

终端输入：jmeter

2 Web 系统性能测试

我选择访问麒麟官网：https://www.kylinos.cn/

2.1 验证Web 系统可访问性

先确保麒麟系统能正常访问目标 Web 系统，避免因网络 / 权限问题导致测试失败：

（1）打开麒麟系统的「奇安信浏览器」（系统预装，桌面图标）；

（2）在地址栏输入 https://www.kylinos.cn/（麒麟官网，HTTPS 协议），确认能正常加载首页（显示 “银河麒麟操作系统” 标题、轮播图）；

（3）访问产品下载列表页 https://www.kylinos.cn/support/trial/download/，确认能显示 “桌面操作系统”“服务器操作系统” 等产品分类；

2.2配置 JMeter Web 测试计划

2.2.1新建测试计划并配置线程组

（1）启动 JMeter：终端执行 jmeter；

（2）右键左侧面板的Test Plan → 选择 Add → Threads (Users) → Thread Group，在右侧面板配置 Thread Group 参数（对应不同并发场景）：

①Number of Threads (users)：填写并发用户数（如低并发填10）

②Ramp-Up Period (in seconds)：填写用户启动时间（如5，表示 5 秒内启动 10 个用户）

③Loop Count：填写循环次数（如10）

2.2.2添加 HTTP Request Defaults（复用 Web 系统公共配置）

右键左侧的 Thread Group → 选择 Add → Config Elements → HTTP Request Defaults

在右侧面板填写：

Protocol [http/https]：填https（麒麟官网用 HTTPS）

Server Name or IP：填www.kylinos.cn

Port Number：填443（HTTPS 默认端口，HTTP 为 80，此处需填 443）

Content encoding：填UTF-8（避免中文响应乱码）；

其他参数默认，点击「保存」（后续取样器可复用此配置，无需重复填服务器地址）。

2.2.3添加 HTTP Request（对应麒麟官网 2 个核心功能）

取样器 1：首页访问（Homepage Access）

（1）右键 Thread Group → Add → Samplers → HTTP Request；

（2）配置：

Name：Homepage Access;

Method：GET；

Path：/（对应官网首页，即https://www.kylinos.cn/）；

参数：无需添加（首页访问无请求参数）；

勾选Use browser-compatible header（使用浏览器兼容的头，模拟真实浏览器请求，避免被服务器拦截）。

取样器 2：产品列表查询（Product List Query）

（1）右键 Thread Group → Add → Samplers → HTTP Request；

（2）配置：

Name：Product List Query;

Method：GET；

Path：/support/trial/download/（对应官网产品列表页）；

其他参数与「首页访问」一致（复用 HTTP 请求默认值）。

2.2.4添加 Listeners（收集性能指标）

右键 Thread Group → Add → Listeners，依次添加以下 4 个（覆盖实验要求的所有指标）：

· Aggregate Report（核心指标：平均响应时间、分位数、吞吐量等）

· View Results Tree（验证请求是否成功）

· Response Time Percentiles Graph（可视化 90%/95%/99% 响应时间）

· Summary Report（实时监控请求数 / 错误率）

2.3运行测试并保存指标数据

点击顶部工具栏的 Start 按钮（绿色三角形图标），启动测试

测试完成后，右键 Aggregate Report → 选择 Save Table Data，保存指标数据

2.3.1 分场景运行测试

低并发测试：

线程组参数设为「低并发（10 线程）」；

点击 JMeter 工具栏「启动」按钮（绿色三角形），等待测试完成；

测试完成后，右键「Aggregate Report」→「Save Table Data」，命名为「Low concurrency.csv」（存到桌面，方便后续整理）；

低并发：

重复此操作，依次运行「中并发（50 线程）」「高并发（100 线程）」，分别保存为「Medium_concurrency.csv」「High_concurrency.csv」。

中并发：Medium_concurrency

高并发：High_concurrency

2.3.2 验证测试有效性

打开「查看结果树」，筛选「成功」请求（顶部下拉选 “成功”），确认 2 个取样器的「响应代码」为200（HTTP 成功状态码）；

2.4指标分析

2.4.1提取核心指标

低并发：

中并发

高并发

2.4.2 Web 性能指标的分析

1.系统稳定性

所有请求的Error %均为 0.000%，说明在当前压力下（200 次首页请求 + 200 次产品列表请求），麒麟官网 Web 系统的服务可用性极佳，未出现请求失败、超时等异常。

2.响应时间表现

首页访问（Homepage Access）：平均响应时间 398ms，99% 请求的响应时间≤1399ms，最大响应时间 2479ms—— 首页资源（如轮播图、导航栏）加载效率较好，多数用户能在 400ms 内完成访问。

产品列表查询（Product List Query）：平均响应时间 1164ms（是首页的 2.9 倍），99% 请求响应时间≤2870ms—— 产品列表需加载多类产品的图片、描述等资源，数据量更大，导致响应时间显著高于首页。

总吞吐量（Throughput）为 7.43 requests/sec，说明系统每秒可处理约 7.4 个请求；Received KB/sec达 1688.19（接收数据量），反映页面包含较多静态资源（如图片），但当前带宽消耗在合理范围内。

3 数据库性能测试

3.1安装MariaDB

3.1.1更新系统源：

打开麒麟系统终端（快捷键Ctrl+Alt+T），执行以下命令：

# 更新系统软件源索引

 sudo apt update

# 升级已安装软件（可选，确保系统环境稳定）

 sudo apt upgrade -y

3.1.2 安装 MariaDB 服务器 + 客户端

麒麟桌面版自带 MariaDB 官方源，直接安装：

# 安装MariaDB服务器和客户端（核心包）

sudo apt install -y mariadb-server mariadb-client

# 验证安装结果（显示“active (running)”即为成功）

sudo systemctl status mariadb

3.1.3 初始化 MariaDB（安全配置 + 设置密码）

执行 MariaDB 官方安全初始化脚本，按提示操作：

sudo mysql_secure_installation

按以下步骤回答交互提示（关键步骤标红）：

Enter current password for root (enter for none): → 直接回车（默认无密码）；

Set root password? [Y/n] → 输入Y，然后设置密码（如muc5210.，记住此密码）；

Remove anonymous users? [Y/n] → 输入Y；

Disallow root login remotely? [Y/n] → 输入N（允许 JMeter 远程 / 本地连接）；

Remove test database and access to it? [Y/n] → 输入Y；

Reload privilege tables now? [Y/n] → 输入Y。

3.1.4授权 root 远程访问（JMeter 连接必需）

# 登录MariaDB（无需密码，直接回车）

 sudo mysql -uroot

# 授权root允许所有IP访问（替换密码为你设置的MariaDB123!）

GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'muc5210.' WITH GRANT OPTION;

 # 刷新权限

FLUSH PRIVILEGES;

# 退出

MariaDB exit;

3.2创建测试库/表/初始数据 + JMeter 驱动准备

3.2.1创建数据库测试环境（核心）

1.修改MariaDB 的 root 用户的认证方式：

（1）绕过认证登录 MariaDB（核心）

sudo mysql -uroot # 用sudo执行，跳过密码认证

执行后会进入 MariaDB 的命令行界面（显示MariaDB [(none)]>提示符）。

（2）修改 root 用户的认证方式 + 重置密码

在 MariaDB 命令行中执行以下 SQL

— 切换到mysql系统库（存储用户权限）

USE mysql;

 — 修改root用户的认证方式为密码认证，并设置密码为muc5210.

UPDATE user SET plugin = 'mysql_native_password', password = PASSWORD('muc5210.') WHERE user = 'root' AND host = 'localhost';

— 同时确保远程访问的root用户也用密码认证（适配JMeter连接）

UPDATE user SET plugin = 'mysql_native_password', password = PASSWORD('muc5210.') WHERE user = 'root' AND host = '%';

 — 刷新权限（使修改生效）

FLUSH PRIVILEGES;

— 退出MariaDB

EXIT;

2.登录 MariaDB，执行 SQL 创建测试库、表和初始数据：

# 登录MariaDB（输入密码MariaDB123!）

 mysql -uroot -pmuc5210.

 # 1. 创建测试库

test_db CREATE DATABASE test_db;

# 2. 切换到test_db库

USE test_db;

# 3. 创建学生表student_db（增删改查核心表）

CREATE TABLE student_db ( id INT PRIMARY KEY AUTO_INCREMENT,

# 主键自增

name VARCHAR(50) NOT NULL,

# 学生姓名

age INT NOT NULL,

# 年龄

class VARCHAR(50) NOT NULL,

# 班级

create_time DATETIME DEFAULT CURRENT_TIMESTAMP # 创建时间 );

 # 4. 插入1000条初始数据（用于查询/更新测试）

DELIMITER //

# 定义存储过程分隔符

CREATE PROCEDURE insert_test_data() BEGIN DECLARE i INT DEFAULT 1; WHILE i <= 1000 DO INSERT INTO student_db (name, age, class) VALUES (CONCAT('初始用户',i), FLOOR(RAND()*12+18), CONCAT('23级软件',FLOOR(RAND()*10+1),'班'));

SET i = i + 1;

 END WHILE;

END // DELIMITER ;

# 恢复默认分隔符

 # 执行存储过程，插入1000条数据

CALL insert_test_data();

# 验证数据（返回1000则成功）

SELECT COUNT(*) FROM student_db; # 退出MariaDB exit;

3.2.2 下载 MariaDB JDBC 驱动（JMeter 连接必需）

MariaDB 需用专属 JDBC 驱动（不能用 MySQL 驱动）：

# 从Maven中央仓库下载最新稳定版MariaDB JDBC驱动

wget https://repo1.maven.org/maven2/org/mariadb/jdbc/mariadb-java-client/3.3.4/mariadb-java-client-3.3.4.jar

3.将驱动复制到 JMeter 扩展目录：

sudo cp ~/下载/mariadb-java-client-3.3.4.jar /opt/jmeter/lib/ext

验证驱动是否复制成功：

ls /opt/jmeter/lib/ext | grep mariadb

4.重启 JMeter（确保驱动加载）：关闭已打开的 JMeter，重新执行jmeter启动。

由于我之前的设置的临时的环境变量，每次启动都要source一下，现在我修改一下：

nano ~/.bashrc

，在文件最后一行添加以下内容（替换成你自己的 JMeter 路径）：

export PATH=/opt/jmeter/bin:$PATH

保存退出后再执行：

source ~/.bashrc

然后重新启动一下

3.3JMeter 配置数据库性能测试

3.3.1新建测试计划 + 配置线程组（模拟并发）

1.启动 JMeter（终端执行jmeter），右键左侧Test Plan → Add → Threads (Users) → Thread Group；

2.配置 2 个并发场景（需分别测试，先低后高）：

3.3.2配置 JDBC Connection Configuration（关联 MariaDB）

1.右键Thread Group → Add → Config Elements → JDBC Connection Configuration；

2.右侧面板填写以下参数（关键，错一个会连接失败）：

3.3.3添加增删改查 JDBC Request 取样器

右键Thread Group → Add → Samplers → JDBC Request，依次创建 4 个取样器（英文界面操作）：

取样器 1：查询操作（Select）

• Name：Query Student (age<25)
• Variable Name：mariadb_conn
• Query Type：Select Statement
• SQL Query：SELECT * FROM student_db WHERE age < 25 LIMIT 100;

取样器 2：插入操作（Insert）

• Name：Insert Test Student
• Variable Name：mariadb_conn
• Query Type：Update Statement（Insert/Update/Delete 均选此类型）
• SQL Query：INSERT INTO student_db (name, age, class) VALUES ('JMeterTest${__Random(1,1000,)}', ${__Random(18,30,)}, '23Soft${__Random(1,10,)}');

取样器 3：更新操作（Update）

• Name：Update Student Age
• Variable Name：mariadb_conn
• Query Type：Update Statement
• SQL Query：UPDATE student_db SET age = age + 1 WHERE id = ${__Random(1,1000,)};

取样器 4：删除操作（Delete）

• Name：Delete Test Student
• Variable Name：mariadb_conn
• Query Type：Update Statement
• SQL Query：DELETE FROM student_db WHERE id > 1000;（仅删除测试插入的数据，保护初始数据）

步骤 4：添加监听器（收集性能指标）

右键Thread Group → Add → Listeners，添加 3 个核心监听器：

• Aggregate Report（核心：响应时间、吞吐量、错误率、90%/95%/99% 分位数）；
• View Results Tree（调试：验证 SQL 是否执行成功）；
• Summary Report（实时监控：并发请求数、成功数）。

3.4运行测试 + 收集指标 + 分析结果

3.4.1 低并发测试运行

3.4.2 高并发测试运行

3.4.3指标整理

低并发：

高并发：

3.4.4结果分析

本次测试针对 MariaDB 数据库的查询（Query）、插入（Insert）、更新（Update）、删除（Delete） 四类核心操作，分别在低并发（20 线程）和高并发（50 线程）场景下验证性能，核心评估维度为响应时间、错误率、吞吐量，且已修正前期 SQL 语句和 JMeter 连接配置问题，所有操作错误率归零，测试数据具备有效性。

3.4.4.1低并发场景（20 线程，总样本 1600）性能分析

1. 响应时间：处理效率极高，延迟可忽略

四类操作的平均响应时间（Average） 和中位数响应时间（Median） 均为 1ms，90% 响应时间≤4ms、95% 响应时间≤8ms，说明低并发下 MariaDB 对简单 CRUD 操作的处理几乎无延迟。

仅查询操作的最大响应时间（Max）达到 107ms，99% 响应时间为 19ms，其余操作（插入 / 更新 / 删除）最大响应时间≤14ms、99% 响应时间≤6ms；查询操作的偶发高延迟推测为首次执行时的磁盘 IO 导致（数据未加载至内存缓存），后续查询均走内存，效率极快。

2. 错误率：全场景 0%，操作完全稳定

所有操作的 Error % 均为 0.000%，验证了前期修正的 UPDATE 语句（改用 WHERE age < 25 LIMIT 1）和 JDBC 连接池名称（消除空格）生效，四类操作在低并发下无执行失败，功能层面完全可靠。

3. 吞吐量：资源充足，处理能力最大化

单操作吞吐量均达到 83~85 req/sec，整体吞吐量高达 332.23 req/sec；

该数据说明低并发下数据库的 CPU、内存、磁盘 IO 资源充足，无资源竞争，请求无需排队，能以最优效率处理。

3.4.4.2高并发场景（50 线程，总样本 7600）性能分析

1. 响应时间：延迟稳定性优秀，无明显恶化

四类操作的平均 / 中位数响应时间仍维持在 1ms，90% 响应时间≤3ms、95% 响应时间≤5ms，99% 响应时间≤13ms（查询）/7ms（插入）/6ms（更新）/5ms（删除）；

最大响应时间虽略有上升（插入 48ms、更新 30ms），但整体仍处于毫秒级，说明 MariaDB 对简单 CRUD 操作的延迟控制优秀，内存缓存机制（查询数据驻留内存）抵消了部分并发压力。

2. 错误率：0% 稳定执行，无并发异常

所有操作 Error % 仍为 0.000%，说明高并发下 MariaDB 的锁机制、事务处理能力对简单 CRUD 操作足够可靠，未出现因并发冲突（如行锁竞争）导致的 SQL 执行失败。

3. 吞吐量：资源竞争导致显著下降，成为核心瓶颈

单操作吞吐量骤降至 20.5 req/sec 左右，整体吞吐量仅 82.18 req/sec，仅为低并发场景的 24.7%；

核心原因：高并发下数据库连接池、CPU 调度、磁盘 IO 出现资源竞争，大量请求排队等待资源，导致单位时间内可处理的请求数大幅减少（而非 SQL 执行本身变慢）。

3.4.4.3 高低并发场景核心对比

3.4.4.4 核心结论

1.功能性结论：修正 SQL 语句（UPDATE 条件）和 JMeter 连接配置（消除变量名空格）后，MariaDB 的四类核心操作在高低并发下均能稳定执行，无错误，满足基础业务功能要求。

2.性能特性结论：MariaDB 对简单 CRUD 操作的响应时间稳定性极佳（低延迟），但高并发下吞吐量瓶颈显著，核心瓶颈为资源竞争（连接池、CPU/IO），而非 SQL 执行本身。

3.稳定性结论：MariaDB 的并发控制机制（锁、事务）对简单操作足够可靠，无因并发导致的执行失败，具备基础的高并发承载能力。