之所以写排队论的话题是因为这个理论和性能分析中的队列分析有关。
这里我尽量不写和数学相关的公式，只写分析部分，以免看得人心塞。
写之前先说几个假设条件（在最后会对这几个条件加以说明）：
- 每请求的响应时间相同（为什么要做这个假设？是因为不想计算得太复杂）。
- 每个服务器提供稳定的服务，没有抖动。
- 到达分布是满足泊松分布的。
- 响应时间分布是满足指数分布的。
M/M/1/∞ /∞ /FCFS模型：单线程单连接，先到先服务
（注：以上是kendall表达式）
在下图中有几个前提条件需要说明，单连接单服务进程。
如果这个连接中的前8个请求可以进入系统得到响应，并且同时还有两个空位，也就是说系统可以同时处理10个请求的话，那再接着到达系统的前两个请求就可以立即得到响应。那么后续的两个请求将进入队列等待。这就是最简单的模型：M/M/1/∞ /∞ /FCFS。
M/M/C/∞ /∞ /FCFS：多线程多连接，先到先服务
（注：以上是kendall表达式）
当然大部分系统都不会是上面这个样子，而是下面这个样子。
在下图中，就是进来的连接通道有4个（有人问为什么是4个呢，是因为画多了太乱）。
如果每个连接中的前8个请求到达系统可以得到响应，后续两个也可以得到响应。那再后续的两个就必然进入队列等待。
这就是另一个模型：M/M/C/∞ /∞ /FCFS。
基于第二个模型标识下相应的数学符号：
参数 | 符号 |
请求到达率 | λ |
平均每个线程的TPS | μ |
线程个数 | c |
单个线程的服务强度 | 𝜌 |
单个线程的空闲率 | Po |
整个服务器都空闲的概率 | C*Po |
请求排队概率 | Pw |
请求不排队概率 | Pc |
响应时候的标准方差 | σ |
平均排队的请求数 | Lq |
整个系统中排队的请求数 | c*Lq |
每个线程中的平均请求数（包括等待和正在服务的） | Ls |
整个系统中的请求数（包括等待和正在服务的） | c*Ls |
一个请求的排队时间 | Wq |
一个请求的响应时间 | Ws |
代入相应的数据计算（因为数学公式实在是帖起来太费劲，并且看起来眼晕，这里我就直接把代入数据后的结果帖出来）。
排队计算-1
上表中有几个输入值，即λ/μ/c，这几个值都是可以从系统中得到，或者测试出来的。下面的值部分是通过计算得来的。其中也有一个假设值就是标准方差，之所以现在的计算没有加入标准方差是想减少计算的复杂度。
排队计算-2
从上面的数据可以看到实际系统的处理能力是2000请求/秒。那如果是2000请求同时到达系统会是什么样呢？如下所示：
也就是说如果到达请求数和系统的能力一致的话，响应时间是不变的，但是服务强度、线程空闲率、新请求的排队概率、每线程的平均请求数等都变了。
排队计算-3
如果到达的请求数持续大于系统能力呢？如下所示：
从上表可以看到，如果到达系统的请求数持续超过系统的处理能力的话，那将导致响应时间变长，并且都长在了排队中。
通过排队的计算可以知道：
- 系统当前是否负载过重；
- 系统如果想满足更高的并发应该增加多少处理线程；
- 系统的超时应该如何设计；
- 系统的容量应该如何评估；
以上的计算过于理想化，在现实的环境中当然不会是这样的结果，所以本文的标题是简述。
在现实的环境计算中，有几个点是需要再细究的（对应开篇的假设条件）。
- 到达率
通过系统中的请求到达时间点统计之后，通过卡方检验判断到达率满足哪种分布模型； - 响应时间的标准方差
通过统计响应时间，计算标准方差后代入计算，则响应时间也会受到影响； - 系统的处理能力
在系统有峰值持续时间对响应时间和超时设计的要求；
对这些做细致的统计分析之后，才能对一个系统容量有比较好的指导作用。
这篇文章仅是为了抛砖。更细化的内容需要更多的时间来完成。
希望有兴趣的一起来玩。
