漫话：如何给女友解释为何双11没法修改收货地址

2018年11月11日上午11点，我拖着疲惫身躯回到家中，准备美美的睡上一觉，洗去身上值班一宿而带来的疲惫。忽然想到以前有交代女友让她帮我抢东西，不知道怎么样了。html

QPS、TR、并发用户数、最佳线程数等等这些都是系统对并发处理上有关的概念。能够用来衡量一个系统的可用性等指标。web

RT

响应时间(Response Time)，是指从客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间。算法

当咱们评价一个网站的"快"和"慢"的时候，其实说的就是他的RT时间的长和短。当咱们访问某个网站，有时候咱们会说这个网站很"卡"，其实言下之意说的就是这个网站的RT很长。bash

若是一个网站的RT很长的话，就会特别的影响用户体验。因此，RT是很重要的一个指标。也是各个网站须要重点优化的。服务器

拿一个游乐园的例子来讲明一下可能会比较容易理解，好比咱们去迪士尼乐园游玩时候，大多数的项目都是须要排队的。markdown

为了让游客知道一个项目须要排队多久才能玩上，迪士尼作了不少事情，好比他们有一个App，专门能够提示每一个项目的预计排队时间。再有就是每一个项目的排队处都有一个小牌牌，上面写着预计排队时间。网络

可是，这个时间并非凭空设定出来的，而是『计算』出来的。并发

迪士尼的排队时间计算方法：app

一、迪士尼在每一个项目的入口处和出口处都会设置工做人员。
二、入口处工做人员随机寻找游客，给游客一张小纸条，上面记录着游客开始排队的时间。
三、入口处工做人员提醒游客，项目游览玩以后，在出口处把小纸条交还给出口处的工做人员。
四、出口处工做人员在收到游客的小纸条后，会用：当前时间-游客开始排队的时间 = 排队时长。
五、为了尽可能让数据准确，通常会收集多个排队时长以后，计算一个平均值。post

以上就是迪士尼的排队时间计算法。其实，这也是RT的计算方法。在一个请求开始的时候记录时间，请求结束的时候再记录时间，两个时间的差值，就是RT了。

迪士尼的一个项目的RT包含了多个时间段：排队时间、听项目讲解时间、项目准备时间、项目游玩时间等。

服务器响应时间也有多部分组成，通常包含：请求发送时间、网络传输时间和服务器处理时间等三部分。

QPS

QPS，指的是系统每秒能处理的请求数(Query Per Second) ，在Web应用中咱们更关注的是Web应用每秒能处理的request数量。这个是衡量系统性能的重要指标。有时候，咱们也称之为吞吐量。

QPS和RT几乎老是成对出现的。当咱们评价迪士尼的一个项目的好坏的时候，一般会包含这几个指标：是否好玩、游玩时长以及能够同时容纳多少人。

这个能够同时容纳多少人，就能够简单的理解为QPS。很大程度上，一个项目同时能够容纳多少人，其实会大大的影响游客的游玩时长。

因此，QPS和RT之间是有着必定的关系的：

RT= 并发数/QPS
QPS= 并发数/RT
复制代码

虽然上面的等式看上去，在并发数必定的状况下，想要提高QPS的话就只能下降RT。但其实并非，以上只是QPS的计算方法。想要提高QPS每每有不少手段。

就像想要提高游乐设施的吞吐量，最首先想到的办法就是升级设备，好比增长游乐场地的面积，增长设备的座位数目，增长排队的队伍个数等。

在计算机系统中，想要提高QPS，主要能够在CPU、内存等硬件上面下功夫，好比提高CPU利用率、增长CPU数目、提高内存等。

和QPS相似，还有个TPS的概念，这里就不作展开了，本文中提到的吞吐量，泛指QPS和TPS，不作详细区分。

并发用户数

并发用户数指的就是同时跑到一个项目前面排队的人数。

关于并发用户数有两种常见的错误观点。

一种错误观点是把并发用户数量理解为使用系统的所有用户的数量；（好比迪士尼的飞跃地平线项目一天可能会接纳50万人，咱们不能说这个50万就是并发用户数）

还有一种错误观点是把用户在线数量理解为并发用户数量。（好比晚上六点的时候，迪士尼的飞跃地平线项目排队加观看人数共有1万人，咱们不能说这个1万就是并发用户数）

并发用户数量的正确理解为：在同一时刻与服务器进行了交互的在线用户数量。（咱们说，晚上六点的时候，共有8000人正在和正在排队使用飞跃地平线这个项目。这才是并发用户数）

拿系统来讲，咱们说淘宝详情页的并发用户数，其实说的是同一时刻请求查看详情页的用户个数。有些用户虽然也在浏览详情页，可是它并无在并发时刻和系统有交互，这就不算的。

最佳线程数

最佳线程数指的就是一个项目最多能够容纳的人数，这里的容纳能够包含排队的人数。

迪士尼每新开一个场馆或者一个游戏项目的时候，都会是一个试运营的阶段。在试运营阶段，经过不断调整并发用户数来观察整个场馆或者项目的运行状况。

除了上线新场馆和新项目之外，有的是在节假日以前也会有一些相似的实验。

这和计算机软件的压测很像。就是不断的提升请求数目，来观察系统的QPS和系统的其余指标，如CPU状况、内存状况等。

性能压测的状况下，起初随着用户数的增长，QPS会上升并对CPU等影响不大，当到了必定的阀值以后，用户数量增长QPS并不会增长，或者增长不明显，同时CPU Load有飙高、内存占用大等状况发生。随之而来的伴随着请求的响应时间大幅增长。这个阀值咱们认为是最佳线程数。

若是并发请求数目，超过了系统的最佳线程数，那么就会致使激烈的资源竞争，随着资源的匮乏甚至枯竭，整个系统也就面临着灾难。

说完，也无论女友的反应，我顺手给她扔了一个连接（ http://www.techug.com/post/10-tips-of-web-app-performance.html ），而后倒到床上就开始补觉了。

不过，在半睡半醒之间，我彷佛听到女友还在埋怨：为啥有的人能够更换地址，我却更换不了呢？

我知道，下次确定要给她讲熔断、限流和降级等知识了。