架构设计之性能评估：如何定义系统并发数、响应时间和吞吐量？

大家好，我是IT孟德，You can call me Aman(阿瞒，阿弥陀佛的ē，Not阿门的ā)，一个喜欢所有对象（热爱技术）的男人。我正在创作架构专栏，秉承ITer开源精神分享给志同道合（爱江山爱技术更爱美人）的朋友。专栏更新不求速度但求质量（曹大诗人传世作品必属精品，请脑补一下《短歌行》：对酒当歌，红颜几何？譬如媳妇，吾不嫌多...青青罗裙，一见动心，但为佳人，挂念至今...），用朴实无华、通俗易懂的图文将十六载开发和架构实战经验娓娓道来，让读者茅塞顿开、相见恨晚...如有吹牛，不吝赐教。关注wx公众号：IT孟德，一起修炼吧！

专栏文章推荐：

网关有什么用？如何进行网关选型？

 架构实战：2万字真实案例全方位解析高并发系统性能优化之道

 架构师指南：像呵护感情一样构建无懈可击的系统稳定性防线

系统性能评估：如何定义并发数、响应时间和吞吐量

实战：混合云架构Nginx+Lua实现流量跨机房分发

架构图的魅力：如何用UML提升架构设计的质量

为什么要做架构设计？架构设计包含哪些内容？

架构师的职责是什么？程序员如何转型为架构师？

什么是架构？架构如何演进？

Mysql数据库连接池druid、hikaricp优化实战

1、前言

        先从高速收费站开始聊吧！据媒体报道，号称“中国最繁忙高速公路”的广深高速曾创下单日85万的车流量记录，吸金能力令人咋舌。如果我们将沿线所有收费站视为一个分布式集群系统，85万是系统的活跃用户，通常80%的车流量都集中在早上8点到晚上20点共计12个小时之间（活跃时段）。车辆通行收费站的场景比较简单，仅相当于一次完整的事务操作，包含车牌识别、缴费到抬杆3个必须动作（用户请求）。假设每辆车从进入收费站到离开平均需要30秒（响应时间/会话时长，车辆进入收费站所有动作一气呵成，不太可能有无故停顿，正常状态会话时长等于响应时间），即同时进入收费站范围的车次850000×80%×30÷12÷3600≈472辆（并发数），理论上收费站每秒放行472÷30≈16辆车时可确保畅通无阻（吞吐量，通常用TPS/QPS表示，这里的通过是一个完整的“事务”，所以10是TPS，QPS为10×3=30）。但现实情况广深段可能仅有20个出口200条通道（线程池，系统通过线程池限制并发数），当前收费站每秒仅能处理200÷30≈7辆车次，所以必然导致车辆排队，增加会话时长，并发数越来越高，最终堵车越来越严重。

        那么如何提升车辆通行效率（性能优化）呢？最直接的办法就是增加通道加大并发线程，譬如鹤洲站2023年扩建后出口通道增至26条。但单纯堆硬件的方式成本太高，且低峰期资源浪费严重（资源利用率低），所以还可以将人工通道改造为ETC优化单通道响应时间。ETC将耗时最长的缴费动作改成异步处理，每辆车通行时长从30秒降至5秒，200条通道每秒钟可以通过40辆车，堵车问题迎刃而解。当然这些都是理想状态，实际上还有很多车都没有装ETC、每辆车通过收费站不会那么顺利、车辆到达收费也忽多忽少或集中在某几个收费站...所以在设计之初，就应该定义好各项指标，设置冗余和预留扩展。广深高速当初设计通行能力每日车流量8万辆次，饱和车流量14.4万辆次，当前拥堵已成为家常便饭。

2、性能指标

        在高速收费站的案例中，某些数据不可能那么就精准，但是基本上捋清楚了性能相关的一些概念以及如何计算性能指标的方法。性能是指系统在执行任务时所展现出的效率和能力，是系统设计中非常关键的非功能指标。架构设计中经常提及的三高设计、即高并发、高性能和高可用，其中高并发和高性能都属于系统非功能设计中性能的范畴。所谓高性能强调系统的处理能力，即单位时间内完成任务的速度与效率，追求低延迟与高吞吐。而高并发侧重于系统在单位时间内并行处理大量请求的能力，它是性能在高负载场景下的具体体现。值得注意的是并发并不意味着任务真正同时执行，而是通过合理的调度（如时间片轮转、任务切换）让多个任务看似同时推进。比如某时间管理大师同时交往7个女友，这个叫并发；古代帝王后宫佳丽三千，只要皇帝高兴，可以把所有贵妃、常在聚在一起玩耍，这个叫并行。总体来说，高性能是纵向深化，追求单点极致效率；高并发是横向扩展，保障规模下的稳定吞吐。对于大型分布式系统，为保障高效稳定的服务，高性能目标需覆盖高并发场景。我们通常通过并发数、响应时间和吞吐量（TPS/QPS）、资源利用率等指标来共同衡量系统的性能。

2.1、并发数

        首先我们需要确定系统可承载的并发数，即系统每秒可处理的请求数。并发数根据系统用户行为数据推算而来。计算逻辑为日活用户使用的总时长除以活跃时段，基础公式如下：

        并发数 = 日活用户 ✖️ 平均会话时长 ➗ 活跃时段

        对于已有系统重构或扩展新业务模块，相关参数可以分析原有业务系统数据获取。如果是从0到1开始搭建，缺少存量系统用户行为数据支撑的情况下，那么就需要结合实际业务来推导，尽可能贴近真实场景。日活用户可根据不同行业目标（潜在）用户的活跃率折算，通常社交类产品日活跃率为30~50%、工具类20~40%、企业级应用10~30%，为了更加真实，日活用户只取活跃时段用户数。会话时长是用户平均使用时长，基本上与系统提供的核心业务操作时间相匹配，比如外卖平台点一次外卖需要的时长。活跃时段为一天当中用户集中使用的时间，根据业务特点评估，比如作业辅导APP，学生使用比较有规律，80%的用户集中在放学后晚上18点到22点之间使用。我们再用一个完整的例子来算一遍，比如某券商线上炒股系统，目标用户就是100万开户的股民数，日活用户按工具类活跃率上限上浮10%折算为50万，70%股民都会集中在开盘时间（上午9点到11点、下午13点到15点）上线盯盘交易，平均使用时长约20分钟。最后套入公式，并发数= 500000×70%×（20×60）÷（4×60×60）≈ 29167。

        这个公式计算出来的并发数相对粗犷，它更接近同时在线用户数，比较吻合需要保持长连接的系统的并发数，比如在线游戏、在线会议、即时通讯系统。而Web系统更多都是http协议，如果平均会话时长取值较大，期间用户没有实质性操作的话，tcp连接会超时断开，对系统压力有限，所以可以将公式调整为：

        并发数 = 日活用户 ✖️ 平均请求接口次数 ➗ 活跃时段

        以12306购票业务为例，用户登录主要目的就是为了订票，调用接口主要包含登录、车票查询、查询乘车人、提交订单、去支付、提交支付、支付回调、出票、查询订单、查看订单详情。其中车票查询比较特殊，假设人均查询3次，加起来人均请求接口12次。根据官方披露，12306平均日活为1800万，那么日总请求量为1800万×12=2亿1600万。一般12306放票时间相对比较均匀，所以90%购票行为集中在上午8点到晚上22点共14个小时之间，所以并发数=2亿1600万×90%÷（14×3600）=3857。以上基于个人对12306订票业务表面操作的简单分析，实际情况用户请求的接口数会更多，且需要考虑节假日、春运等场景。

        最后强调一点，前面不管哪种公式得到的并发数都是整个系统的并发。对于业务复杂的系统来说，会拆分成若干模块，包含少则几十上百、多则数千个业务接口，有些是核心的，有些是次要的，被调用的频率必定也不一样。为了更加贴合实际业务场景，需要按上述的思路单独评估核心模块或接口的并发能力。

2.2、响应时间

        响应时间（Response Time, RT）是从用户发出请求到系统返回响应的总时间，包含服务端处理、网络传输和客户端渲染等环节。它是衡量系统性能的核心指标之一，直接影响用户体验、系统效率及业务可持续性。在架构设计阶段，需结合业务场景、技术实现、用户体验、行业标准等综合考虑响应时间指标。

1. 按业务场景定义指标

        将业务流程分解为多个环节，分析每个场景的响应时间对整个业务流程的影响，识别核心路径。例如电商平台的订单支付流程包括订单确认、支付处理、订单状态更新等环节，其中支付处理环节的响应时间对整个支付流程的用户体验影响最大，应制定更严格的响应时间指标。不同场景对响应时间的要求参考如下（接口响应）：

2.按分层定义指标

        从用户层到系统层将用户感知的整体响应时间分解为前端响应时间、网络传输时间、后端处理时间等多个环节的响应时间指标；从系统层到组件层将后端处理时间进一步分解为各个组件的响应时间指标，如数据库查询时间、服务调用时间、业务逻辑处理时间等。在不同层级设置不同的响应时间目标：

3.参考行业标准、竞品分析与用户容忍度定义指标

        用户对系统的直观感受几乎完全依赖于响应速度。由于不同行业的业务特点和需求差异较大，用户对响应时间的容忍度不同，相应的响应时间标准也不同。用户容忍度、行业标准与竞品数据共同构成响应时间指标基准，既避免闭门造车，也确保服务能力与市场动态同步进化。如电商网站页面加载每增加1s转化率下降约7%、金融交易系统要求所有核心操作必须在200ms内完成。

• 用户容忍度阈值参考（整体页面加载）：

• 部分行业标准参考（接口响应）：

        评估系统响应时间指标的方式很多，实际应用中需结合自身系统的特点和业务需求灵活应用。例如C端产品首页加载需严控2s内，sql慢查询阈值为100ms，而导出10万条数据可放宽至5s。

2.3、吞吐量

        吞吐量是一个广义的概念，指系统在单位时间内完成的有效数据量或任务量。在计算机网络中，吞吐量通常以比特/秒（bps）或字节/秒（Bps）为单位；而在软件系统中，则常用QPS或TPS表示。QPS 表示每秒查询次数，通常用于衡量数据库或接口的查询性能，特别适用于GET请求或SELECT操作。TPS表示每秒事务处理数量，通常用于衡量系统完成完整业务流程的能力，适用于插入、更新、删除等写操作（如电商下单包含库存扣减、生成订单、支付等多个业务操作）。QPS关注单次操作的响应速度，TPS强调整体业务流程的可靠性，两者在复杂系统中需协同优化。明确了并发数和响应时间指标，吞吐能力可以通过以下公式计算：

        吞吐量 ≈ 并发数 ➗ 平均响应时间

        看到这个公式，读者可能会想提高并发数就能提高吞吐量？设想一下，假设一家奶茶店只有一个店员，每制作一份饮品需要3分钟，如果每次2人同时点单，每人平均需要等待4分半钟；如果每次3人同时点单，平均每人就得等6分钟。不考虑手忙脚乱的情况下每小时服务20位顾客的吞吐量没变，但因为排队变长（响应时间变长）从而导致用户体验变差。为什么会出现这种情况呢？其实原因很简单，实际并发没有变化，顾客增加了，但只有一个店员提供服务。那是不是增加店员就能解决呢？不一定，可能会因为使用设备冲突导致响应时间增加。所以说，吞吐量与并发数呈正相关的前提是响应时间不变，但实际中随着并发数增加，系统资源（如 CPU、内存、IO）会被抢占，导致响应时间延长，吞吐量增长逐渐趋缓。若需提升吞吐量，可通过减少响应时间（如优化代码、升级硬件）或增加并发处理能力（如集群部署）实现。

3、性能评估

        所有的指标都明确后，通过JMeter、LoadRunner等压测工具模拟真实或超预期的用户负载，识别出关键性能指标与预期的差距并持续优化，确保系统在高并发、大数据量、长时间运行等场景下依然稳定可靠。以下是一份100线程执行10分钟混合场景JMeter聚合报告示例（只展示了部分指标）：

        从报告中可以看出，系统总吞吐量为631.2次/秒，报告中响应时间有多个不同类型的指标，如99% Line表示99%的请求响应时间小于等于该值。为什么需要百分位值呢？平均值易受极端值（如偶尔出现的秒级延迟）影响，无法真实反映用户体验，百分位值可更精准地描述 “典型场景” 的响应能力。如建订单接口95% Line为750ms、99% Line为1450ms、最大响应时间达2800ms，表明高并发下订单处理存在长尾延迟。长尾请求可能导致线程阻塞、资源耗尽，进而引发雪崩效应，有必要分析根因进行优化，甚至设置熔断（如连续5次超过1500ms则熔断）。

        大多数情况下，压测都是基于性能环境或测试环境开展，难以完全还原真实生产环境的复杂性和负载情况。因此压测的结果更多是参考性质的评估指标，无法精确预测系统在真实高并发场景下的表现。为了弥补这一差距，还需在系统上线后搭建实时监控系统（如Grafana + Prometheus实时采集CPU利用率、内存使用、响应时间等指标），通过动态追踪性能指标、快速定位瓶颈并持续优化迭代。

专栏文章推荐：

网关有什么用？如何进行网关选型？

 架构实战：2万字真实案例全方位解析高并发系统性能优化之道

 架构师指南：像呵护感情一样构建无懈可击的系统稳定性防线

系统性能评估：如何定义并发数、响应时间和吞吐量

实战：混合云架构Nginx+Lua实现流量跨机房分发

架构图的魅力：如何用UML提升架构设计的质量

为什么要做架构设计？架构设计包含哪些内容？

架构师的职责是什么？程序员如何转型为架构师？

什么是架构？架构如何演进？

Mysql数据库连接池druid、hikaricp优化实战