数字档案馆系统响应速度多场景实测对比及性能调优实操指南

一、测试前准备工作

所有对比测试必须在统一环境下执行，避免环境差异导致结果失真，以下是标准测试环境配置：

• 硬件：Intel Xeon E5-2678 v32、32G DDR4内存、1T SSD固态硬盘
• 软件：CentOS 7.9 2009操作系统、JDK 1.8.0_341、MySQL 8.0.32、Nginx 1.24.0
• 网络：内网千兆环境，排除公网波动干扰

测试工具下载安装

所有工具直接复制地址下载即可，无需自行查找：

• 压测工具JMeter 5.5：https://dlcdn.apache.org//jmeter/binaries/apache-jmeter-5.5.tgz，解压即可使用
• 链路追踪工具SkyWalking 9.4.0：https://archive.apache.org/dist/skywalking/9.4.0/apache-skywalking-apm-9.4.0.tar.gz，解压后执行bin/startup.sh启动
• 前端性能分析直接用Chrome浏览器自带DevTools（按F12调出）

二、多场景响应速度对比测试步骤

1. 单用户档案查询场景测试

该场景模拟普通用户日常查档操作，测试单用户下的基础响应速度：

• 步骤1：提前向被测系统导入100万条标准档案元数据，确保数据量和生产环境一致
• 步骤2：打开Chrome浏览器，按F12调出DevTools，切换到Network面板，勾选「Disable cache」禁用缓存
• 步骤3：输入随机档案号执行查询，重复操作10次，去掉最高、最低响应时间后取平均值
• 参考对比值：自研原生系统120-200ms、开源框架二次开发系统300-500ms、商用成品系统80-150ms

2. 50并发档案上传场景测试

该场景模拟批量档案入库操作，测试高并发下的系统负载能力：

• 步骤1：打开JMeter，新建线程组，设置线程数50、Ramp-Up时间10s、循环次数10次
• 步骤2：新增HTTP请求，配置上传接口地址，请求体附加10MB标准PDF电子档案文件
• 步骤3：添加「聚合报告」监听器，启动压测，记录平均响应时间、95分位响应时间、错误率三项核心指标
• 参考对比值：自研系统平均1.2s/95分位2.3s、开源二次开发系统平均2.8s/95分位4.7s、商用成品系统平均0.8s/95分位1.5s

3. 全库模糊检索场景测试

该场景模拟跨类目档案检索操作，测试检索模块的性能：

• 步骤1：输入无精准索引的检索关键词（如「2023年工程合同」），执行全库检索
• 步骤2：记录从点击检索按钮到结果列表全部渲染完成的总时长，重复5次取平均值
• 参考对比值：带ES检索的系统200-400ms、仅用MySQL模糊查询的系统2-3s

三、响应慢根因定位实操

1. 前端耗时排查

打开DevTools的Network面板，查看请求Timing信息：

• 如果Queueing/Stalled时长超过50ms，说明是浏览器并发限制或Nginx限流导致
• 如果TTFB（首字节时间）超过200ms，说明是后端服务耗时高，需排查后端链路

2. 后端耗时排查

• 数据库慢查询排查：登录MySQL执行命令开启慢查询日志：
  SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1;
  执行查询查看慢日志：SELECT FROM mysql.slow_log;，即可找到执行时间超过1s的慢SQL
• Java应用耗时排查：执行jstack [应用进程ID] > stack.log抓线程栈，查看是否有锁等待；执行jstat -gcutil [应用进程ID] 1000 10查看GC情况，若YGC频率超过10次/秒说明堆内存不足

四、性能优化落地实操

1. 前端优化

直接修改Nginx配置文件（nginx.conf），添加以下配置即可生效：

``` 开启gzip压缩 gzip on; gzip_vary on; gzip_min_length 1024; gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml+rss application/javascript application/json; 静态资源设置30天缓存 location ~ \.(js|css|png|jpg|gif)$ { expires 30d; add_header Cache-Control "public, no-transform"; } ```

2. 后端优化

• 热点数据缓存：将高频查询的档案数据存入Redis，过期时间设为1小时，Java代码可直接复用： ```java // 优先查缓存 String archiveKey = "archive:" + archiveNo; Archive archive = redisTemplate.opsForValue().get(archiveKey); if (archive == null) { // 缓存未命中查数据库 archive = archiveMapper.selectByArchiveNo(archiveNo); // 写入缓存 redisTemplate.opsForValue().set(archiveKey, archive, 3600, TimeUnit.SECONDS); } return archive; ```
• 慢SQL优化：给常用查询字段加索引，示例命令：CREATE INDEX idx_archive_no ON t_archive(archive_no);，优化后单SQL查询耗时可降低90%以上
• 内存优化：启动应用时调整堆内存参数，建议分配物理内存的50%给Java应用：java -Xms16G -Xmx16G -Xmn8G -jar archive-system.jar

3. 检索优化

全库检索不要用MySQL的like模糊查询，改用Elasticsearch 7.17.0，用Logstash同步MySQL数据到ES，配置文件可直接复制：

``` input { jdbc { jdbc_connection_string => "jdbc:mysql://localhost:3306/archive_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai" jdbc_user => "root" jdbc_password => "替换为你的数据库密码" jdbc_driver_library => "/opt/mysql-connector-java-8.0.32.jar" jdbc_driver_class => "com.mysql.cj.jdbc.Driver" statement => "SELECT id, archive_no, title, content, create_time FROM t_archive" schedule => "0 " 每小时同步一次 } } output { elasticsearch { hosts => ["http://localhost:9200"] index => "archive" document_id => "%{id}" } } ```

配置完成后执行logstash -f mysql-to-es.conf启动同步即可，检索耗时可从秒级降到毫秒级。

五、优化效果验证

优化完成后重新执行本文第二部分的三个测试场景，和优化前的结果做对比：

• 单用户查询响应时间降到100ms以内、50并发上传95分位响应时间降到2s以内、全库检索响应时间降到300ms以内，说明优化达标
• 若某场景未达标，回到第三部分重新排查对应模块的耗时点即可