“大型网站架构设计”—— 网站性能测试

2019 年 10 月 25 日
笔记

嘿，笔者的个人博客已经孵化完成啦?，欢迎大家来逛逛。以后的文章也会在博客进行首发，快来关注我吧，我们继续一起探讨技术一同进步~

本文主要是笔者对《大型网站技术架构》一书的总结归纳。主要通过两种方式展现，一是通过“思维导图”的形式输出；另一种，就是本文以图文的形式更加详细和展开的描述‘大型网站技术架构’的方方面面。

三，网站性能测试

性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。

3.1 不同视角下的网站性能

用户视角的网站性能从用户角度，网站性能就是用户在浏览器上直观感受到的网站响应速度快还是慢。

用户视角的网站性能在实践中，使用一些前端架构优化时段，通过优化页面 HTML 样式、利用浏览器端的并发和异步特性、调整浏览器缓存策略、使用 CDN 服务、反向代理等手段，使浏览器尽快地显示用户感兴趣的内容、尽可能近地获取页面内容，即使不优化应用程序和架构，也可以很大程度地改善用户视角下的网站性能。

开发人员视角的网站性能开发人员关注的主要是应用程序本身及其相关子系统的性能，包括： a）响应延迟 ———— 优化手段：使用缓存加速数据读取； b）系统吞吐量 ———— 优化手段：使用集群提高吞吐能力； c）并发处理能力 ———— 优化手段：使用异步消息加快请求响应以及实现削峰； d）系统稳定性 ———— 优化手段：使用代码优化手段改善程序性能等技术指标。主要的优化手段有： a）使用缓存加速数据读取； b）使用集群提高吞吐能力； c）使用异步消息加快请求响应以及实现削峰； d）使用代码优化手段改善程序性能
运维人员视角的网站性能运维人员更关注基础设施性能和资源利用率，如网络运营商的带宽能力、服务器硬件的配置、数据中心网络架构、服务器和网络带宽的资源利用率等。主要的优化手段有建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用等。

3.2 性能测试指标

从开发和测试人员的视角，网站性能测试的主要指标有： a）响应时间； b）并发数； c）吞吐量； d）性能计数器；等。

响应时间响应时间：指应用执行一个操作需要的时间，包括从发出请求开始到收到最后响应数据所需的时间。响应时间是系统最重要的性能指标。如果测试目标操作本身需要花费的时间极少，比如几微秒，那么测试程序就无法测试得到系统的响应时间。实践中通常采用的办法是重复请求，比如一个请求操作重复执行一万次，然后求平均单次请求的响应时间。
并发数并发数：指系统能够同时处理请求的数目，这个数字也反映了系统的负载特性。网站系统用户 >> 网站在线用户数 >> 网站并发用户数根据产品特性和运营手段，推算在线用户数和并发用户数。
吞吐量吞吐量：指单位时间内系统处理的请求数量，体现系统的整体处理能力。 TPS（每秒事务数）是吞吐量的一个常量化指标，此外还有 HPS（每秒 HTTP 请求数）、QPS（每秒查询数）等。 TPS ———— Transactions Per Second（客户端）它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。 QPS ———— Question Per Second（服务端） QPS 是一台服务器每秒能够响应的查询次数，是对一个特定的查询，服务器在规定时间内所处理流量多少的衡量标准。在系统并发数由小逐渐增大的过程中（这个过程也伴随着服务器系统资源消耗逐渐增大），系统吞吐量是先逐渐增加，达到一个极限后，随着并发数的增加反而下降，达到系统崩溃点后，系统资源耗尽，吞吐量为零。而这个过程中，响应时间则是先保持小幅上升，到达吞吐量极限后，快速上升，到达系统崩溃点后，系统失去响应。系统吞吐量和系统并发数，以及响应时间的关系可以形象地理解为高速公路的通行状况：吞吐量是每天通过收费站的车辆数目（可以换算成收费站收取的高速费），并发数是高速公路上的正在行驶的车辆数目，响应时间是车速。车辆很少时，车速很快，但是收到的高速费也相应较少；随着高速公路上车辆数目的增多，车速略受影响，但是收到的高速费增加很快；随着车辆的继续增加，车速变得越来越慢，高速公路越来越堵，收费不增反降；如果车流量继续增加，超过某个极限后，任何偶然因素都会导致高速全部瘫痪，车走不动，费当然也收不着，而高速公路成了停车场（资源耗尽）。
性能计数器性能计数器：它是描述服务器或操作系统性能的一些数据指标。包括： a）System Load； b）对象与线程数； c）内存使用； d）CPU 使用； e）磁盘与网络 I/O；等指标。 System Load 即系统负载，指当前正在被 CPU 执行和等待被 CPU 执行的进程数目总和，是反映系统忙闲程度的重要指标。多核 CPU 的情况下，完美情况是所有 CPU 都在使用，没有进程在等待处理，所以 Load 的理想值是 CPU 的数目。

3.3 性能测试方法

性能测试是一个总体，具体可细分为： ① 性能测试 ② 负载测试 ③ 压力测试 ④ 稳定性测试在不同生成环境、不同时间的请求压力是不均匀的，呈波浪特性，因此为了更好地模拟生产环境，稳定性测试也应不均匀地对系统施加压力。

一般来说，性能测试遵循如图4.3所示的抛物线规律

性能测试曲线

在开始阶段，随着并发请求数目的增加，系统使用较少的资源就达到较好的处理能力（a~b段），这一段是网站的日常运行区间，网站的绝大部分访问负载压力都集中在一段区间，被称作“性能测试”，测试目标是评估系统性能是否符合需求以及设计目标；随着压力的持续增加，系统处理能力增加变缓，直到达到一个最大值（c点），这是系统的最大负载点，这一段被称作“负载测试”。测试目标是评估当系统因为突发事件超出日常访问压力的情况下，保证系统正常运行情况下能够承受的最大访问负载压力；超过这个点后，再增加压力，系统的处理能力反而下降，而资源消耗却更多，直到资源消耗达到极限（d点），这个点可以看作是系统的崩溃点，超过这个点继续加大并发请求数目，系统不能再处理任何请求，这一段被称作“压力测试”，测试目标是评估可能导致系统崩溃的最大访问负载压力。

与性能曲线相对应的是用户访问的等待时间（系统响应时间）：

并发用户访问响应时间曲线

3.4 性能测试报告

测试结果报告应该能够反映上述性能测试曲线的规律，阅读者可以得到系统性能是否满足设计目标和业务需求、系统最大负载能力、系统最大压力承受能力等重要信息。

性能测试结果报告：

性能测试结果报告

3.5 性能优化策略

性能分析排除一个网站的性能瓶颈和排查一个程序的性能瓶颈的手法基本相同：检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期；然后检查监控数据，分析影响性能的主要因素是内存、磁盘、网络、还是 CPU，是代码问题还是架构设计不合理，或者系统资源确实不足。
性能优化性能优化，根据网站分层架构，可分为： ① Web 前端性能优化 ② 应用服务器性能优化 ③ 存储服务器性能优化