假设一个系统的业务有登录、浏览帖子、发送新帖、回复帖子，访问高峰是上午10点，日访问高峰PV约5208（含登录1300、浏览2706、发帖526、回帖676）。系统响应时间要求小于3秒，试计算此系统的TPS以及并发数。
如果分析业务量的数据是以PV来统计的，我们需要把PV转化为TPS。
实际上一个PV即一次对服务器的客户请求，可能还包含了很多资源请求，比如图片、样式、JS信息、文字等。而浏览器具有资源缓存功能，下次访问同样资源将不会再从远程服务器上下载，这大大加快了响应速度。如果我们使用代理服务器访问外网资源时，多数代理服务器也会缓存这些静态数据。也就是说浏览器与服务器之间的动态数据的 Size 会小于静态数据。
所以浏览器是否缓存了静态数据对性能测试影响明显。我们在做性能测试时，其中就有许多用户可能是新用户，在他们的浏览器上还没有缓存这些静态数据，为了更准确的模拟用户请求，我们有必要不缓存这些静态内容。所以性能测试中是否缓存访问的静态资源要根据业务情况而定。
本例中，我们把一个请求放在一个事务中来统计服务器的响应时间。这么说，一个PV即是一个事务（每秒的PV量并不直接等同于TPS，因为一次客户请求可能包含了很多资源请求。如果我们不关心页面刷新时请求资源的耗时，此时我们就把每秒PV数等同于TPS）。比如一个功能页面（浏览帖子）每秒会有10个PV，那么此功能的TPS即为10。
估算TPS
业务量一般要取系统业务高峰的值，才能代表系统的实际处理能力。系统在10点的访问高峰PV约5208，那么这个时段的TPS=5208/3600≈1.45吗？
答案是否定的，因为在一小时内的吞吐量未必是平均的。
如果我们采集到的业务量数据能够细分到每分钟，TPS就越准确。如果不能，可以按照二八原则。即80％的业务在20%的时间内完成，TPS=（520880%)/(360020%)≈5.8。
估算并发数
- 由TPS进行估算
- 由在线活动用户数估算
- 根据经验估算
这里我们采用第一种方法。
因为TPS=事务数/时间，假设所有的事务都来自不同的用户，那么并发数=事务数=TPS*时间。具体如下：
Vu（业务名称）=TPS（业务名称）*（Runtime+ThinkTime）
其中，Vu（业务名称）表示此业务的虚拟用户数，即并发数。RunTime是测试程序/脚本运行一次所消耗的时间，包括事务时间+非事务时间。ThinkTime是模拟用户思考或者填写表单消耗的时间。
下面是发帖动作的测试脚本伪代码（T、TT、AT表示时间，单位为秒。AT一般都是非常小的，包含在事务时间中，可以忽略）。Runtime=T1+···+T7；ThinkTime=TT1+TT2。
业内一般把 Think Time 设为3秒。测试需求中要求响应时间小于3秒，我们就以3秒为阀值（为什么只有事务页面是3秒，非事务时间是0.2秒？？？）。可得Vu=TPS（RunTime+ThinkTime）=5.8（T1+TT1+T2+T3+T4+T5+TT2+T6+T7）≈76。
如果只计算事务时间，Vu=TPST2=5.82≈12。
可以看到两者之间的Vu数量相差巨大。由于一次迭代的时间会大于事务的响应时间，如果在估算时不把非事务消耗的时间加入进去，计算出来的12个并发用户在测试执行时很有可能无法达到TPS=5.8的目标。
由于我们计算Vu时，使用的是系统TPS（登录、浏览、发帖、回帖合计），其中又以发帖业务消耗时间最长，所以计算出来的76个并发数实际上是系统业务的总并发数，需要按比例分配到各个业务。
| 业务名称 | 高峰业务量 | TPS | 并发数 | 响应时间 | 事务成功率 |
|---|---|---|---|---|---|
| 登录 | 1300 | 1.44 | 20 | <3秒 | >99% |
| 浏览 | 2706 | 3.0 | 40 | <3秒 | >99% |
| 发帖 | 526 | 0.58 | 7??? | <3秒 | >99% |
| 回帖 | 676 | 0.75 | 10 | <3秒 | >99% |
| 合计 | 5208 | 5.8 | 77 | - | - |
实际上分配时由于有小数点，向上取整（是合计向上取整，还是单个业务向上取整？？？），所以76个并发用户分配后是77个。
并发数的计算说到底还是一个估算，在性能测试执行时需要根据实际情况调整。衡量性能的指标还是要参考TPS实际达到了多少，响应时间是多少，系统硬件（CPU、内存等）指标是否在限定范围内等要求。
