宝软数字 · 产品深度解读 · 2025-09-02
性能数据不能靠猜测。一个声称"高并发"的AI平台，如果没有经过系统化的压力测试来验证，那只是一句口号。本文是EIOS的正式压力测试报告——记录了从100并发到1000并发的递增压力测试全过程：测试方案设计、JMeter脚本架构、模拟真实用户行为的测试场景、每一轮测试的详细数据（延迟、吞吐量、错误率、资源利用率），以及测试中发现的瓶颈和优化措施。所有数据都是真实测试结果，未经修饰。我们相信，坦诚的压测报告比华丽的性能承诺更有说服力。
压测最重要的原则是：模拟真实用户行为，而不是简单地对一个健康检查端点发请求。对/health端点压到10000 QPS毫无意义——真实的AI平台用户不会不停地检查健康状态。我们的压测方案模拟了完整的Agent对话流程，包含四个阶段。
第一阶段：用户认证（占总请求的2%）。模拟用户登录，获取JWT Access Token和Refresh Token。这个阶段的负载较轻，但它是后续所有请求的前提——如果认证服务在高压下崩溃，整个系统不可用。
第二阶段：Agent对话初始化（占总请求的5%）。模拟用户开始一段新对话——选择Agent类型、加载知识库上下文、建立SSE连接。这个阶段涉及数据库查询、权限验证、会话创建，是一个中等复杂度的请求。
第三阶段：Agent推理对话（占总请求的80%）。这是压测的核心——模拟用户向Agent提问并接收流式响应。每次对话包含多个步骤：用户输入向量化、向量检索（pgvector HNSW）、上下文构建、LLM推理（调用外部LLM API或本地模型）、流式输出。每次模拟对话的Token长度随机分布在200-3000 Token之间（模拟简单问题和复杂分析的不同场景），每次对话中包含0-2次工具调用（模拟Agent使用工具的场景）。
第四阶段：管理后台操作（占总请求的13%）。模拟管理员用户的后台操作——查看对话历史、管理知识库文档、配置Agent参数。这些操作的延迟要求相对宽松（不需要流式实时响应），但涉及更复杂的数据库查询。
压测使用Apache JMeter 5.6，测试脚本部署在独立的压测服务器上（与生产环境在同一数据中心，网络延迟<1ms，以排除网络因素）。每个测试级别（100/200/500/750/1000并发）持续运行30分钟，其中前5分钟为预热阶段（数据不纳入统计），后25分钟为正式测试阶段。
压测环境配置：压测在预生产环境（Staging）中进行，环境规格与生产环境完全一致：NestJS API服务 ×4 Pod（每个2核4GB），PostgreSQL主实例（4核16GB），Neo4j单实例（4核8GB），Redis单实例（2核4GB），LLM推理服务通过API调用外部模型（模拟生产环境的模型调用延迟，通过Mock Server注入符合真实分布的延迟）。
100并发是中等规模企业客户的典型负载——大约200-500名员工的公司，在一定时间窗口内同时使用AI助手的场景。100并发是压测的第一个级别，也作为后续比较的基线。
在100并发下，系统表现稳定且亮眼：Agent推理请求的P50延迟为320ms，P95延迟为780ms，P99延迟为1,150ms。SSE流式传输的首Token时间（TTFT）P50为210ms。整个30分钟测试期间，系统处理了约42,000次完整的Agent对话请求，错误率为0%。PostgreSQL的CPU使用率约25%，连接数约40（连接池最大100），查询P50延迟为2.8ms。Neo4j的CPU使用率约15%，查询P50延迟为1.5ms。Redis的内存使用约1.2GB，命中率99.7%。NestJS服务的每个Pod的CPU使用率约35-45%，内存使用约600-800MB，事件循环延迟（event loop lag）P99约8ms。
这个级别的测试没有暴露出任何问题——系统轻松应对，各项指标都有充足的余量。唯一的发现是：在100并发下，LLM推理服务的调用延迟是端到端延迟的最大贡献者（约占65%），其次是向量检索（约15%），网络和其他开销（约20%）。这说明在低负载下，优化重心应该是LLM推理的效率而非基础设施。
为什么P50和P95差距较大：320ms的P50和780ms的P95之间差距明显，主要原因是Agent对话的复杂度分布不均——简单的问候（"你好"）可能只需200ms，而复杂的分析请求（"分析过去一个季度的销售趋势并给出建议"）需要1500ms。这在实际使用中是正常的——系统不会因为少数复杂请求而拖慢简单请求。P50代表了"大多数用户的体验"，P95代表了"最慢的正常用户体验"，P99代表了"异常情况的边界"。
500并发是大型企业客户的峰值负载——约2000-5000名员工的公司，在业务高峰期（如季度分析、年度总结）同时使用AI的场景。这个级别开始暴露出系统的瓶颈。
在500并发下，初始测试结果并不理想：P50延迟上升到680ms，P95上升到2,800ms，P99上升到6,500ms，错误率0.3%（约150个请求超时失败）。深入分析发现了两个关键瓶颈。第一个瓶颈是PostgreSQL连接池耗尽——默认的连接池大小是20，在500并发下连接池经常被全部占用，新请求排队等待连接。将连接池扩大到50后，PostgreSQL端的排队大幅减少。第二个瓶颈是LLM推理服务的并发限制——外部LLM API对单一API Key有每分钟500次请求的限流，500并发下这个限制被触发，导致部分请求被拒绝。解决方案是在压测脚本中引入多API Key轮询——部署5个不同的API Key，通过轮询策略分散请求。
优化后重新测试：P50延迟降至380ms（比100并发时仅增加60ms），P95降至1,200ms，P99降至2,100ms，错误率降至0.02%（主要为极端长尾的超时）。NestJS的每个Pod CPU使用率约55-70%，内存约900MB-1.2GB。事件循环延迟P99约25ms（比100并发时的8ms有所上升但在可接受范围）。PostgreSQL的CPU使用率约55%，查询P50延迟上升到4.5ms（增加了约60%但仍然很低）。
优化的经验：500并发测试给了我们一个重要的启示——在高并发下，瓶颈往往不是CPU或内存，而是连接和限流。PostgreSQL连接池、LLM API限流、Redis连接数、Kafka分区数——这些都是"无形的天花板"，在低并发下完全不可见，一旦触及就会导致性能断崖式下降。我们基于这个发现，在系统监控中增加了所有"软限制"的仪表盘——连接池使用率、API配额消耗率、Kafka消费延迟——确保在达到瓶颈之前就能预警。
1000并发是极限测试——超出任何单一企业客户的正常需求，但帮助我们发现系统的真正容量上限和失效模式。在最极端的场景下（如所有用户在同一时间发送复杂查询），系统是否能够优雅降级而非崩溃？
在1000并发下，初始测试的原始数据非常糟糕：P50延迟1,800ms，P95 8,500ms，P99 15,000ms，错误率约2.5%。但这不是失败——这正是极限压测的目的：发现系统在什么条件下开始失效，以及如何失效。分析失效模式发现：NestJS Pod的事件循环延迟P99飙升到180ms（正常<10ms），说明事件循环被阻塞——不是CPU不够（CPU使用率约75%），而是有同步操作阻塞了事件循环。排查后发现是审计日志的同步写入——每个Agent请求在返回前需要写入一条审计记录（到PostgreSQL），在1000并发下这个同步写入的排队时间成为瓶颈。修复方案是将审计日志写入改为异步——先放入内存缓冲区，批量写入数据库，不阻塞请求响应。
优化后进行第二轮1000并发测试，结果显著改善：P50延迟降至560ms，P95降至2,400ms，P99降至4,800ms，错误率降至0.08%。在测试的30分钟内，系统处理了约186,000次完整的Agent对话。需要注意的是，1000并发的P50延迟（560ms）仍然明显高于100并发的P50（320ms）——这说明系统已经开始承受压力。但重要的是：错误率保持在0.1%以下，没有出现雪崩式崩溃。这意味着在真实的企业场景中，即使在极端峰值流量下，系统仍然能为绝大多数用户提供可接受的响应速度。
失效模式分析：1000并发测试揭示了一个重要的架构特性——我们的系统在面对超出设计容量的负载时，表现出的不是"突然崩溃"（如服务进程OOM退出），而是"渐进式性能下降"（延迟逐步升高但服务持续可用）。这是架构设计中有意追求的特性——通过请求调度器、连接池限流和断路器模式，确保系统的失效模式是"慢"而不是"死"。对于一个企业级SaaS平台来说，"慢了10秒但还是能返回结果"远好于"直接返回500错误"。
通过逐级压测和profiling，我们识别出了EIOS系统的性能瓶颈塔：
LLM推理延迟（占总延迟的55-70%）：这是最大的单一延迟来源——AI平台的性能天花板很大程度上取决于所用LLM的推理速度。在测试中，LLM API的P50响应延迟约200-400ms（取决于输出Token数量）。这个瓶颈不是我们完全能控制的——它受LLM提供商的GPU资源和模型架构限制。我们能做的优化包括：选择更快的模型（如使用GPT-4o-mini替代GPT-4用于简单查询）、实施语义缓存减少不必要的LLM调用、优化提示词长度减少Token数量、对常见查询做预计算回答。
向量检索延迟（占总延迟的10-15%）：HNSW索引在图遍历中需要访问多个节点。在1000并发下，pgvector的CPU使用率达到60%，P95查询延迟约25ms。优化方向包括：使用pgvector的并行查询（parallel index scan），调整HNSW的ef_search参数（查询时降低ef_search值以加速搜索但略微降低精度），将embedding维度从1536降到768（如果任务允许精度下降），使用IVFFlat索引替代HNSW（构建/查询更快但精度略低）。
数据库连接管理（在优化前占误差的约40%）：连接池的排队是"无声的性能杀手"。最佳实践是：为不同类型的请求分配不同的连接池（高优先级OLTP操作和低优先级批处理操作分池），监控连接池使用率（超过70%就预警），使用连接超时和获取连接的等待超时防止无限排队。
审计日志写入（在优化前占请求延迟的约15%）：同步等待审计日志写入数据库是不必要的。异步写入+批量提交是更好的选择——代价是极端情况下（进程crash）可能丢失最后几秒的审计日志。我们权衡后认为这个代价可接受——审计日志的完整性和请求响应的实时性之间，优先保证实时性。
性能优化的黄金法则：不要优化你没有测量的东西。压测+Profiling必须成为开发流程的常规部分——每次重大架构变更后重新压测，确保没有引入性能退化。我们计划在每个版本发布前运行一次标准压测套件（100/500并发），在每次大版本发布前运行极限压测（1000并发）。性能回归应该像功能回归一样被CI/CD流水线自动检测。
基于压测数据，我们制定了EIOS的性能SLA（服务等级协议）：
Agent对话首Token时间（TTFT）：在正常负载下（低于系统容量的80%），P50 < 300ms，P95 < 800ms。在高峰负载下（系统容量的80-100%），P50 < 600ms，P95 < 2,000ms。Agent对话总响应时间：取决于输出Token数量。对于典型长度的对话（500 Token输出），P50 < 1.5s，P95 < 4s。系统可用性：月度正常运行时间 > 99.9%（月停机时间 < 43分钟，包括计划维护）。并发容量：单区域支持500并发Agent对话（P95延迟 < 3s），多区域支持2000+并发（通过全局负载均衡分发）。
这些数字不是拍脑袋编的——每一个都基于压测数据并留有安全余量。例如，TTFT P50我们承诺300ms，而实测100并发下为210ms、500并发下为280ms——承诺值比实测宽松30-40%，以应对生产环境的额外不确定性（网络抖动、第三方服务波动、突发流量尖峰）。
SLA的限度：上述SLA不适用于以下情况：LLM第三方服务故障或严重性能下降（我们依赖的模型API不可用或极度缓慢）、客户自身的网络问题、超出承诺并发容量的流量（如DDoS攻击）、计划内维护时间。此外，某些Agent功能（如大规模数据分析、批量文档处理）天然耗时更长，不适用于实时对话的性能SLA。这些排除条款在服务协议中明确列出——透明是信任的基础。