1. 项目概述与背景最近在折腾一个叫daily_stock_analysis的项目简单说它是一个基于AI的股票智能分析系统能自动抓取数据、做技术指标计算、生成买卖信号甚至还能写个简单的分析报告。项目本身用Docker打包成了镜像方便部署。东西做出来了功能跑通只是第一步真正要上线给用户用尤其是可能有多人同时访问的场景稳定性就成了头等大事。你总不想用户一多系统就直接卡死或者崩掉吧所以就有了这次压力测试模拟10个用户并发、持续不断地请求这个镜像的核心分析功能看看它到底扛不扛得住。这活儿听起来简单不就是找10个人模拟的同时点按钮嘛。但真干起来里头的门道可多了。比如这10个“用户”的行为模式是啥是同时发起请求然后立刻结束还是像真实用户一样有思考、有间隔地持续操作系统在压力下的响应时间变化曲线是怎样的内存会不会泄漏CPU会不会被打满数据库连接池够不够用这些都是“稳定性”这个笼统词汇背后需要一个个抠出来的具体问题。这次测试的目标就是通过模拟一个中小规模的并发场景把daily_stock_analysis镜像在持续负载下的真实状态给“逼”出来找到潜在的瓶颈和风险点为后续的优化和扩容提供硬核数据支撑。2. 测试环境与工具选型工欲善其事必先利其器。压力测试不是蛮干得有一套靠谱的环境和工具。2.1 被测系统环境首先看我们的“靶子”——daily_stock_analysis镜像。根据项目惯例它很可能是一个包含了Web服务比如Flask或FastAPI、数据分析库Pandas, NumPy、机器学习库可能用到scikit-learn或TA-Lib做指标计算以及数据库客户端连接MySQL或PostgreSQL的复合体。测试前我们将其部署在一台独立的服务器上。服务器配置4核CPU8GB内存50GB SSD硬盘。这个配置模拟的是一个中等偏下的云服务器实例更能暴露资源紧张时的问题。部署方式使用docker-compose up -d启动确保所有依赖服务如数据库、Redis缓存等也一并启动。通过docker stats命令实时监控容器本身的资源消耗。网络隔离测试机与被测服务器部署在同一内网排除公网带宽和延迟的干扰让测试结果更聚焦于应用本身的性能。2.2 压力测试工具选型工具方面JMeter是行业标准功能强大且免费但图形化界面在持续测试和资源消耗上有点重。考虑到我们测试场景相对固定模拟API并发请求我选择了ApacheBench和wrk作为主力辅以自定义Python脚本进行更复杂的场景模拟和结果收集。ApacheBench简单粗暴适合快速发起固定URL的并发请求。命令如ab -n 1000 -c 10 http://your-api/analyze就能发起1000次请求并发数为10。它的输出能直接给出每秒请求数、平均响应时间等关键指标非常适合做基准测试和快速验证。wrk性能更高支持使用Lua脚本定制复杂的测试逻辑。比如我们可以写一个Lua脚本让每个虚拟用户先登录获取token然后再用这个token去调用股票分析接口更贴近真实业务流。它的性能损耗比JMeter小很多能更好地压榨出服务器的极限。自定义Python脚本当需要模拟更复杂、有状态、带业务逻辑如不同用户查询不同股票代码的并发场景时用asyncio或concurrent.futures库写个脚本就非常灵活。它能方便地集成到我们的CI/CD流程中并且可以详细记录每个请求的上下文和响应内容便于后续分析。注意工具本身也会消耗资源。务必确保运行压力测试的机器测试机本身性能足够最好CPU和内存资源充裕并且监控测试机自身的资源使用情况避免测试机先成为瓶颈导致结果失真。我通常会把测试工具也放在一个独立的容器里运行方便资源隔离和管理。2.3 监控体系搭建只压测不监控等于盲人摸象。我们需要一套监控系统在测试过程中全方位地收集数据。系统层面使用top、htop、vmstat、iostat等命令实时观察服务器的CPU使用率、内存占用、磁盘I/O、网络流量。特别是vmstat它能告诉我们进程是卡在CPU上还是I/O上。容器层面docker stats命令可以持续输出容器的CPU、内存、网络I/O、块I/O使用情况。应用层面这是关键。需要在daily_stock_analysis的应用代码中植入或开启性能监控。日志确保应用日志级别足够能记录每个请求的入口、出口、耗时、关键步骤耗时如数据获取、指标计算、AI推理。使用结构化日志如JSON格式方便后续用ELK等工具分析。内省端点如果框架支持如Flask有flask-profiler可以添加一个监控端点实时查看视图函数耗时、数据库查询次数等。APM工具条件允许的话集成像Py-Spy性能分析器或简单的Prometheus客户端暴露应用内部的度量指标如请求计数器、直方图。数据库层面监控数据库连接数、慢查询日志、锁等待情况。对于MySQL可以开启slow_query_log并使用SHOW PROCESSLIST命令实时查看当前连接和执行中的查询。3. 测试场景设计与实施压力测试不是拿大锤乱砸需要有精心设计的场景模拟真实用户行为。3.1 核心分析接口压测这是最直接的测试。假设我们的核心接口是POST /api/stock/analyze接收股票代码和日期范围返回分析结果。脚本设计使用wrk配合Lua脚本。脚本内容会从预设的股票代码列表如[‘000001.SZ’ ‘600519.SH’]中随机选取一个构造请求体。请求头中设置合理的Content-Type: application/json。-- wrk 压力测试脚本示例 (analyze.lua) request function() local codes {“000001.SZ”, “600519.SH”, “000858.SZ”} local code codes[math.random(#codes)] local body string.format(‘{“symbol”: “%s”, “start_date”: “2023-01-01”, “end_date”: “2023-12-31”}’, code) local headers {} headers[“Content-Type”] “application/json” return wrk.format(“POST”, “/api/stock/analyze”, headers, body) end执行命令wrk -t10 -c10 -d300s –timeout 2s –scriptanalyze.lua http://your-server:port-t10使用10个线程。-c10保持10个HTTP连接模拟10个并发用户。-d300s持续测试300秒5分钟这是“持续分析稳定性”的关键看长期负载下的表现。–timeout 2s设置2秒超时超过则认为请求失败。这个命令会模拟10个用户在5分钟内不停地、随机地请求分析不同股票。3.2 混合场景稳定性验证真实用户不会只调用一个接口。他们可能先登录再查看列表最后进行分析。因此设计一个混合场景更能反映真实压力。登录POST /api/login(低频每个虚拟用户只在开始时登录一次获取token)。查询股票列表GET /api/stock/list(中频模拟用户浏览)。执行深度分析POST /api/stock/analyze/deep(高频这是我们的压测重点但加入思考时间)。实施这个场景用ApacheBench或wrk单独模拟比较困难。我采用自定义Python脚本使用concurrent.futures.ThreadPoolExecutor创建10个线程模拟10个用户。每个线程的执行逻辑如下import time, random, requests def user_simulation(user_id): # 1. 登录 session requests.Session() login_resp session.post(‘http://your-server/login‘, json{‘user’: f‘test_{user_id}‘, ‘pwd’: ‘xxx’}) token login_resp.json().get(‘token’) session.headers.update({‘Authorization’: f‘Bearer {token}‘}) # 2. 持续行为模拟 for _ in range(50): # 每个用户执行50轮操作 # 随机间隔模拟用户思考时间 time.sleep(random.uniform(0.5, 2.0)) # 偶尔查询列表 if random.random() 0.3: session.get(‘http://your-server/api/stock/list‘) time.sleep(0.2) # 核心分析操作 stock_code random.choice([‘000001.SZ‘, ‘600519.SH‘]) start_time time.time() try: resp session.post(‘http://your-server/api/stock/analyze/deep‘, json{‘symbol’: stock_code}, timeout5) resp.raise_for_status() latency (time.time() - start_time) * 1000 # 毫秒 # 记录延迟、状态码等信息 record_metric(user_id, latency, resp.status_code) except Exception as e: record_error(user_id, str(e))这个脚本能更真实地模拟用户行为并且可以详细记录每个请求的耗时和成功与否。3.3 测试数据准备与预热压力测试要用到数据。如果测试时现场去抓取实时数据会引入网络延迟这个不可控变量。所以数据预热至关重要。做法在测试开始前先让系统运行一段时间把可能用到的股票历史数据缓存到数据库或Redis中。对于daily_stock_analysis项目可以提前调用数据抓取模块将测试涉及到的股票代码如沪深300成分股最近一年的数据全部入库。缓存预热如果系统使用了Redis缓存计算结果也在测试前预先跑一遍核心分析逻辑让热点数据进入缓存。这样压力测试更多地是考验应用的计算和IO处理能力而不是外部数据源的获取速度。数据库索引检查确保查询相关的表都已建立正确的索引避免压力测试变成数据库全表扫描的灾难。4. 关键指标与结果分析压测过程中我们像看仪表盘一样紧盯一系列关键指标。这些指标分为两类性能指标和资源指标。4.1 性能指标解读性能指标直接反映了用户体验和系统处理能力。指标描述本次测试观察目标结果示例与分析吞吐量系统每秒处理的请求数。在10并发下是否能保持相对稳定的吞吐量。初始阶段 120 req/s运行2分钟后降至 85 req/s 并保持。说明系统经过初始波动后达到稳定状态但吞吐量有下降可能存在资源竞争。平均响应时间所有请求的平均耗时。是否在可接受范围内如1秒且随着测试进行不会线性增长。平均响应时间从 200ms 逐渐增长到 450ms 后稳定。增长后稳定表明系统在压力下达到新的平衡点但延迟增加了。响应时间百分位数如P95P99。表示95%或99%的请求响应时间低于该值。P99是否过高这决定了长尾请求的体验。P95: 800ms, P99: 1.5s。有1%的请求非常慢需要排查是哪些请求导致的是否是某个复杂股票的分析。错误率失败请求数 / 总请求数。在持续压力下错误率应接近0%。任何非零错误都需要深究。错误率 0.05%。经查均为超时错误2秒超时。结合P99数据说明有少量请求处理时间过长。并发用户数同时活跃的用户数。我们固定为10观察系统在该并发下的表现。保持10并发用于观察固定负载下的系统行为。实操心得只看平均值会掩盖很多问题。P95和P99响应时间、错误率这两个指标往往比平均响应时间和吞吐量更能揭示系统的健康度。一个P99很高的系统即使平均值很好看也会让那1%的用户抓狂。4.2 资源消耗监控分析资源指标告诉我们系统“累不累”瓶颈在哪里。CPU使用率通过top命令观察。理想情况是CPU使用率较高表明计算资源被充分利用但不会持续100%。如果某个核心持续100%可能是单线程任务或GIL锁Python成为瓶颈。在我们的测试中发现4个核心平均使用率在70%-85%之间波动说明计算任务被相对均匀地分配没有完全打满但压力不小。内存使用量使用docker stats和free -m监控。重点关注内存使用量是否随时间推移而持续增长内存泄漏。本次测试中容器内存从初始的800MB在5分钟测试后增长到1.2GB之后趋于稳定。这个增长是正常的因为Python进程和缓存会占用更多内存但稳定后不再增长说明没有明显的内存泄漏。磁盘I/O使用iostat -x 1查看。%util表示设备繁忙程度。如果持续接近100%说明磁盘读写是瓶颈。我们的应用主要是计算和数据库查询磁盘I/O很低%util基本在5%以下。网络I/O压力测试下网络流量会增大但内网通常不是瓶颈。主要观察是否有大量的重传或错误包。数据库连接数这是关键中的关键通过数据库监控发现连接数从平时的5个迅速增长到30个最大连接数设置为50。检查应用代码发现每个请求都新建数据库连接没有使用连接池这导致了巨大的开销。这就是本次压测发现的最核心问题。5. 暴露的问题与优化实践压测的目的就是发现问题。这次10并发持续压测虽然规模不大但确实揪出了几个典型问题。5.1 数据库连接池缺失问题现象数据库连接数飙升接近最大限制。应用日志中频繁出现获取数据库连接缓慢或超时的警告。根因分析在daily_stock_analysis的Web服务代码中每次处理分析请求时都在视图函数内部直接创建新的数据库连接用完后关闭。在高并发下频繁创建和销毁连接消耗巨大且容易达到数据库的最大连接数限制。解决方案引入数据库连接池。对于SQLAlchemy在创建引擎时设置pool_size和max_overflow参数。from sqlalchemy import create_engine engine create_engine(‘mysqlpymysql://user:passhost/db‘, pool_size10, # 连接池保持的连接数 max_overflow5, # 允许超过pool_size的最大连接数 pool_recycle3600) # 连接自动回收时间秒对于直接使用DB-API可以使用DBUtils或PyMySQL自带的连接池功能。优化后效果再次压测数据库连接数稳定在15个左右pool_size 少量溢出连接创建/销毁的消耗几乎为零平均响应时间下降了约30%。5.2 同步阻塞与GIL限制问题现象CPU使用率虽然高但4个核心并未完全均衡满载有时单个核心负载很高。同时当并发请求处理计算密集型任务如计算复杂技术指标时响应时间波动很大。根因分析项目使用的是同步Web框架如Flask和同步数据库驱动。Python的全局解释器锁GIL导致即使在多线程环境下CPU密集型计算也无法有效利用多核。一个线程在进行复杂计算时会阻塞其他线程。解决方案采用异步架构或进程池。短期优化代码改动小使用concurrent.futures.ProcessPoolExecutor将CPU密集型的计算任务如Pandas数据计算、指标生成提交到单独的进程池中执行避免阻塞主线程和GIL限制。Web线程只负责接收请求和返回结果。from concurrent.futures import ProcessPoolExecutor import asyncio # 创建进程池不宜过大通常等于CPU核心数 compute_executor ProcessPoolExecutor(max_workers4) async def analyze_stock(symbol): loop asyncio.get_event_loop() # 将CPU密集型函数扔到进程池运行 result await loop.run_in_executor(compute_executor, cpu_intensive_analysis, symbol) return result长期架构升级考虑将Web框架迁移到异步框架如FastAPI或Sanic并使用异步数据库驱动如asyncpg、aiomysql。这能从根本上提升I/O并发能力更好地利用系统资源。5.3 缓存策略不足问题现象对于同一支股票、同一时间范围的重复分析请求响应时间没有显著差异CPU每次都在进行相同的计算。根因分析系统没有对计算结果进行有效缓存。很多用户可能都在查询热门的几只股票如茅台、宁德时代重复计算浪费资源。解决方案引入多级缓存。请求级缓存对于完全相同的请求参数可以在内存中使用functools.lru_cache进行短期缓存例如缓存5分钟。适用于单实例部署。from functools import lru_cache lru_cache(maxsize128) def analyze_stock_cached(symbol, start_date, end_date): # 原有的分析逻辑 return result分布式缓存使用Redis作为共享缓存。将分析结果序列化如用JSON或MessagePack后存入Redis并设置合理的过期时间如30分钟。这样即使有多个应用实例也能共享缓存。import redis import json r redis.Redis(host‘localhost‘, port6379, db0) cache_key f“analysis:{symbol}:{start_date}:{end_date}” result r.get(cache_key) if result: return json.loads(result) else: result compute_analysis(symbol, start_date, end_date) r.setex(cache_key, 1800, json.dumps(result)) # 缓存30分钟 return result引入缓存后对于重复请求的响应时间可以降低90%以上极大减轻数据库和计算压力。6. 稳定性验证总结与后续规划经过一轮“折腾”这个10并发的持续压力测试给了我们一个清晰的系统画像。daily_stock_analysis镜像在基础功能上是稳定的没有在持续负载下崩溃但在资源利用和架构设计上存在明显的优化空间。数据库连接池的缺失是首要性能杀手同步阻塞模型限制了其并发上限而缓存机制的缺乏则导致了不必要的资源浪费。优化不是一蹴而就的。根据本次测试结果我建议的后续步骤是立即实施优先解决数据库连接池问题这是投入产出比最高的优化。然后引入请求级内存缓存快速缓解重复计算压力。中期规划将CPU密集型任务进行进程池隔离并引入Redis作为分布式缓存。同时建立常态化的性能测试流程将压力测试集成到CI/CD中每次重大更新后都自动运行防止性能回退。长期演进评估业务增长如果并发需求持续增加需要考虑向异步架构FastAPI迁移甚至将分析这类重计算任务拆分为独立的微服务通过消息队列进行异步处理实现真正的水平扩展。压力测试就像给系统做一次全面的“体检”目的不是证明它有多强而是发现它的“亚健康”状态。这次10并发的测试只是一个开始随着用户量的增长我们还需要设计50并发、100并发甚至更高的测试场景持续地验证和优化系统的稳定性。记住没有经过压力测试的系统就像没上过战场的士兵真正的能力如何永远是个未知数。
