一个系统的吞度量（承压能力：系统在单位时间内处理请求的数量，体现系统总体处理能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个request对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。吞度量经常使用量化指标有每秒事务数TPS、每秒查询率QPS、每秒HTTP请求数HPS。html
系统吞吐量几个重要参数：每秒查询率QPS、并发数、响应时间RT。数据库
每秒查询率 QPS：对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，做为域名系统服务器的机器的性能常常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也便是最大吞吐能力。后端
并发数：指系统能够同时承载的正常使用系统功能的用户的数量。 对于网站系统咱们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。因为注册用户可能长时间不登录网站，使用注册用户数做为性能指标会形成很大的偏差。而在线用户数和同时发请求用户数均可以做为性能指标。相比而言，以在线用户做为性能指标更直观些，而以同时发请求用户数做为性能指标更准确些。缓存
响应时间： 系统对请求做出响应的时间，通常取平均响应时间。如：网络传输时间 N1+N2+N3+N4;应用服务器处理时 间 A1+A3;数据库服务器处理时间 A2; 响应时间 N1+N2+N3+N4+A1+A3+A2;安全
PV(page view)即页面浏览量：用户每1次访问网页均被记录1次。服务器
同时在线用户数是指在必定的时间范围内，最大的同时在线用户数量。
同时在线用户数=每秒请求数RPS（吞吐量）+ 并发链接数/平均用户思考时间网络
1）平均并发用户数C=nL / Tsession
n是平均天天访问用户数（login session），L是一天内用户从登陆到退出的平均时间（login session的平均时间），T是考察时间长度（一天内多长时间有用户使用系统）架构
2）并发用户数峰值≈C + 3 *（根号C） 并发
举例假设系统A，该系统有3000个用户，平均天天大概有400个用户要访问该系统（能够从系统日志从得到），对于一个典型用户来讲，一天以内用户从登录到退出的平均时间为4小时，而在一天以内，用户只有在8小时以内会使用该系统。
平均并发用户数为：C = 400*4/8 = 200
并发用户数峰值为：≈200 + 3*根号200 ≈ 200 + 3*14.1≈ 242
3）吞吐量，指单位时间内系统处理用户的请求数
从业务角度看，吞吐量能够用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量。从网络角度看，吞吐量
能够用：字节/秒来衡量。对于交互式应用来讲，吞吐量指标反映的是服务器承受的压力，他可以说明系统的负载能力。
当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在必定的联系，能够采用如下公式计算：
TPS=(虚拟用户个数VU * 每一个虚拟用户发出的请求数R )/性能测试所用的时间T
TPS=每一个虚拟用户发出的请求数R × 系统的并发用户数C
4）思考时间的计算公式
Think Time，从业务角度是指用户进行操做时每一个请求之间的时间间隔，在作性能测试时，模拟这样的时间间隔，更加真实的
模拟用户的操做。
每一个虚拟用户发出的请求数R = 性能测试所用的时间T / 思考时间TT
1）用户关注的是用户操做的相应时间。
2）管理员的角度考虑须要关注的性能点。
相应时间、服务器资源使用状况是否合理、
应用服务器和数据库资源使用是否合理、系统可否实现扩展、
系统最多支持多少用户访问、系统最大业务处理量是多少、
系统性能可能存在的瓶颈在哪里、 更换那些设备能够提升性能、
系统可否支持7×24小时的业务访问
3）开发（设计）人员角度去考虑。
架构设计是否合理、 数据库设计是否合理、
代码是否存在性能方面的问题、 系统中是否有不合理的内存使用方式、
系统中是否存在不合理的线程同步方式、系统中是否存在不合理的资源竞争
1）流控：后台服务能够支撑的最大并发量，虽然理论上能够经过添加节点（机器）的方法横向扩展，即扩容，但考虑到成本一般后台服务都会存在一个预估的能力上限。后台服务的最大支撑能力低于了实际用户的请求量，那么对后台系统形成的影响可能就如同DDOS攻击，严重的话整个后台服务都会出现不可用，根据业务场景定制合理的流控策略。
2）负载均衡：网关层除了流控功能外，还有一个重要的Balance Load的做用。将大量用户的请求经过负载均衡策略合理地分发给后端节点。每一个节点分配不一样的权重。
3）接入层：经过网关层执行一些基础的流控策略，而后再由网关层将请求转发给后端的接入层。接入层主要实现一些业务层面的基本校验功能，好比登陆态校验。可过滤大部分非法请求，为合法的用户请求留出有限的后台资源。一般接入层都是无状态的，可横向扩展。
4）逻辑层:根据“前轻后重”的原则，接入层通常只执行一些轻量的业务逻辑，真正核心的业务逻辑放在逻辑层来实现。逻辑层是真正核心处理的模块，它的处理能力决定了整个服务的质量，所以逻辑层的设计很是重要。设计原则：缩短关键业务流程、下降单个接口处理时耗、同步变异步、隔离。
5）存储层存储层主要解决的是数据快速访问，大数据量如何存储，以及数据一致性安全问题。对应的解决方案分别是缓存，分库分表，数据如何同步备份。