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（每秒查询率）取决于多个因素，包括但不限于以下几点：

1. 硬件配置：服务器的 CPU、内存、硬盘速度等硬件资源对性能有很大影响。更高配置的硬件通常能够支持更高的 QPS。

2. 应用程序复杂性：应用程序的复杂性、处理逻辑和业务需求会影响 QPS。一些复杂的业务逻辑和大量的计算可能会降低系统的吞吐量。

3. 并发连接数：同时连接到 Tomcat 的请求数量也是限制 QPS 的因素。在高并发场景下，如果并发连接数过高，可能会降低系统的响应速度。

4. 网络带宽：处理请求的 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能支持