大型网站基础架构，我们需要理解这六个性能指标

大家好，笔者曾在多家一线互联网公司负责核心业务的架构设计与研发，对大型互联网服务架构有着丰富的实战经验。

欢迎【关注】，一起完善属于我们自己的大型网站技术架构知识体系。

上一篇 "大型网站架构概述，我们必须要理解的这五个架构要素" ，我们主要一起理解了大型网站架构设计中高性能，高可用，可伸缩，可扩展和安全性这五大要素，知道了怎么通过这些架构要素来衡量我们整体系统架构设计的优劣。

今天我会跟大家分享的是，我们在做大型网站技术架构的时候，必须要彻底理解的四个方面性能指标以及一些基础知识，我们才能找到系统瓶颈，分而治之，逐步优化。

欢迎关注笔者，相信能够帮助到大家，一起完善属于自己的大型网站技术架构知识体系。

大型互联网服务和传统软件服务最大的区别点就是对极端流量的性能要求差异。

由于互联网业务系统的多样性和业务架构的差异性，大型网站的高性能架构设计一直是业内巨大的技术挑战。

比如我们大家都知道的这些经典互联网事件

1.鹿晗公布恋情，微博在当天会卡顿

2.天猫双十一期间，点击支付按钮会响应变慢

3.12306刚上线就直接崩溃

5.在18年春晚，经受过双十一洗礼的阿里服务器还是出现宕机

笔者也是这些事件中的亲历者，在极端流量下，深刻体会到高性能在大型网站架构设计的重要性。

任何软件架构设计方案都必须考虑可能带来的性能问题，也正因为性能问题几乎无处不在，在请求链路的任何一个环节，都是需要我们去做极致性能优化，全链路某一环节的瓶颈，就是整体服务的瓶颈所在。

当然，本期专栏其中一个重要目的就是希望能帮助大家建立起自己的大型网站架构之高性能知识体系。

今天这篇我们先从基础开始，去掌握必须知道的性能指标，只有扎实的基础才能让我们走的更远。

当我们在浏览器上打开一个网页，会直接感受到这个网站响应速度快还是慢。

我们感受到的时间，主要包括了用户浏览器构造请求时间，域名解析时间，网络通信的时间、服务端处理的时间、用户浏览器解析响应数据的时间等等。

不同计算机的性能不一样，不同浏览器解析HTML速度的不一样，不同网络运营商提供的互联网宽带服务的不一样这些差异最终导致用户感受到的响应延迟可能会远远大于服务端处理请求需要的时间，所以我们要做的高性能架构设计方案，必须要是全链路覆盖的设计方案才是可行的。

为了提高性能，常规的有很多方案

比如前端优化方向，有通过优化页面HTML式样、利用浏览器端的并发和异步特性、调整浏览器缓存策略、使用CDN服务、反向代理等手段。

1.比如服务端优化方向，使用缓存加速数据读取，使用集群提高吞吐能力，使用异步消息加快请求响应及实现削峰，使用代码优化手段改善程序性能。

2.比如基础服务优化方向，有建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用等等。

究竟我们在设计过程中应该怎么抉择，那就需要我们知道一些基础的性能知识以及必须理解的四大性能指标，我们对系统的瓶颈在哪里就心里有数了。

1.服务器程序将需要发送的数据写入该程序的内存空间中；

2.服务器程序通过操作系统的接口向内核发出系统调用；

3.系统内核将用户态内存空间中的数据复制到内核缓冲区中去，然后通知网卡过来取；此后CPU转而做其他处理；

4.网卡到CPU指定的内核缓冲区中将数据复制到网卡缓冲区中；

5.网卡将字节转换成二进制位，再以电信号的形式输出至网络。

数据在计算机内部的复制是按照总线的宽度来复制的。比如在32位的操作系统中，数据每次都复制32位。

数据的发送速度由接收方的接收速度决定。在数据链路层中，为了确保数据在接收过程中不发生丢失，因此接收方要告诉发送方目前发送速度是否合理。若接收方来不及收，就会告诉发送方，让它慢点发。

因此，数据的发送速度(即带宽)由接收方的接收速度决定。

与传播介质的并行度有关。传输介质可以看成是多车道马路，数据由0/1组成，每股车道每次只能容纳一个0/1。因此，如果马路的车道增多，那么每次发送的0/1也就增多，从而提高了发送速度(即带宽).

我们的服务器会通过一个交换机连入互联网，互联网由无数个路由器和主机构成，路由器负责数据包的存储转发,将数据包根据目的地址途径一个个路由器，最终投递到目的主机中。

由于一个交换机往往有多个服务器接入，服务器们都会将需要发送的数据首先发给交换机，再由交换机发给路由器，这些数据先存储在路由器的缓存中，然后路由器根据先后顺序逐个转发。

所以，如果服务器发送数据的速度过快，路由器缓存满了，那接下来的数据就会丢失，因此需要限制服务器向路由器发送数据的速度，即限制服务器的带宽。

而这个限制由接入服务器的交换机完成。通过上文可知，交换机只要控制接收速度，就能限制服务器的发送速度。

响应时间

指应用执行一个操作需要的时间， 响应时间(RT)是指从客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间，响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。

响应时间是系统最重要的性能指标，直观地反映了系统的"快慢"，我们要客观知道一个服务的响应时间，通常是通过记录收到响应和发出请求之间的时间差来计算系统响应时间。

直观上看，这个指标与我们对服务性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。

由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同服务的响应时间肯定也不尽相同，甚至同一功能在不同用户数据的情况下响应时间也不相同。

所以，在讨论一个系统的响应时间时，我们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。

指系统能够同时处理请求的数目，这个数字也反映了系统的负载特性。对于互联网服务而言，并发数即并发用户数，指同时提交请求的用户数目。

在网站产品设计初期，产品经理和运营人员就需要规划不同发展阶段的网站系统用户数，并以此为基础，根据产品特性和运营手段，推算在线用户数和并发用户数。这些指标将成为系统非功能设计的重要依据。

测试程序通过多线程模拟并发用户的办法来测试系统的并发处理能力，为了真实模拟用户行为，测试程序并不是启动多线程然后不停地发送请求，而是在两次请求之间加入一个随机等待时间，这个时间被称作思考时间。

我们一般通过在超过安全负载的情况下，不断对系统继续施加压力，直到系统崩溃或不能再处理任何请求，以此获得系统最大压力能承受的并发数。

指单位时间内系统处理的请求数量，体现系统的整体处理能力。

对于网站，可以用"请求数/秒"或是"页面数/秒"来衡量，也可以用"访问人数/天"或是"处理数/小时"等来衡量。

TPS（每秒事务数）是吞吐量的一个常用量化指标，此外还有HPS（每秒HTTP请求数）、QPS（每秒查询数）等。

在系统并发数由小逐渐增大的过程中（这个过程也伴随着服务器系统资源消耗逐渐增大），系统吞吐量先是逐渐增加，达到一个极限后，随着并发数的增加反而下降，达到系统崩溃点后，系统资源耗尽，吞吐量为零。

而这个过程中，响应时间则是先保持小幅上升，到达吞吐量极限后，快速上升，到达系统崩溃点后，系统失去响应。系统吞吐量、系统并发数及响应时间之间的关系将在本章后面内容中介绍。

网站性能优化的目的，除了改善用户体验的响应时间，还要尽量提高系统吞吐量，最大限度利用服务器资源。

对于大型互联网服务，吞吐量是我们系统性能服务的重要指标。

它是描述服务器或操作系统性能的一些数据指标。

包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等指标。

这些指标也是系统监控的重要参数，对这些指标设置报警阈值，当监控系统发现性能计数器超过阈值时，就向运维和开发人员报警，及时发现处理系统异常。

System Load即系统负载，指当前正在被CPU执行和等待被CPU执行的进程数目总和，是反映系统忙闲程度的重要指标。多核CPU的情况下，完美情况是所有CPU都在使用，没有进程在等待处理，所以Load的理想值是CPU的数目。当Load值低于CPU数目的时候，表示CPU有空闲，资源存在浪费；

当Load值高于CPU数目的时候，表示进程在排队等待CPU调度，表示系统资源不足，影响应用程序的执行性能。在Linux系统中使用top命令查看，该值是三个浮点数，表示最近1分钟，10分钟，15分钟的运行队列平均进程数。

通过本篇我们知道了我们做性能评估必须知道的性能指标。

在下一篇文章开始我们就会通过去讲解具体的技术方案，帮助大家彻底掌握如何构造高性能的大型互联网服务。