【网站架构】100万用户量需要达到什么性能指标？并发量、吞吐量、响应时间、错误率

 

​大家好，欢迎来到停止重构的频道。从本期开始，我们进入大型网站宏观整体架构的性能部分， 本期，我们先来讨论一下性能指标。

到底达到什么样的性能指标， 网站系统才能满足目标用户量 ？

这往往是上线或交付的重要前提，通过对性能指标及其关系的了解 ，才能更有效地进行性能调优。

不然，往往就是：以为微服务、分布式服务能无限扩展，但实际上服务器是加上去了， 性能一点也没长，有时候反而更低。

我们按以下顺序介绍 ：

1. 性能指标 

2. 性能指标间的关系 

3. 如何换算性能指标的目标值 

性能指标

网站系统的性能指标说到底只有4个： 响应时间、并发量、吞吐量、错误率。

响应时间指的是处理一个请求所需要的时间，在网络状态良好的状态下，网页打开时间一般要求在3秒内 ，普通接口的响应时间在500毫秒内。

编辑搜图

并发量是网站系统在同一时间需要处理的请求数 ，包括正在处理的请求和处于等待的请求。

 吞吐量是网站系统在一段时间处理请求的数量，常用的单位为TPS、RPS、QPS RPS、QPS都是每秒处理的请求数量，TPS是每秒处理的事务数。

以一个购物行为为例 假设用户的操作需要3步，查看商品列表-查看商品详情-下单商品 。那么，整个购买行为是1个事务，3次请求 理论上，TPS是RPS的1/3。

 

错误率是一段时间的请求错误率，虽然错误率最好是0%，但是在大量并发请求时很难实现，所以请求错误率一般在0.5%以下即可 。

 

性能指标间的关系​

以上4个性能指标任意一个单拿出来都不能描述系统性能，只有4个性能指标结合才能描述系统性能。

这4个性能指标之间的关系可以用饭店进行类比，饭店相当于一个网站系统 、顾客相当于所接收的请求。

 响应时间，相当于顾客到达饭店到离开饭店的时间 ，包括门外排队的时间。

 并发量相当于当前顾客数 ，包括门外排队顾客和店内顾客。

错误率相当于中途走掉的人，如果上菜太慢会走掉，对应响应时间太长，如果排队或店里没有位置也会走掉一部分 ，相当于服务器会拒绝过多的请求对应并发量过大。

 

吞吐量相当于一段时间的顾客流量，但吞吐量的有效量依赖错误率， 如1小时有100个顾客， 但是这100个顾客不一定都是吃完饭走的，也有一部分是没吃饭就走掉的。

 

如何换算性能指标的目标值

回到一开始抛出的问题 ，究竟什么样的性能指标能才能满足目标用户量？

我们假设目标用户量是100万， 那么同时在线用户的峰值一般是10% 。当然，这个比例不同平台相差可能甚远 ，一些平台可能只有千分之一。

这里我们假设同时在线用户的峰值是10万， 那么系统的最大并发量一般为1万（10%）， 因为同时在线用户不会同时发送请求。

以购物为例： 用户不可能点开商品详情就马上点击购买， 一般是先阅读一下信息再决定是否购买， 当然，这个转换的值与业务是相关的 ，这里假设最大并发量为1万。

 

至于响应时间，在网络状态良好的情况下， 为了给用户较优体验，一般的接口请求处理在500毫秒内，一般的网页打开时间要求在3秒内。

这里以普通接口请求为例，在峰值压力时，平均响应时间要求趋近500毫秒。

吞吐量我们采用RPS为单位 ，即每秒处理的请求数， 由于已经明确了最大并发量和平均响应时间， 所以可以计算出峰值压力时 RPS应该高于2万。

这里注意的是 2万RPS是在峰值压力（1万并发量）前提下的值 ，如果低于这个压力 RPS有可能更高 ，但是低压力下的RPS的参考意义并不大。

最后，错误率一般在0.5%以下即可。经过以上换算， 即可满足100万用户的使用。 当然，其中的转换比例需要根据实际系统、业务场景、操作概率而定 。

 

总结

我们这一期明确了性能指标，下一期我们将介绍性能压力测试方案，进一步模拟压力场景。

你所疑虑的一些细节问题， 敬请期待。