1. 衡量业务量的指标
衡量业务量的指标项有很多，比如，常见Web类应用中的PV、UV、IP。而比较贴近业务的指标项就是大家通常所说的业务用户数。但这个用户数比较笼统，其实和真实访问量有比较大的差距，所以为了更贴近实际业务量及压力，我们又把用户数的指标分成了活跃用户数、在线用户数以及并发用户数。常见衡量业务量级的指标汇总如表所示。
| 指标 | 计算周期 | 所表示的业务指标含义 |
|---|---|---|
| PV | 按天 | PV是Page View的简写。一般指Browser/Server（浏览器/服务器）架构中的Web类业务一天内页面的访问次数，每打开或刷新一次页面，就算作一个PV |
| UV | 按天 | UV是Unique Visitor的简写。一般指Browser/Server（浏览器/服务器）架构中的Web类业务一天内访问站点的用户数（以Cookie为依赖） |
| IP | 按天 | IP是指Browser/Server（浏览器/服务器）架构中的Web类业务一天内有多少个独立的IP浏览了页面，即统计不同的IP浏览用户数 |
| 用户数 | 软件周期 | 一般指业务系统的注册用户数 |
| 活跃用户数 | 按天 | 指注册用户数中，一天中实际使用了业务系统的用户数量，跟UV的概念一样 |
| 在线用户数 | 按天 | 指一天的活跃用户数中，用户同时在一定的时间段内在线的数量 |
| 并发用户数 | 按秒 | 指在线用户数的基础上，某一时刻同时向服务器发送请求的用户数 |
2. 业务访问量与性能压力指标的转换
得到业务访问量的指标数据后，我们要将其转化成为系统压力的指标数据。这一步让抽象的业务访问量的指标数据，变成技术人员熟悉的性能压力指标数据，这样在做架构规划设计、容量规划和成本预算时才能有章可循，从而使其思路更加清晰。
2.1 未上线业务量与性能压力指标的转换
针对业务还处于前期需求规划期间的容量规划，最常见的做法就是把业务量的数据指标，最终转换成对系统的每秒请求数，进而评估对应业务量究竟产生了多少性能压力，最终设计出合理的架构，以及要用多大规模的服务器及配置。
2.2 已上线业务量与性能压力指标的转换
如果业务系统已经上线，生成指标转换的模型就要简单的多。一方面，当前业务系统有多少用户量及活跃用户量等业务数据，运营人员基本都能很直接的给出。另一方面，业务系统的运行性能状态也能通过监控很直接地体现出来。有了这两组数据，我们就能将用户量与性能压力进行转化对应，也能做出未来业务量下的容量规划等。比如，100万用户量，当前用了10台机器，业务高峰期资源使用率是50%。如果变成200万用户量，至少要在加10台服务器。在实际应用中，用户量和对系统压力不是呈线性级关系，而是指数级关系。
3. 服务器配置模型
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
单台机器支持多少QPS？ 这和很多因素有关，以Tomcat为例，单机 Tomcat 的支持的 QPS（每秒查询率）取决于多个因素，包括但不限于以下几点：
-
硬件配置：服务器的 CPU、内存、硬盘速度等硬件资源对性能有很大影响。更高配置的硬件通常能够支持更高的 QPS。
-
应用程序复杂性：应用程序的复杂性、处理逻辑和业务需求会影响 QPS。一些复杂的业务逻辑和大量的计算可能会降低系统的吞吐量。
-
并发连接数：同时连接到 Tomcat 的请求数量也是限制 QPS 的因素。在高并发场景下，如果并发连接数过高，可能会降低系统的响应速度。
-
网络带宽：处理请求的 Tomcat 服务器与客户端之间的网络带宽也会对 QPS 产生影响。更高的带宽可以支持更多的请求同时传输。
Tomcat 里面有一个线程池。其 maxThreads 默认值是 200（假定 BIO 模式）：
假设服务器处理请求RT为1秒，理想状态下单机Tomcat QPS=200
4. 案例分析
4.1 500w PV 需要多少台机器
500w PV，即一天24小时中访问了业务页面500w次，根据2/8法则，80%的业务发生在20%的时间段。计算公式如下
QPS = （80% * 总PV）/ （24小时 * 3600秒 * 20%）
500w PV QPS = （80% * 500w）/ （24 * 3600 * 20%） = 231.48 个请求/秒
所以理想状态下至少得 2台4核8G服务器部署Tomcat能支持
4.2 1000w 用户 需要多少台机器
1000w 用户 按照2/8法则，有20%活跃用户，假设平均每个用户过来点击10次
PV = 1000w * 20% * 10 = 2000w PV
QPS = （80% * 2000w）/ （24 * 3600 * 20%） = 925.92 个请求/秒
所以理想状态下至少得 5台4核8G服务器部署Tomcat能支持
