1 系统吞吐量、用户并发量、性能测试概念和公式
1.1 系统吞度量要素
一个系统的吞度量（承压能力：系统在单位时间内处理请求的数量，体现系统整体处理能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个request对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。吞度量常用量化指标有每秒事务数TPS、每秒查询率QPS、每秒HTTP请求数HPS。
系统吞吐量几个重要参数：每秒查询率QPS、并发数、响应时间RT。
每秒查询率 QPS：对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
并发数：指系统可以同时承载的正常使用系统功能的用户的数量。 对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同时发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。
响应时间： 系统对请求作出响应的时间，一般取平均响应时间。如：网络传输时间 N1+N2+N3+N4;应用服务器处理时 间 A1+A3;数据库服务器处理时间 A2; 响应时间 N1+N2+N3+N4+A1+A3+A2;
PV(page view)即页面浏览量：用户每1次访问网页均被记录1次。
1.2 计算公式
同时在线用户数是指在一定的时间范围内，最大的同时在线用户数量。
同时在线用户数=每秒请求数RPS（吞吐量）+ 并发连接数/平均用户思考时间
1）平均并发用户数C=nL / T
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
2 软件性能关注点
2.1不同角色关注点
1）用户关注的是用户操作的相应时间。
2）管理员的角度考虑需要关注的性能点。
相应时间、服务器资源使用情况是否合理、
应用服务器和数据库资源使用是否合理、系统能否实现扩展、
系统最多支持多少用户访问、系统最大业务处理量是多少、
系统性能可能存在的瓶颈在哪里、 更换那些设备可以提高性能、
系统能否支持7×24小时的业务访问
3）开发（设计）人员角度去考虑。
架构设计是否合理、 数据库设计是否合理、
代码是否存在性能方面的问题、 系统中是否有不合理的内存使用方式、
系统中是否存在不合理的线程同步方式、系统中是否存在不合理的资源竞争
3高并发实时后台服务技术架构杂谈
1）流控：后台服务可以支撑的最大并发量，虽然理论上可以通过添加节点（机器）的方法横向扩展，即扩容，但考虑到成本通常后台服务都会存在一个预估的能力上限。后台服务的最大支撑能力低于了实际用户的请求量，那么对后台系统造成的影响可能就如同DDOS攻击，严重的话整个后台服务都会出现不可用，根据业务场景定制合理的流控策略。
2）负载均衡：网关层除了流控功能外，还有一个重要的Balance Load的作用。将大量用户的请求通过负载均衡策略合理地分发给后端节点。每个节点分配不同的权重。
3）接入层：通过网关层执行一些基础的流控策略，然后再由网关层将请求转发给后端的接入层。接入层主要实现一些业务层面的基本校验功能，比如登录态校验。可过滤大部分非法请求，为合法的用户请求留出有限的后台资源。通常接入层都是无状态的，可横向扩展。
4）逻辑层:根据“前轻后重”的原则，接入层一般只执行一些轻量的业务逻辑，真正核心的业务逻辑放在逻辑层来实现。逻辑层是真正核心处理的模块，它的处理能力决定了整个服务的质量，因此逻辑层的设计非常重要。设计原则：缩短关键业务流程、降低单个接口处理时耗、同步变异步、隔离。
5）存储层存储层主要解决的是数据快速访问，大数据量如何存储，以及数据一致性安全问题。对应的解决方案分别是缓存，分库分表，数据如何同步备份。