投标准用的软件性能检测报告之中, 并发数量常常并非是靠随意决定的, 而是依据真切业务情形推导出来的, 你所获取的那一份报告里头, 并发数量究竟该源自何处、依据什么这样计算, 这是评标专业人员以及甲方技术主管真正期望看到的内容。
1
并发数并非越大便越好,它乃是业务场景的函数, 众多投标方惯于书写出一个看似具备唬人效果的数字, 像"支持10000并发"这般, 然而倘若此数字并无对应真实的用户行为模型, 反倒会在答疑环节被当场戳穿。真正的并发数需从三个维度予以锚定, 分别是日常平均在线人数、峰值时段活跃比例以及单笔交易的耗时, 这三个量一经组合, 你便能够获取一份有着依据可供查证的计算过程, 而非一个孤立存在的数字。
2
有一个业界通用的关于具体计算方法的起点, 先去确定"业务量基线", 这指的是那系统的核心交易在每个正常工作日里每小时大概能处理的笔数, 比如说某政务OA系统, 在日常办公的时段里每小时大概会有200笔待办审批存在、这200笔便意味着该系统在这个时段的真实工作负载。紧接着要把"峰值系数"乘上去, 常见的取值是在1.5到2.5倍之间, 是依据行业波动性来决定的；政务系统一般情况下通常会取1.5, 电商秒杀类的则会取2.5以上。最后经由Little定律进行换算得出: 并发数 等于 业务量 乘以 峰值系数 乘以 平均响应时间（以秒作单位）而后除以3600；这套给出的公式是什么呢, 没错"稳态并发", 它相较于单纯写出一个高数字而言更具说服力, 原因在于它经受得住评委提出的追问。
3
在实际操作情形之下, 还得将"目标响应时间"进行反方向的约束并发上限的操作: 要是投标要求之中确切写明了"审批页面响应时间不超过2秒", 那么并发数就不能够毫无限制地向上推升, 不然在性能压测之际必然会出现被打爆的状况；正确的做法是先依据上面所提及的公式计算出一个候选并发数值, 接着在压测过程里分步缓慢增加并发, 并记录响应时间曲线, 从而找到满足"不超2秒"要求的那个拐点, 那个拐点才是你投标报告里应当填写落笔的数字。
并发数, 绝非投标书里用于炫技的装饰词汇, 它理应是那种, 能够还原业务的, 能经得起追问的, 能用数据闭环验证的真实参数；撰写报告之际, 将计算过程清晰写出来, 远比写一个令人震惊的数字要重要许多。