### 一、压测背景
>以前:未出社会之前经常用AB工具来压测自己的 nginx 欢迎页面,看着服务器的资源从20%到100%,发现原来一个开源的工具都可以把一台4C8G的虚拟机压爆满,然后就陷入沉思,低成本的压测都可以造成一台虚拟机的资源满负载,而且还是个静态页面,那如果发生在企业身上会如何?造成的损失远远高于压测方,后果不敢想象。
>现在:我承认以前太天真了,既然有压测方,那肯定有防御方,遇到恶意压测他人网站的,直接通过各种全家桶拉黑、屏蔽掉就好了。那对于现在企业来说,各人觉得最大的价值就是探测资源性能、资源容量合理规划、增强业务稳定SLA、减少事故发生,这个对于测试还是运维来说都是天大的好事,也是价值的体现。
>未来:压测的普适性,对企业带来的价值不止探测资源性能、资源容量合理规划,还有技术架构升级验证、业务系统上线测试、业务峰值稳定性测试等等,通过压测清楚资源的能力,降低盲目预估的风险,提高服务的可用性和稳定性。
#### 所以为什么要做压测?
压测的目的就是通过压测(模拟真实用户的行为),测算出机器的性能(单台机器的QPS),从而推算出系统在承受指定用户数(100W)时,需要多少机器能支撑得住压测是在上线前为了应对未来可能达到的用户数量的一次预估(提前演练),压测以后通过优化程序的性能或准备充足的机器,来保证用户的体验。
### 二、压测工具
1.工具说明
AB:ApacheBench 是 Apache服务器自带的一个web压力测试工具,简称ab。ab又是一个命令行工具,对发起负载的本机要求很低,根据ab命令可以创建很多的并发访问线程,模拟多个访问者同时对某一URL地址进行访问,因此可以用来测试目标服务器的负载压力。总的来说ab工具小巧简单、非常轻量化的压测工具,上手学习较快,可以提供需要的基本性能指标,但是没有图形化结果,不能监控。
Jmeter:Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试,它最初被设计用于Web应用测试,但后来扩展到其他测试领域。JMeter能够对应用程序做功能/回归测试,通过创建带有断言的脚本来验证你的程序返回了你期望的结果。
LoadRunner:LR是HP推出的一种预测系统行为和性能的负载测试工具,通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,分为Windows 版本和Unix 版本。LoadRunner能够对整个企业架构进行测试。企业也能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。也能预测系统行为并优化系统性能。商业版支持录屏+脚本的方式。
阿里云PTS:PTS(Performance Testing Service)是面向所有技术背景人员的云化测试工具。有别于传统工具的繁复,PTS以互联网化的交互,提供性能测试、API调试和监测等多种能力。自研和适配开源的功能都可以轻松模拟任意体量的用户访问业务的场景,任务随时发起,免去繁琐的搭建和维护成本。更是紧密结合监控、流控等兄弟产品提供一站式高可用能力,高效检验和管理业务性能。当然也可以模拟黑客对业务系统进行全面深入的安全测试,
2.常用工具对比
| 对比项\压测工具 | Apache Bench(ab) | JMeter | LoadRunner | PTS |
| --- | --- | --- | --- | --- |
| 学习成本 | 低 | 高 | 高 | 低 |
| 安装部署成本 |低 | 高 | 高 | 低 |
| 费用 | 无| 无 | 有 | 有 |
| 多协议 | 否 | 是 | 是 | 是 |
| 图形化展示 |否 | 是 | 是 | 是 |
| TPS模式 | 否 | 否 | 否 | 是 |
| 压测链路、场景编排管理 | 否 | 是 | 是 | 是 |
| 场景录制 | 否 | 是 | 是 | 是 |
| 生态环境强弱 | 弱 | 弱 | 弱 | 强 |
| 监控指标是否完备 |否 | 否 | 否 | 是 |
| 流量地域定制 | 否 | 否 | 否 | 是 |
3.压测标准
| 压测类型 | 解释说明 |
| --- | --- |
| 压力测试(Stress Testing) | 也称之为强度测试,测试一个系统的最大抗压能力,在强负载(大数据、高并发)的情况下,测试系统所能承受的最大压力,预估系统的瓶颈 |
| 并发测试(Concurrency Testing) | 通过模拟很多用户同一时刻访问系统或对系统某一个功能进行操作,来测试系统的性能,从中发现问题(并发读写、线程控制、资源争抢) |
| 耐久性测试(Configuration Testing) | 通过对系统在大负荷的条件下长时间运行,测试系统、机器的长时间运行下的状况,从中发现问题(内存泄漏、数据库连接池不释放、资源不回收) |
#### 系统性能指标
3.1 交易响应时间
>响应时间指用户从客户端发起一个请求开始,到客户端接收到从服务器端返回的响应结束,整个过程所耗费的时间。在性能检测中一般以压力发起端至被压测服务器返回处理结果的时间为计量,单位一般为秒或毫秒。平均响应时间指系统稳定运行时间段内,同一交易的平均响应时间。一般而言,交易响应时间均指平均响应时间。 平均响应时间指标值应根据不同的交易分别设定,一般情况下,分为复杂交易响应时间、简单交易响应时间、特殊交易响应时间。其中,特殊交易响应时间的设定必须明确该交易在响应时间方面的特殊性。
Response Time: 简称RT
>不同行业不同业务可接受的响应时间是不同的,一般情况,对于在线实时交易:
>互联网企业:500毫秒以下,例如淘宝业务10毫秒左右。
>金融企业:1秒以下为佳,部分复杂业务3秒以下。
>保险企业:3秒以下为佳。
>制造业:5秒以下为佳。
对于批量交易:
>时间窗口:即整个压测过程的时间,不同数据量则时间不一样,例如双11和99大促,数据量级不一样则时间窗口不同。大数据量的情况下,2小时内可完成压测。
3.2 系统处理能力
>系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。 系统处理能力通过系统每秒钟能够处理的交易数量来评价,交易有两种理解:一是业务人员角度的一笔业务过程;二是系统角度的一次交易申请和响应过程。前者称为业务交易过程,后者称为事务。两种交易指标都可以评价应用系统的处理能力。一般的建议与系统交易日志保持一致,以便于统计业务量或者交易量。系统处理能力指标是技术测试活动中重要指标。
一般情况下,用以下指标来度量:
>HPS(Hits Per Second) :每秒点击次数,单位是次/秒。
>TPS(Transaction per Second):系统每秒处理交易数,单位是笔/秒。
>QPS(Query per Second):系统每秒处理查询次数,单位是次/秒。 对于互联网业务中,如果某些业务有且仅有一个请求连接,那么TPS=QPS=HPS,