图像修复自动化测试：fft npainting lama API压力测试方案

图像修复自动化测试：fft npainting lama API压力测试方案

1. 引言：为什么需要API压力测试？

你有没有遇到过这种情况：本地测试时一切正常，但一上线就卡顿、崩溃、响应超时？尤其是在多人并发使用图像修复系统时，WebUI界面卡住不动，用户抱怨“怎么又失败了”？

这背后往往不是模型本身的问题，而是服务承载能力不足。我们今天要聊的这套由科哥二次开发的fft npainting lama图像修复系统，虽然在功能上已经非常完善——支持画笔标注、自动填充、边缘羽化、高质量输出，但在实际部署中，如果不对后端API进行充分的压力测试，很容易在高负载下出现性能瓶颈。

本文将带你从零构建一套完整的API压力测试方案，目标是：

• 验证系统在多用户同时请求下的稳定性
• 测量单次修复的平均响应时间与资源消耗
• 找出系统最大并发承受能力
• 提供可复用的自动化测试脚本

无论你是运维工程师、AI应用开发者，还是想把这套系统集成到自己产品中的技术负责人，都能从中获得实用价值。

2. 系统架构与测试目标

2.1 当前系统结构回顾

根据提供的用户手册，该系统的运行流程如下：

用户上传图像 → 标注mask区域 → 调用后端推理接口 → 返回修复结果 → 显示并保存

核心服务由 Python + Gradio 构建，启动命令为：

cd /root/cv_fft_inpainting_lama bash start_app.sh

默认监听http://0.0.0.0:7860，前端通过 WebUI 交互完成操作。

这意味着，所有图像修复请求最终都会转化为对 Gradio 后端的 HTTP 请求。因此，我们的压力测试可以直接绕过页面操作，模拟多个客户端并发调用API接口。

2.2 压力测试核心目标

我们将围绕这些指标设计测试策略。

3. 准备工作：提取API接口 & 构建测试环境

3.1 如何找到真实API端点？

Gradio 默认会暴露一个/api/predict/接口用于前后端通信。我们可以通过浏览器开发者工具抓包来确认。

打开 WebUI 页面，在完成一次修复后查看 Network 面板，通常会看到类似请求：

POST http://<server_ip>:7860/api/predict/ Content-Type: application/json { "data": [ "data:image/png;base64,iVBORw0KGgoAAAANSUhEUg...", "data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..." ], "event_data": null, "fn_index": 0 }

其中：

• data[0]是原始图像的 base64 编码
• data[1]是 mask 图像（白色标注区域）的 base64 编码
• fn_index: 0表示调用第一个函数（即“开始修复”按钮对应的功能）

提示：如果你无法抓包，也可以直接查看app.py源码中的gr.Interface()定义顺序。

3.2 构建测试用图像数据

我们需要准备几组不同尺寸的测试图像，以评估性能随分辨率增长的变化。

建议准备以下三类图像：

• 小图：512×512（模拟头像、图标处理）
• 中图：1024×1024（常见商品图、社交配图）
• 大图：1536×1536（高清摄影、海报级素材）

每张图生成对应的 mask：用白色涂鸦覆盖中心约 1/4 区域，模拟典型去水印或删物体场景。

然后将它们转为 base64 字符串，便于在 JSON 请求中传输。

3.3 安装测试依赖库

在任意一台能访问服务器的机器上安装：

pip install requests locust matplotlib

• requests：用于编写简单脚本发起请求
• locust：轻量级压力测试框架，支持可视化监控
• matplotlib：后续绘制性能曲线图

4. 编写自动化测试脚本

4.1 基础请求脚本（test_inpaint.py）

import requests import base64 import time import json # 配置 SERVER_URL = "http://your_server_ip:7860/api/predict/" IMAGE_PATH = "test_512.png" MASK_PATH = "mask_512.png" def load_image_as_base64(image_path): with open(image_path, "rb") as f: return base64.b64encode(f.read()).decode('utf-8') def call_inpaint_api(image_b64, mask_b64): payload = { "data": [ f"data:image/png;base64,{image_b64}", f"data:image/png;base64,{mask_b64}" ], "event_data": None, "fn_index": 0 } headers = {'Content-Type': 'application/json'} start_time = time.time() try: response = requests.post(SERVER_URL, data=json.dumps(payload), headers=headers, timeout=60) end_time = time.time() if response.status_code == 200: result = response.json() output_image_b64 = result["data"][0].split(",")[1] print(f"✅ 成功修复，耗时: {end_time - start_time:.2f}s") return True, end_time - start_time else: print(f"❌ 请求失败，状态码: {response.status_code}") return False, None except Exception as e: print(f"⚠️ 请求异常: {str(e)}") return False, None if __name__ == "__main__": img_b64 = load_image_as_base64(IMAGE_PATH) mask_b64 = load_image_as_base64(MASK_PATH) call_inpaint_api(img_b64, mask_b64)

运行此脚本可验证单次调用是否成功，并记录响应时间。

4.2 使用Locust构建并发压测

创建文件locustfile.py：

from locust import HttpUser, task, between import base64 import json # 全局加载图像数据 with open("test_1024.png", "rb") as f: IMAGE_B64 = base64.b64encode(f.read()).decode('utf-8') with open("mask_1024.png", "rb") as f: MASK_B64 = base64.b64encode(f.read()).decode('utf-8') class InpaintingUser(HttpUser): wait_time = between(1, 3) # 用户间隔1~3秒发起请求 @task def repair_image(self): payload = { "data": [ f"data:image/png;base64,{IMAGE_B64}", f"data:image/png;base64,{MASK_B64}" ], "event_data": None, "fn_index": 0 } headers = {"Content-Type": "application/json"} with self.client.post("/api/predict/", json=payload, catch_response=True) as resp: if resp.status_code != 200: resp.failure(f"返回状态码: {resp.status_code}") elif "error" in resp.text: resp.failure("响应包含错误信息")

启动 Locust 测试：

locust -f locustfile.py --host http://your_server_ip:7860

访问http://localhost:8089，设置：

• 用户数：10
• 每秒启动用户数：2
• 运行5分钟观察趋势

5. 压力测试执行与数据分析

5.1 测试场景设计

每个场景运行5分钟，记录：

• 平均响应时间
• 请求成功率
• RPS（每秒请求数）
• 服务器资源占用（top/nvidia-smi）

5.2 实测数据汇总（示例）

注：测试环境为 NVIDIA T4（16GB显存），CPU Intel Xeon 8核，RAM 32GB

5.3 关键发现

1. 响应时间呈非线性增长
   分辨率翻倍，处理时间超过两倍，说明模型推理存在平方级以上复杂度。

2. 并发超过10后错误率上升明显
   主要原因为 CUDA Out of Memory，部分请求因排队超时被丢弃。

3. Gradio自带队列机制缓解了瞬时冲击
   即使并发激增，服务未崩溃，体现了其一定的容错能力。

4. 小图适合高频调用，大图建议限流
   对于 >1200px 的图像，建议限制同时处理不超过5个任务。

6. 性能优化建议

6.1 服务端调优

python app.py --server_port 7860 --queue --max_size 20 --enable_cors

6.2 前端/调度层建议

• 添加任务队列中间件（如 Redis + Celery），实现异步处理
• 对大图请求添加优先级标签，避免阻塞小图快速响应
• 在客户端增加“正在排队”提示，提升用户体验
• 实现自动降级：当负载过高时，拒绝超大图像请求

6.3 硬件扩展方向

• 升级至 A10/A100 显卡，显存更大，支持更多并发
• 使用 TensorRT 加速推理（需对模型做量化封装）
• 多实例部署 + Nginx 负载均衡，横向扩展服务能力

7. 自动化监控脚本建议

可以编写一个守护脚本，定期发送探测请求，判断服务健康状态：

import requests import logging from datetime import datetime HEALTH_CHECK_URL = "http://localhost:7860/health" TEST_IMAGE_B64 = "..." # 预存小图base64 def health_check(): try: resp = requests.get("http://localhost:7860") if resp.status_code != 200: log_error("WebUI不可达") return # 发起一次快速测试 success, rt = call_inpaint_api(TEST_IMAGE_B64, TEST_IMAGE_B64) # 自覆盖作为mask if not success: log_error("API调用失败") else: logging.info(f"健康检查通过，响应时间: {rt:.2f}s") except Exception as e: log_error(f"检查异常: {e}") def log_error(msg): now = datetime.now().strftime("%Y-%m-%d %H:%M:%S") print(f"[{now}] ERROR: {msg}")

配合 cron 每5分钟执行一次：

*/5 * * * * python /root/health_check.py >> /var/log/inpaint_health.log 2>&1

8. 总结

通过本次对fft npainting lama图像修复系统的API压力测试，我们完成了从接口分析、脚本编写、并发测试到性能优化的完整闭环。关键结论如下：

1. 系统具备基本的生产可用性，在中小并发下表现稳定。
2. 大图处理是性能瓶颈，需结合硬件升级与任务调度优化。
3. Gradio框架提供了良好的基础支撑，但高并发场景仍需额外架构设计。
4. 自动化测试不可或缺，能提前暴露潜在风险，避免线上事故。

未来若要将其应用于电商批量去水印、内容审核自动修图等工业级场景，建议引入更专业的任务队列系统，并考虑将核心推理模块拆分为独立微服务，进一步提升灵活性与可维护性。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。