# 政务系统压力测试实战——人脸识别离线版并发性能摸底

政务系统压力测试实战------人脸识别离线版并发性能摸底

背景

2022年，给一个政务系统做人脸识别对接。人脸识别用离线版（部署在本地服务器，不走外网），主要担心的是：高并发下接口能不能扛住。

场景：政务大厅办事窗口集中上班时，多个窗口同时刷脸。极端情况下可能有几十个并发请求。

测试目标

单接口响应时间：单次人脸识别API调用耗时
并发能力：同时N个请求时，响应时间和成功率
Tomcat线程瓶颈：Tomcat默认线程数够不够用
长时间稳定性：持续1小时高负载，有没有内存泄漏或响应退化

测试工具

没买商业压测工具，用的是Apache JMeter------免费、够用。

JMeter基本配置

线程组：设置并发用户数和循环次数

参数	值	说明
线程数（用户数）	10、30、50、100	分多轮测试
Ramp-Up时间	10秒	10秒内启动所有线程
循环次数	100	每个线程执行100次

HTTP请求：配置人脸识别API接口

参数	值
协议	http
服务器	离线人脸识别服务器IP
端口	8080
方法	POST
Body	JSON格式的人脸图片base64

监听器：

聚合报告：看平均响应时间、90%线、99%线、错误率
View Results Tree：看每个请求的详细结果（调试用，正式测试关掉）
Response Times Over Time：看响应时间随时间的变化趋势

测试过程

第一轮：单用户基准测试

线程数=1，循环100次。

目的：排除网络和接口本身的问题，获取单次调用的基准耗时。

结果：

平均响应时间：850ms
90%线：920ms
错误率：0%
结论：单次调用<1秒，可接受

第二轮：10并发

线程数=10，循环100次。

结果：

平均响应时间：1.2s
90%线：1.8s
99%线：2.5s
错误率：0%
结论：10并发响应时间略有上升，但还在可接受范围

第三轮：30并发

线程数=30，循环100次。

结果：

平均响应时间：2.1s
90%线：3.5s
99%线：5.2s
错误率：0%
结论：30并发开始有明显延迟，但无错误

第四轮：50并发

线程数=50，循环100次。

结果：

平均响应时间：3.8s
90%线：6.2s
99%线：9.1s
错误率：2.3%（部分请求超时）
结论：50并发出现超时错误，响应时间过长

第五轮：100并发

线程数=100，循环100次。

结果：

平均响应时间：8.5s
90%线：15s
99%线：30s+
错误率：15.6%
结论：100并发严重超时，不可接受

Tomcat线程限制分析

50并发就出现问题，怀疑是Tomcat线程池不够用。

Tomcat默认的线程配置（server.xml）：

xml 复制代码

<Connector port="8080" protocol="HTTP/1.1"
           maxThreads="200"
           minSpareThreads="25"
           connectionTimeout="20000" />

默认maxThreads=200看起来够用，但这里的问题不在Tomcat，在人脸识别服务本身。人脸识别是CPU密集型操作，服务端处理一张人脸图片要几百毫秒，线程再多也受限于CPU。

真正的瓶颈分析：

瓶颈	表现	判断依据
Tomcat线程不够	请求排队，connectionTimeout超时	查看Tomcat的thread dump，看线程都在干什么
人脸识别服务CPU满	响应时间随并发线性增长	用top看CPU使用率
网络带宽	传输大图片（base64）慢	单次调用耗时主要在传输上

我们的情况：人脸识别服务CPU是瓶颈。4核服务器跑人脸识别推理，同时处理50个请求时CPU已经90%+。

应对方案

短期：加队列

对于政务大厅的场景，同时50人刷脸的概率很低。加一个排队机制：

复制代码

用户刷脸 → 前端检查当前排队人数 → 超过10人提示"请稍候" → 前端轮询等待

不用后端改任何东西，前端控制并发量就行。

中期：调优Tomcat线程池

虽然瓶颈不在Tomcat，但合理配置线程池可以避免不必要的线程切换开销：

xml 复制代码

<Connector port="8080" protocol="HTTP/1.1"
           maxThreads="100"
           minSpareThreads="10"
           maxQueueSize="50"
           acceptCount="50"
           connectionTimeout="30000" />

参数	说明	设置依据
maxThreads	最大处理线程	设为CPU核心数的2_{4倍（4核→16}32），太多了反而增加线程切换开销
minSpareThreads	最小空闲线程	保持一定空闲线程，避免突发请求时创建线程的延迟
acceptCount	等待队列长度	超出maxThreads的请求排队等待，满了就拒绝
connectionTimeout	连接超时	人脸识别慢，适当调大

注意：Tomcat 7默认没有maxQueueSize参数（这是Tomcat 8+的），7里用acceptCount控制。

长期：人脸识别服务扩容

如果业务量确实大，给人脸识别服务加机器，用Nginx做负载均衡：

复制代码

Nginx → 人脸识别服务1（4核）
      → 人脸识别服务2（4核）
      → 人脸识别服务3（4核）

3台4核机器，理论上可以扛3倍的并发量。

稳定性测试

除了压力测试，还做了1小时的稳定性测试：

线程数=20（模拟正常业务高峰）
循环=持续1小时

结果：

平均响应时间：1.8s（全程稳定，没有随时间增长）
内存使用：稳定，没有持续增长
错误率：0%
结论：在合理并发范围内，系统稳定运行无问题

压测方法论总结

复制代码

1. 先单用户基准测试------确认接口本身没问题
2. 逐步加并发（10→30→50→100）------找到拐点
3. 在拐点处分析瓶颈------是线程不够、CPU不够、还是网络不够
4. 针对性优化------调线程池、加队列、加机器
5. 稳定性测试------跑1小时以上，排除内存泄漏

不要一上来就100并发------先摸底再加压，才知道瓶颈在哪。

总结

政务系统的压力测试，关键不在工具多高级，在于方法对不对：

从低到高逐步加压，找到性能拐点
在拐点处分析瓶颈，不要猜
针对性优化，不要盲目调参
稳定性测试不能少，跑1小时看有没有退化

人脸识别并发能力有限是正常的（CPU密集型），不是所有的"慢"都要靠"加机器"解决。有时候前端加个排队提示就够了。

感谢豆包、智谱、OpenCode在写作过程中的辅助。