**1. 性能**
[TOC]
## 1.1 监控指标
在系统并发数由小逐渐增大的过程中(这个过程也伴随着服务器系统资源消耗逐渐增大),系统吞吐量先是逐渐增加,达到一个极限后,随着并发数的增加反而下降,达到系统崩溃点后,系统资源耗尽、吞吐量为零。
而这个过程中,响应时间则是先保持小幅上升,到达吞吐量极限后,快速上升,到达系统崩溃点后,系统失去响应。
### 1.1.1 响应时间
`响应时间`:指应用执行一个操作需要的时间(从发出请求开始到收到最后响应数据所需的时间)。是系统最重要的性能指标,直观地反映了系统的“快慢”。
:-: 常用系统操作响应时间表
![常用系统操作响应时间表](https://box.kancloud.cn/18fe24690d195a182fa470791ad25e66_2368x1080.jpg)
### 1.1.2 并发数
`并发数`:指系统能同时处理的请求数目。对于网站而言,即是指网站的并发用户数(同时提交请求的用户数目)。
>[info] 网站系统用户数 >> 网站在线用户数 >> 网站并发用户数
### 1.1.3 吞吐量
`吞吐量`:指单位时间内系统处理的请求数量,体现系统的整体处理能力。
* TPS(每秒事务数),是吞吐量的常用量化指标。
* QPS(每秒查询数)
* HPS(每秒HTTP请求数)
### 1.1.4 性能计数器
* System Load:系统负载
>[] 指当前正在被CPU执行和等待被CPU执行的进程数总和,是反映系统忙闲程度的重要指标。
* 对象与进程数
* 内存使用
* CPU使用
* 磁盘I/O
* 网络I/O
上述指标也是系统监控的重要参数,对这些指标设置报警阈值,当监控系统发现性能计数器超过阈值时,就向运维和开发人员报警,及时发现处理系统异常。
**多核CPU的System Load**
* 完美情况是,所有CPU 都在使用,没有进程在等待处理,所以Load的理想值是CPU的数目。
* 当Load值低于 CPU数目的时候,表示CPU有空闲,资源存在浪费;
* 当Load值高于CPU数目的时候,表示进程在排队等待CPU调度,表示系统资源不足,影响应用程序的执行性能。
在Linux系统中使用`top`命令查看,System Load是三个浮点数,表示最近1分钟,5分钟,15分钟的运行队列平均进程数,如下图所示。
![](https://box.kancloud.cn/3b27a1840b46c9664ba630699363e10b_2964x148.jpg)
:-: Linux命令行查看系统负载
## 1.2 性能测试
### 1.2.1 响应时间
测试程序通过模拟应用程序,记录收到响应和发出请求之间的时间差来计算系统响应时间。
实践中通常采用的办法是重复请求,比如一个请求操作重复执行一万次,测试一万次执行需要的总响应时间之和,然后除以一万,得到单次请求的响应时间。
### 1.2.2 并发数
测试程序通过多线程模拟并发用户的办法来测试系统的并发处理能力。
为了真实模拟用户行为,测试程序并不是启动多线程然后不停地发送请求,而是在两次请求之间加入一个随机等待时间, 这个时间被称作思考时间。
### 1.2.3 测试方法
`性能测试`是一个不断对系统增加访问压力,以获得系统性能指标、最大负载能力、最大压力承受能力的过程。 所谓的增加访问压力, 在系统测试环境中,就是不断增加测试程序的并发请求数。一般说来,性能测试遵循下图所示的抛物线规律。
![](https://box.kancloud.cn/5c072ac7a593e1dda57e9c6ec907cfd3_2480x1140.jpg)
:-: 性能测试曲线
上图中的a~b段是系统的`日常运行区间`,系统使用较少的资源就达到较好的处理能力。
上图中c点是系统的`最大负载点`。超过这个点后,再继续加大并发请求数,系统的处理能力反而下降,而资源的消耗更多,直到资源消耗达到极限(d点)。
d点是系统的`崩溃点`。超过这个点继续加大并发请求数,系统不能再处理任何请求。
`用户访问的等待时间`:性能测试反应的是系统在实际生产环境中使用时,随着用户并发访问数量的增加,系统的处理能力。 与性能曲线相对应的是用户访问的等待时间 ( 系统响应时间),如下图所示。
![](https://box.kancloud.cn/bc0a82df69aeeabc260a515853c7d799_2472x1080.jpg)
:-: 并发用户访问响应时间曲线
在日常运行区间(a~b),系统可以获得最好的用户响应时间,但随着并发用户数的增加,响应延迟越来越大,直到系统崩溃,用户失去响应。
![](https://box.kancloud.cn/be183d4844aa086cdb43f67981a2e118_2504x712.jpg)
:-: 性能测试结果报告
## 1.3 性能分析
如果性能测试结果不能满足设计或业务需求,那么就需要寻找系统瓶颈,分而治之,逐步优化。
大型网站结构复杂,用户从浏览器发出请求直到数据库完成操作事务,中间需要经过很多环节,如果测试或者用户报告网站响应缓慢,存在性能问题,必须对请求经历的各个环节进行分析,排查可能出现性能瓶颈的地方,定位问题。
* **性能分析方法**:
排查一个网站的性能 瓶颈和排查一个程序的性能瓶颈的手法基本相同:
1. 检查请求处理的各个环节的日志,分析哪个环节响应时间不合理、超过预期;
2. 然后检查监控数据,分析影响性能的主要因素是内存、磁盘、网络、还是CPU,是代码问题还是架构设计不合理,或者系统资源确实不足。
### 1.3.1 前端(用户角度)
用户在浏览器上直观感受到的网站响应速度的快慢。
**用户感受到的时间:**
* 用户计算机和网站服务器通信时间
* 网站服务器处理的时间
* 用户计算机浏览器购置请求数据的时间
* 用户计算机浏览器解析响应数据的时间
![](https://box.kancloud.cn/2208da7f2370f98fe9acd8eaa3b00b40_2992x456.jpg)
**优化方法:**
1. 尽可能快地显示用户感兴趣的内容
* 优化页面HTML式样、
* 利用浏览器的并发和异步特性、
* 调整浏览器的缓存策略
2. 尽可能近地获取页面内容
* 使用CDN服务
* 使用反向代理
### 1.3.2 应用程序、编码(开发人员角度)
**优化方法:**
1. 使用`缓存`加速数据读取
2. 使用`集群`提高吞吐能力
3. 使用`异步`消息加快请求响应和实现削峰
4. 使用`代码优化`手段改善程序性能。
### 1.3.3 运维(运维人员角度)
**优化方法:**
1. 建设优化骨干网。
2. 使用高性价比定制服务器。
3. 利用虚拟化技术优化资源利用。
### 1.3.4 性能优化的目的
* 改善用户体验
* 减少用户操作的响应时间
* 尽量提高系统吞吐量
* 最大限度利用服务器资源
## 1.4 性能优化
根据网站分层架构,可分为web前端、应用服务器、存储服务器性能优化3大类
### 1.4.1 web前端
1. 浏览器访问优化
* 减少http请求
* 使用浏览器缓存
* 启用压缩
* CSS放在网页最上面,JavaScript放网页最下面
* 减少Cookie传输
2. CDN加速
3. 反向代理
### 1.4.2 应用服务器
1. 分布式缓存
* `JBoss Cache`:需要更新同步
* `Memcached`:不互相通信,丰富客户端程序(Java、php、Perl、Python、Ruby、C/C++/C#),海量数据可伸缩
2. 异步操作
3. 使用集群
4. 代码优化
* 多线程。保证线程安全的编码手段:将对象设计为无状态对象;使用局部变量;并发访问资源时使用锁。
* 资源复用。单例(Singleton);对象池(Object Pool)
* 数据结构。Hash表;字符串Hash散列算法(Time33)
* 垃圾回收。JVM的堆(heap)和堆栈(stack)。堆空间又分为Young Generation/Old Generation
### 1.4.3 存储服务器
在网站应用中,海量的数据读写对磁盘访问造成巨大压力,虽然可以通过 Cache解决一部分数据读压力,但是很多时候,磁盘仍然是系统最严重的瓶颈。而且磁盘中存储的数据是网站最重要的资产,磁盘的可用性和容错性也至关重要。
1. 机械硬盘
2. 固态硬盘(SSD)
3. B+树
`B+树`:传统关系型数据库常使用的数据结构。是一种专门针对磁盘存储而优化的N叉排序树。
4. LSM树
`LSM树`:NoSQL数据库常使用的数据结构。可看作是一个N阶合并树。
5. RAID
在传统关系型数据库及文件系统中应用较为广泛。
6. HDFS(Hadoop File System)
HDFS配合MapReduce等并行计算框架进行大数据处理时,可以在整个集群上并发读写访问所有磁盘,无需RAID支持。
- 软件工程
- 1. 基础
- 计算
- 网络
- 存储
- 2. 开发/运维
- 微服务
- 容器化(Docker)
- 容器网络
- 持续集成
- 持续发布
- 3. 架构
- 操作系统
- Linux服务器
- windows
- 内存
- 应用软件
- 前端
- 后端
- 数据库
- 协议
- 服务
- 分布式
- LNMP+Vue.js
- web网站架构技术
- 架构演化
- 架构分层
- Layer1. Frontend
- Layer2. Application
- Layer3. Service
- Layer4. Storage
- Layer5. Backend
- Layer6. Operation
- Layer7. Security
- Layer8. DataCenter
- 架构模式
- 架构要素
- 1. Performance
- 2. Availability
- 3. 可伸缩性
- 4. 可扩展性
- 5. 安全
- 6. 成本
- 4. 开发项目
- vue-php