精华内容
下载资源
问答
  • 服务器可靠性指标

    千次阅读 2015-12-28 14:10:52
    什么是“5个9”(99.999%)的可靠性

    什么是“5个9”(99.999%)的可靠性?

    在软件系统的高可靠性(也称为可用性,英文描述为HA,High Available)里有个衡量其可靠性的标准——X个9,这个X是代表数字3~5。X个9表示在软件系统1年时间的使用过程中,系统可以正常使用时间与总时间(1年)之比,我们通过下面的计算来感受下X个9在不同级别的可靠性差异。

    • 3个9:(1-99.9%)*365*24=8.76小时,表示该软件系统在连续运行1年时间里最多可能的业务中断时间是8.76小时。
    • 4个9:(1-99.99%)*365*24=0.876小时=52.6分钟,表示该软件系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
    • 5个9:(1-99.999%)*365*24*60=5.26分钟,表示该软件系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。

    那么X个9里的X只代表数字3~5,为什么没有1~2,也没有大于6的呢?我们接着往下计算:

    • 1个9:(1-90%)*365=36.5天
    • 2个9:(1-99%)*365=3.65天
    • 6个9:(1-99.9999%)*365*24*60*60=31秒

    可以看到1个9和、2个9分别表示一年时间内业务可能中断的时间是36.5天、3.65天,这种级别的可靠性或许还不配使用“可靠性”这个词;而6个9则表示一年内业务中断时间最多是31秒,那么这个级别的可靠性并非实现不了,而是要做到从5个9》6个9的可靠性提升的话,后者需要付出比前者几倍的成本,所以在企业里大家都只谈(3~5)个9。

    转载请注明:运维派 » 什么是“5个9”(99.999%)的可靠性?

    展开全文
  • 可靠性测试竟如此容易

    千次阅读 2019-09-06 14:06:52
    分布式系统具有廉价高效的特点,利用性能相对一般的PC横向扩展,提升服务器性能,通过软件来保障系统的高可靠性。 由于分布式系统存在API接口通信、微服务架构、节点规模大等特点,增加了系统的复杂性和出错的概率...

    随着互联网的快速发展,传统的单工程的性能瓶颈越发明显,分布式系统的优点越发突出。分布式系统具有廉价高效的特点,利用性能相对一般的PC横向扩展,提升服务器性能,通过软件来保障系统的高可靠性。

    由于分布式系统存在API接口通信、微服务架构、节点规模大等特点,增加了系统的复杂性和出错的概率,从而很难确保系统的容错机制得到充分的验证,依赖自动化工具来完成对系统端到端验证是不可避免的。

    Netflix和类似互联网企业构建的大规模的分布式系统,不可避免地会发生如机器崩溃和网络延迟等故障。为了给客户提供“永远在线”的体验,建立系统可以可靠运行的信心需要软件能够检测、处理各种错误情况,除了少量发生概率较低的极端故障。

    华为云可靠性解决方案

    在业界,混沌工程被定义为“在分布式系统上进行实验, 以建立对系统抵御生产环境中失控条件的能力的信心”

    基于华为在ICT领域10多年的软件可靠性测试经验,以及工程师们的千万个夜以继日,华为云推出了混沌工程领域应用实践的一套完整解决方案。目标是沉淀通用的故障模式,从入门到精通,从研发到生产,层层推进,以在线演练和专业测评来持续暴露问题,从而推动产品全方位的改进。防止失败的最佳方法就是经常失败,在真实环境测试,而不是模拟环境。

    • 全面有效的故障模式库

    基于华为在ICT领域10多年的实践积累和数百产品的实际应用的沉淀,电信领域软件的高要求,我们通过正向分析、事故分析、业界案例分析三个维度建立全面的故障模式库。

    • 精准高效的故障模拟

    我们通过软件模拟各种硬件故障,对应用无侵入,而且跟应用的实现语言无关。

    • 端到端全自动化测评

    我们实现了智能识别故障对象,而且全自动化运行,自动度量KPI,自动实现风险评估,生成测评报告,测试工程可反复执行。防止失败的最佳方法就是经常失败。在真实环境测试,而不是模拟环境。通过我们的端到端全自动化测评,可以实现这个目标。

    华为云混沌工程应用场景

    入门级可靠性测试:手工注入

    功能:提供对Kubernetes集群、弹性云服务器的单业务实例、单故障模式的注入。

    适用场景:开发人员针对确定故障的自验证;测试人员针对可靠性问题回归验证等。

    特点:操作简单,故障注入/清除结果及系统的表现清晰可见。

    手工注入是混沌工程的入门级功能,操作非常容易,结果直接清晰。

    • 首先在服务所在的容器集群或者节点上安装探针,一键安装,秒级创建,速度很快;
    • 然后选择注入对象和注入的故障,还可以选择设置告警、CPTS压测工程,就可以完成一次故障注入;
    • 再接着就是以5分钟为维度获取监控数据生成测试报告;
    • 最后你就可以基于报告来评估服务可靠性的质量了。

    全流程可视化操作,只用鼠标点点点就可以了;简单易用,使用门槛低,非常方便开发者和测试人员进行基本的可靠性测试。

    进阶级可靠性测试:故障演练

    功能:提供对单工作负载的随机故障注入,预置了多种入门级和进阶级演练场景。

    适用场景:线下随机故障注入测试;线上例行故障演练、专项演练等。

    特点:模型化的场景定义、灵活的编排调度、丰富的评估报告。

    故障演练主要使用场景是线上例行故障演练和专项演练。相比于手工注入,故障演练会提供多种入门级和进阶级的演练场景。上图为传统的手工演练流程,与混沌工程提供的故障演练能力对比。

    三、四年前我们还处于传统手工演练阶段,全流程的手工进行,后续逐步演变为现在混沌工程提供的全自动化故障演练能力,经我们自己实际使用对比,现在的自动化演练过程比手工更准确和规范,避免人为导致的差错;可靠性专项测试人员投入的时间可以减少80%,端到端效率提升10倍以上。

    我们提供如下的预置模板,同时也支持自定义演练任务。

    高阶级可靠性测试:自动测评

    功能:提供对多工作负载全量的可靠性测评,即将支持

    适用场景:云服务的全量可靠性测评;不同服务、不同版本的可靠性能力对比。

    特点:智能对象识别、自动用例生成、无脚本化执行、自动KPI度量、丰富的评估报告。

    自动测评最大的特点就是智能对象识别、自动用例生成、无需定制脚本的全自动化执行、自动KPI度量生成丰富的评估报告,可以对不同服务、不同版本的可靠性能力进行对比。

    自动测评服务的智能对象识别能力,保证了故障对象覆盖的全面性,能有效避免人工测试出现的遗漏。自动用例生成与无脚本化执行,大幅节省了用例设计和自动化脚本编写的工作,同时降低了自动化可靠性测试对人员技能的要求。

    系统预置了3种常见场景模板,同时支持用户自定义。既可以用预置目标快速创建任务,也可以灵活的定制任务。

    测评报告

    混沌工程通过结合华为云上的CCE、ECS、CPTS、AOM、APM等服务,提供了一套完整的端到端的可靠性测试解决方案,解决了测什么、如何测、如何评价的问题。

    可靠性质量评估架构

    在华为云上,云服务部署的载体要么是ECS的弹性云服务器,要么是CCE的容器集群,我们现在已经支持对CCE容器集群和弹性云服务器ECS(linux)进行故障注入。

    CPTS服务可以实现对应用接口的压测,在故障注入的同时运行,通过CPTS的报告用来评估故障对业务的影响。

    AOM可以完成对容器、主机的资源监控,以及自定义阈值告警,故障注入后相关的监控数据和告警数据会被写入混沌工程测试任务的报告中,然后根据可靠性质量评估方法实现自动KPI度量,生成评估报告。

    APM提供了调用链功能,在故障注入后,利用调用链可以快速完成问题定位分析。

    可靠性质量评估方法上,我们采用的是基于可靠性关键质量属性的KPI评估方式,如下图。从故障模式维度测试对象维度对KPI进行分析,可以针对自己的服务特性,自主调整评估的参数,然后生成测评报告。

    评估属性和方法

    目前华为云混沌工程正在公测中,可免费使用,公测申请免审批,申请即可用,详情点击这里,欢迎大家试用。

    戳→传送门

    展开全文
  • 从而团队提出对平台进行稳定性分析,通过给系统施加一定业务压力大情况下,使系统持续运行一段时间,以此来检测系统是否稳定运行(下统称稳定性测试或测试)。 1.2 服务说明 平台运行的服务包括系统服务和业务服务,...

    注:
    1. 程序员做的测试
    2. 测试报告文档原稿在上传审核中,请等待
    审核好了:https://download.csdn.net/download/yiquan_yang/12694138

    1 概述

    1.1 背景

    系统的稳定性是系统长期稳定运行能力,需要时间累积才能度量。平台的某些问题需要达到一定时间、一定的使用量后才会暴露出来。如内存泄漏,系统运行过程中发现部分服务的部分接口会发生服务不可达的情况。
    从而团队提出对平台进行稳定性分析,通过给系统施加一定业务压力大情况下,使系统持续运行一段时间,以此来检测系统是否稳定运行(下统称稳定性测试或测试)。

    1.2 服务说明

    平台运行的服务包括系统服务和业务服务,系统服务包括Consul、Redis、Cap、RabbitMQ、Exceptionless套件等,业务服务包括用户服务、基础数据服务、网关服务,详细见《xxx发布标准》。本次测试针对三个业务服务,对系统外界只有网关可视(测试对象统称系统或平台),故测试对象为一个服务。

    1.2.1 服务器部署

    本次测试采用单机环境,所有服务全部配置在同一台服务上,数据库部署在另一台机器上。

    Manufacturer: Microsoft Corporation
    Product Name: Virtual Machine
    IP:192.168.4.57(业务服务)、192.168.4.253(数据库)
    CPU:Intel® Xeon® Gold 5117 CPU @ 2.00GHz (物理CPU个数 1,核数:16)
    Memory:16G

    OS:CentOS Linux release 7.6.1810 (Core)
    PostgreSQL:PostgreSQL 11.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit
    Docker:Docker version 19.03.5, build 633a0ea
    其他软件环境见1.3测试工具

    1.2.2 服务配置

    其中系统中存在大量配置,其中影响测试的配置包括:
    xx:单服务接口最大并发数 设置为 1万
    xxx:请求执行超时时间 设置为 30s
    xxx:是否启用性能追踪组件 设置为 不启用
    xxxxxx:是否启用服务接口缓存拦截 设置为 启用
    Xxxxxxxx:是否启用集中式日志 设置为 不启用

    1.3 测试工具

    Apache JMeter(5.2.1):测试客户端,作为虚拟用户脚本产生器(Virtual User Generator)、压力产生器(player)、用户代理(Agent)、压力调度和监控系统(Controller)、压力结果分析工具(Analysis)
    1)安装前需要安装Java,本次测试使用jre1.8.0_241
    2)客户端如需则自行汉化
    3)安装服务资源监控器插件,从官网下载安装Plugins Manager,并安装jpgc - Standard Set
    ServerAgent(2.2.1):服务器Agent,提供服务器资源使用数据
    1)服务器需要安装Java,本测试使用java version “1.8.0_241”
    2)进入ServerAgent存放目录,使用命令“./startAgent.sh”启动Agent
    3)需要确保端口4444能够访问,本测试关闭了服务器防火墙

    1.4 稳定标准

    在一定的配置情况下
    CPU:单颗,16核
    Memory:16G
    在以上硬件环境下满足
    1)系统指标
    满足100个/s的最大并发。请求100%请求成功,且平均响应时间小于5s;
    2)资源指标
    在单位时间内(5s),CPU最大使用率不能持续超过95%,内存最大占用率不能持续超过95%。
    1.5 关键字定义
    1.6 排除干扰项
    不考虑断电,硬件资源损坏情况

    2 测试方案

    本次测试采取负载测试并发测试可靠性测试。测试方案采取模拟真实用户使用场景,模拟指定人数在一定时间点击界面产生的请求数。
    在并发10(单位个/s)、20、40、80、160、500、1000、2000的基准下,调整用户数(虚拟用户用一个线程,下统称线程数)、点击准备时间(用户点击时间模拟时间,下称Ramp-up单位秒)和用户点击次数(下称循环),例如10个用户,每个用户每5秒点击1次,则线程数为10,Ramp-up为5,循环数为1。详细测试策略请看2.1。

    对登录、数据新增(用户)、编辑(用户)、获取(用户)和删除(用户)进行负载测试,获得其稳定负载值。
    对全站使用策略100-100-1-1进行并发测试,挑选用户服务所有接口。基础数据服务中挑选和用户服务关联的功能接口5个,组织结构接口4个,和用户服务无关的行政区3个接口。具体接口请查看附件1。
    对全站进行可靠性测试,根据以上测试接口,选择稳定的并发数后持续测试-模拟时长8+小时。
    稳定性测试是通过运行状态和资源指标的2个方面来分析及评估系统的稳定性,请求记录项响应的时间平均值、最小值、最大值、标准偏差、异常(百分比)、吞吐量、接收、发送、平均字节数,服务器资源指标CPU、Memory,在此额外添加记录数据库数据。通过调试测试策略、分析实验数据得出相关系统稳定性的结论,从而达到平台能力验证、规划能力、性能调优、缺陷发现等目的。

    评价定义
    稳定:无异常,平均值和变成偏差差距较少且不高;
    普通:无异常,平均值小于5秒,平均值和变成偏差差距较少;
    一般:无异常,平均值大于5秒,平均值和变成偏差差距较大;
    差:存在异常,异常率小于30%;
    极差:存在异常,异常率大于登录30%;

    2.1 测试策略

    测试策略

    编号 并发数 线程数 Ramp-up 循环 场景 备注
    10-1-1-10 10 1 1 10 1个用户,每个用户每秒提交10次请求
    10-10-1-1 10 10 1 1 10个用户,每个用户每秒提交1次请求
    10-20-2-1 10 20 2 1 20个用户,每个用户2秒内提交1次请求
    10-20-4-2 10 20 4 2 20个用户,每个用户4秒内提交2次请求
    10-40-4-1 10 40 4 1 40个用户,每个用户4秒内提交1次请求
    10-40-8-2 10 40 8 2 40个用户,每个用户8秒内提交2次请求
    10-80-8-1 10 80 8 1 80个用户,每个用户8秒内提交1次请求
    10-80-16-2 10 80 16 2 80个用户,每个用户16秒内提交2次请求
    。。。。。。

    2.2 测试脚本

    测试脚本分为登录和服务接口两个线程组,模拟用户登录后进行系统。
    1)在测试前定义测试配置变量,查看图2.2-1,使用变量
    在这里插入图片描述

    图2.2-1 定义线程组中配置变量
    在这里插入图片描述
    图2.2-2 使用线程组中配置变量
    2)用户登录成功后将Token写入全局变量中,服务接口线程组统一使用该Token。
    3)创建数据类接口,相关使用值在BeanShell预处理程序中创建,创建完成后在JSON提取器中提取相关值,供请求组装报文,例如用户,产生用户姓名请查看图2.2-3,使用查看图2.2-4,提取值查看图2.2-5。
    在这里插入图片描述

    图2.2-3 定义线程组中创建用户姓名变量
    在这里插入图片描述

    图2.2-4 使用线程组中创建用户姓名变量
    在这里插入图片描述

    图2.2-5 使用线程组中创建用户姓名变量
    4)编辑、获取和删除接口需要的主键ID从创建请求成功后提取。
    5)脚本中还包括HTTP头信息管理器(HTTP Header Manager),相关运行结果项察看结果树(请求头,Body,Response结果)、用表格察看结果(请求开始时间、运行时间等)、汇总报告(样本、最小值、最大值、错误率等)、jp@pc-PerMon Metrics Collector(服务器资源监视器)、汇总图(请求时间管理:样本、中位数、平均值、90%百分比等)
    6)整体脚本编写完成后,请查看图2.2-6。
    在这里插入图片描述

    图2.2-5 脚本一览

    3 负载测试

    3.1 测试样本

    3.1.1 登录接口

    1)查看结果树

    登录接口(线程池100)

    策略编号 样本 平均值 最小值 最大值 标准偏差 异常% 吞吐量 接收 发送 平均字节数 评价
    100-50-1-2 100 383 40 1181 294.89 0 55.43 30.96 30.92 572.00 稳定
    100-100-1-1 100 244 41 962 192.77 0 68.63 38.34 40.37 572.00 稳定
    100-200-2-1 200 768 39 2969 716.67 0 55.87 31.21 33.03 572.00 稳定
    100-1000-10-1 1000 50779 38 79358 29633.03 0.739 12.17 3.97 7.35 334.04 极差
    100-1000-20-2 很卡无法测试

    登录接口(线程池1000)

    策略编号 样本 平均值 最小值 最大值 标准偏差 异常% 吞吐量 接收 发送 平均字节数 评价
    100-1000-10-1 1040 18037 43 30473 11904.87157 0.15 3.45 1.77 2.07 527.1

    登录接口(线程池1500)

    策略编号 样本 平均值 最小值 最大值 标准偏差 异常% 吞吐量 接收 发送 平均字节数 评价
    100-1000-10-1 1000 4189 32 13070 2803.22 0 54.38 30.59 33.06 576 稳定

    登录接口(使用多个策略连续测试-线程池1500)

    策略编号 样本 平均值 最小值 最大值 标准偏差 异常% 吞吐量 接收 发送 平均字节数 评价
    1-10-10-1
    10-100-10-1
    100-1000-10-1 1000 4189 32 13070 2803.22 0 54.38 30.59 33.06 576 一般
    100-1000-10-1
    100-1000-10-1 3110 5443 34 17675 3858.24 0 21.67 12.19 13.17 576 一般
    100-1000-10-1 4120 4895 30 17675 3654.62 0 13.77 7.75 8.37 576 一般
    1-10-10-1
    1-10-10-1 4130 4883 30 17675 3657.94 0 11.79 6.63 7.16 576

    2)使用多个策略连续测试
    在这里插入图片描述

    jp@pc-PerMon Metrics Collector 服务资源监控
    3)100-1000-10-无线循环(10次+)
    在这里插入图片描述

    CPU占用在30%左右
    内存在30%左右
    4)100-1000-10-2 汇总图
    在这里插入图片描述

    中位数(所有请求响应时间的中间值可认为50%的请求)低于平均值和最大值的一般,比较稳定。
    90%请求在15s内请求完成,在并发高的情况下响应时间会降低,一半以上的会大于6s。但是100%响应,无异常产生。

    3.1.2 创建接口

    创建用户(连续请求两次)
    策略编号 样本 平均值 最小值 最大值 标准偏差 异常% 吞吐量 接收 发送 平均字节数 评价
    100-1000-10-1 2001 79 41 262 20.40 0.00 30.36 8.75 20.55 295 稳定

    各项测试策略表现的非常稳定

    在这里插入图片描述

    在这里插入图片描述

    3.1.3 获取接口

    此接口没有配置缓存拦截,数据直接读库

    获取用户(连续请求两次)

    策略编号 样本 平均值 最小值 最大值 标准偏差 异常% 吞吐量 接收 发送 平均字节数 评价
    100-1000-10-1 2000 21 13 144 7.95 0.00 32.23 19.70 19.67 626 稳定

    各项测试策略表现的非常稳定

    3.1.4 编辑接口

    1)更新用户

    更新用户(连续请求两次)

    策略编号 样本 平均值 最小值 最大值 标准偏差 异常% 吞吐量 接收 发送 平均字节数 评价
    100-1000-10-1 2000 7877 26 18932 4915.29 0 16.35 4.17 12.85 261 稳定

    2)修改用户密码

    修改用户密码

    策略编号 样本 平均值 最小值 最大值 标准偏差 异常% 吞吐量 接收 发送 平均字节数 评价
    100-1000-10-1 2000 3986 22 12778 2689.05 0.00 49.09 12.80 30.06 267 稳定

    3.1.5 删除接口

    删除用户(暂时无并场景)

    策略编号 样本 平均值 最小值 最大值 标准偏差 异常% 吞吐量 接收 发送 平均字节数 评价

    3.1.6 分页接口

    此处没有选择分页查看用户,是因为查询数据无数据,经排查是没有权限,但是搜索角色却可以。并且页大小为10,查询第一页没有考虑数据量大的情况,搜索比较靠后的页。此接口没有配置缓存拦截,数据直接读库

    分页查询角色

    策略编号 样本 平均值 最小值 最大值 标准偏差 异常% 吞吐量 接收 发送 平均字节数 评价
    100-1000-10-1 2000 16 10 104 6.85 0.00 12.67 25.41 7.93 2054 稳定

    3.1.7 其他接口

    用户服务

    编号 模块 接口 是否满足 评价 备注
    1 User 获得当前登录用户信息 满足 稳定
    2 User 获得用户数据权限 满足 稳定 获取同一个用户
    3 User 获得用户功能权限 满足 稳定 获取同一个用户
    4 User 从数据库获取权限数据 满足 普通 获取同一个用户
    5 User 获得用户列表 满足 稳定 无权限
    6 User 分页获取用户数据 满足 稳定

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    比较突出的四个为评价“普通”,“一般”的。登录请求请看3.1.1

    3.2 结果分析

    3.2.1 稳定性分析

    经过修复上一轮测试暴露出来的问题,目前登录、新增、编辑、查看、删除、分页等不同类型接口都有较好负载能力,满足团队当前对并发值100的期望值,部分接口平均响应时间未能满足要求,请求查看3.1。

    3.2.2 解决方案

    1)修改PostgreSql最大连接数,视服务器配置设定
    在本次测试服务器环境下设定1000,能满足基本负载要求(基础数据平台)
    参考资料:
    https://stackoverflow.com/questions/30778015/how-to-increase-the-max-connections-in-postgres/32584211#32584211
    2)修改服务事务,禁止在事务中添加执行长时间的代码,例如:大量RPC、HTTP、大量循环等。
    事务使用方式请参考《xx平台文档库》
    3)修改服务最小线程池值
    在本次测试服务器环境下设定1500,能满足负载要求(基础数据平台)
    参考资料:https://stackexchange.github.io/StackExchange.Redis/Timeouts.html
    4)优化细节
    登录后权限设定改为异步;
    方法中添加返回值,返回类型为Task添加async关键字;
    取消接口事务,如果零个或单个DML取消事务,其他情况事务中只含DML语句;
    优化代码结构,防止重复代码或重复业务操作(如删除操作:Service判断是否存在、仓储层再次判断是否存在);
    获取类接口(执行时间久、修改频率低)添加服务端缓存拦截;
    修改xxxxxxxx.json中接口并发数,MaxConcurrentRequests=1000
    修改yyyyyyyy.json中管理Redis线程数值,本次测试为:minSize=100、maxSize=1000

    4 并发测试

    4.1 测试样本

    100-100-1-1策略下测试整个服务

    Label # 样本 平均值 最小值 最大值 标准偏差 异常 % 吞吐量 接收 KB/sec 发送 KB/sec 平均字节数
    登录 1 333 333 333 0 0.00% 3.003 1.67 0.91 568
    获得当前登录用户信息 100 1103 52 2379 757.52 0.00% 3.17188 23.72 1.56 7656.2
    。。。
    总体 4501 1303 52 3499 865.01 0.00% 48.36561 1987.8 30.81 42085.8

    表3.2-1 负载测试汇总报告
    在这里插入图片描述

    图3.2-1 负载测试jp@pc-PerMon Metrics Collector

    在这里插入图片描述

    图3.2-2 负载测试汇总图
    在这里插入图片描述

    图3.2-3 负载测试报错日志
    在这里插入图片描述

    图3.2-4 吞吐量正序排序
    在这里插入图片描述

    图3.2-5 接收数据倒序排序

    4.2 结果分析

    测试一次用例总共耗时1分33秒,共4501一个请求,接口普遍正常,其中“根据角色和功能删除”、“根据角色Id删除对象功能”出现少量异常分别为1%、3%,错误信息请查看图“3.2-3”。接口的普遍中位数在500ms以上且标准偏差大在800ms左右,不考虑接口业务设计错误信息下,指标与当前版本要求差距不大。部分接口返回数据较大和吞吐量低的情况,更详细请查看可靠性测试。

    5 可靠性测试

    5.1 测试样本

    5.1.1 全站可靠性测试

    使用稳定的并发数持续运行-模拟时长8+小时
    先采取策略100-100-1-1执行一段时间报错,由于单个接口100并发,49个接口总共并发数较大,调整策略为10-10-1-1,单接口10并发整站490并发,循环持续执行。

    Label # 样本 平均值 最小值 最大值 标准偏差 异常 % 吞吐量 接收 KB/sec 发送 KB/sec 平均字节数
    登录 7 2637 1373 5387 1393.34 0.00% 0.00038 0 0 568
    获得当前登录用户信息 5600 511 83 29353 493.23 0.00% 0.24883 102.87 0.12 423337.8
    总体 267387 903 47 60105 1867.88 0.50% 10.40672 2425.9 6.61 238703.3

    表3.3.1-1 汇总报告
    修改后 相同测试样本,

    Label # 样本 平均值 最小值 最大值 标准偏差 异常 % 吞吐量 接收 KB/sec 发送 KB/sec 平均字节数
    登录 2 124 123 125 1 0.00% 0.05811 0.03 0.02 568
    。。。

    修改前和修改后服务器消耗资源对比
    在这里插入图片描述

    图3.3.1-1 PerMon Metrics Collector-修改前
    在这里插入图片描述

    图3.3.1-1 PerMon Metrics Collector-修改后

    修改前和修改后服务器内存消耗对比

    在这里插入图片描述

    图3.3.1-3 PerMon Metrics Collector-Memory-修改前

    在这里插入图片描述

    图3.3.1-3 PerMon Metrics Collector-Memory

    5.1.2 创建接口类型可靠性测试

    1)创建用户

    Label # 样本 平均值 最小值 最大值 标准偏差 异常 % 吞吐量 接收 KB/sec 发送 KB/sec 平均字节数
    登录 10 4786 4263 5101 294.54 0.00% 0.002 0 0 568
    创建用户 110263 4219 153 12548 1224.2 0.00% 21.94785 6.32 14.69 295
    总体 110273 4219 153 12548 1224.16 0.00% 21.93116 6.32 14.67 295

    表3.3.2-1 汇总报告
    修改后 平均响应时间缩短计算器60%,吞吐量增加300%

    Label # 样本 平均值 最小值 最大值 标准偏差 异常 % 吞吐量 接收 KB/sec 发送 KB/sec 平均字节数
    登录 1 447 447 447 0 0.00% 2.23714 1.24 0.68 568
    创建用户 100000 1609 177 5784 468.86 0.00% 61.72664 17.78 41.3 295
    总体 100001 1609 177 5784 468.88 0.00% 61.70951 17.78 41.29 295

    在这里插入图片描述在这里插入图片描述

    图3.3.2-1 服务器资源消耗-修改前后对比
    修改后:内存消耗稳定,且能够回收内存,之前需要运行1h23min,现在仅需27min,缩短67%的时间。
    在这里插入图片描述
    在这里插入图片描述

    图3.3.2-2 服务器资源消耗-Memory-对比
    2)创建功能

    Label # 样本 平均值 最小值 最大值 标准偏差 异常 % 吞吐量 接收 KB/sec 发送 KB/sec 平均字节数
    登录 2 4873 4512 5234 361 0.00% 0.00284 0 0 568
    创建功能接口 108708 2829 128 9021 910.88 0.00% 30.63697 8.83 23.47 295
    总体 108710 2829 128 9021 910.92 0.00% 30.59851 8.82 23.44 295

    表3.3.2-2-1 汇总报告
    修改后 平均响应时间缩短计算器57%,吞吐量增加270%

    Label # 样本 平均值 最小值 最大值 标准偏差 异常 % 吞吐量 接收 KB/sec 发送 KB/sec 平均字节数
    登录 2 409 375 444 34.5 0.00% 0.01732 0.01 0.01 568
    创建功能接口 100000 1208 115 3842 432.26 0.00% 81.5692 23.5 62.48 295
    总体 100002 1208 115 3842 432.27 0.00% 81.54023 23.49 62.45 295

    修改后:各项指标均运行平稳,其中内存消耗比较明显,之前需要运行58min,现在仅需20min,缩短65%的时间。

    图3.3.2-2-1 服务器资源消耗
    内存消耗比较:由于是单机部署,存在多个服务,此处只比较内存变化稳定性,修改后较修改前稳定。

    图3.3.2-2-2 服务器资源消耗-Memory

    5.1.3 编辑接口类型可靠性测试

    Label # 样本 平均值 最小值 最大值 标准偏差 异常 % 吞吐量 接收 KB/sec 发送 KB/sec 平均字节数
    登录 5 4280 4167 4415 82.15 0.00% 0.00076 0 0 568
    编辑用户 130000 4761 90 30528 4445.93 0.15% 17.24658 4.4 13.42 261

    表3.3.3-1 汇总报告
    修改后 接口存在错误,并发下编辑同库同表同行数据,与本次测试的策略有关系。报错详情:This NpgsqlTransaction has completed;it is no longer usable. 限制因素:数据库行级锁限制或并发下事务处理方案需优化

    Label # 样本 平均值 最小值 最大值 标准偏差 异常 % 吞吐量 接收 KB/sec 发送 KB/sec 平均字节数
    登录 4 928 352 2303 805.26 0.00% 0.00138 0 0 568
    编辑用户 34264 8338 84 30455 7267.91 0.59% 11.75666 3 9.15 261.7

    服务器资源消耗对比
    在这里插入图片描述
    在这里插入图片描述

    图3.3.3-1 服务器资源消耗
    内存消耗对比:修改后编辑用户前期内存消耗正常,在程序后期出现错误后内存消耗严重,和本次测试策略有关系。
    在这里插入图片描述
    在这里插入图片描述

    图3.3.3-2 服务器资源消耗-Memory

    5.1.4 获取接口类型可靠性测试

    。。。

    5.1.5 分页获接口类型可靠性测试

    5.2 结果分析

    5.2.1 概况

    本次测试计划测试时长为8h+,实际测试时长为7小时8分钟,总共发起请求267387个,吞吐量为10.4/s,平均响应时间900ms,错误率0.5%,平均发送速率6.61KB/s,接收速率2425KB/s。
    数据库数据无异常。

    假设系统常用在线用户10人,每人平均每分钟点击20次,每天平均在线时长10分钟,13天

    1)服务器资源CPU
    服务器资源中CPU表现稳定,在测试后半段出现满负荷情况;
    2)服务器Memory
    服务器内存单位时间内平缓但总体呈上逐步升趋势;
    3)服务器Disks I/O
    服务器磁盘I/O比较稳定,测试用例循环测试的启动初期会出现一定的波动;
    4)服务器Swap
    服务器Swap在服务启动初期会暂用比较高资源,在服务运行过程中逐步下降;
    5)服务器TCP
    服务器TCP连接数在运行过程中一直保持在4000个连接左右,可能是影响吞吐量的因素之一;
    6)Network I/O
    网络I/O比较稳定,总体上没有太多的异常。

    5.2.1.1 问题

    1)服务器资源占用会越来越多
    从图3.3-2 PerMon Metrics Collector-CPU、图3.3-3 PerMon Metrics Collector-Memory可以观察到CPU在测试后期出现异常,而内存逐步上升,在1h40min、3h、4h20min时出现一定下降,原因是测试循环和下一个循环的间隔,系统可能回收了资源。停止服务请求在相隔一定时间(8h+)后再次测试,资源占用情况并未好转(测试登录服务报错)。
    在这里插入图片描述

    2)服务吞吐量较低
    在负载测试和并发测试中,虽然请求在100并发下都能真确响应,但响应时间长,在可靠性测试中实际吞吐量为10.4个每秒,考虑到不同类型的接口场景不同受影响因素不同,该值有一定不准确性。
    3)服务出现的异常

    根据角色和功能删除权限 20.50%
    根据角色Id删除对象功能 2.98%
    从数据库获取权限数据 0.09%
    获得用户列表 0.09%
    刷新用户缓存数据 0.09%
    分页获取用户数据 0.04%
    删除用户 0.04%
    根据条件查询所有角色 0.04%
    获得用户数据权限 0.02%
    获取当用用户角色权限 0.02%

    4)部分接口响应时间长
    “从数据库获取权限数据”、“分页获取用户数据”等。
    在这里插入图片描述

    5.2.2 不同接口类型测试

    由于全栈可靠性测试发现问题“服务器资源占用会越来越多”,故而进一步测试,选取压力测试里面增加、编辑、获取、分页获取四种类型接口进行可靠性分析。总体服务器资源消耗严重在于内存会持续增加,最终导致服务器宕机。
    根据测试数据可得出以下结论
    1)服务器消耗瓶颈在于内存,CPU、TPC、I/O等比较稳定;
    2)创建类接口会导致内存泄露;
    3)编辑类接口总体上稳定,但长期观察内存有缓慢上升趋势,但TPC连接数也同步上升,需要深入Linux调优排查;
    4)获取类接口可以长时间稳定运行;
    5)接口吞吐量与接口响应时间正比,响应时间长的接口吞吐量低,比较突出的“分页获取用户数据”、“获得用户列表”、“登录”、“从数据库获得权限数据”、“获取组织机构List”。而相对于不同接口类型,获取类的接口比操作类的接口快。

    5.2.3 解决方案

    1)登录问题
    Token过期后大量请求导致系统卡顿
    原因,Token保活机制在其最后5分钟内触发,对比时间取得是请求Header中的时间,而保活操作取得是缓存时间,导致Token失效后所有请求都触发保活操作,消耗大量资源。
    解决方案:时间统一用缓存中时间
    2)DotNetty组件
    每次Rpc会长留一个byte[]的变量(客户端和客户端都会),记录已发送字节大小。
    修改方案修:不记录已发字节数且Rpc结束之后调用ReferenceCountUtil.Release(buffer);清除Rpc过程中产生的垃圾。
    修改DotNetty服务端和客户端,涉及模块Surging.Core.DotNetty、Surging.Core.DotNettyWSServer、Surging.Core.Protocol.Http、Surging.Core.Protocol.Mqtt、Surging.Core.Protocol.Udp、Surging.Core.DNS。
    3)禁用Surging性能追踪组件。
    原因:使用微软DiagnosticListener组件,记录记录锚点数据用于记录性能追踪数据,BUP目前未启用surging的Skywalking(不完善),所以数据一直长留在内存中,
    4)集中式日志
    当不使用集中式日志时需要在配置中不启动
    5)未使用Module影响
    xxxxxxxx.json中Packages->Using配置:ServiceProxyModule、SkywalkingModule

    6)Surging生命周期管理引起的内存泄漏
    总体上修改后提升了稳定性(详情数据查看3.3中修改后测试结果),首先CPU和Memory振幅变小,系统运行平稳,其次平均响应时间大大缩短,最好为200ms,再者吞吐量提升明显最大接近500个/s。

    5.3 稳定测试-可靠性测试

    5.3.1 平稳-高并发-平稳

    选择接口采用“平稳-高并发-平稳”的测试策略进行测试,设置并发数为1-5-10-15-10-5-30-60-5(接口35个,实际并发高于设定值)。
    在这里插入图片描述

    测试结果
    在这里插入图片描述

    结论:内存能够回收,证明在高并发后能够回收内存资源;

    5.3.2 长时间测试

    选择部分接口进行长时间运行测试,1千万左右请求
    在这里插入图片描述

    最终内存消耗情况
    在这里插入图片描述

    最终系统运行时间
    在这里插入图片描述

    结论:能够长时间运行,且请求结束能够能存占用情况能够回归到稳定水平。

    6 总结

    经过三种不同测试方法负载测试、并发测试、可靠性测试。
    负载测试证明能平台框架在不同类型接口下能满足预定的稳定指标;
    并发测试证明平台所有业务接口能够满足预定的稳定指标;
    可靠性测试证明平台能够长时间运行,满足预定的稳定指标

    7 附录

    附录1-测试接口列表

    编号 服务名 接口名 接口URL
    1 用户 登录 POST /api/user/login?servicekey=User
    2 获得当前登录用户信息 GET /api/user/getcurrentuserinfo?servicekey=User
    3 创建用户 POST /api/user/createuserinfo?servicekey=User

    详细请翻阅附件2-测试脚本

    附录2-测试脚本

    JMeter打开

    ··已删除jmx文件··

    PostMan打开
    ··已删除 postman_collection.json··

    附录3-数据库数据统计

    原始测试数据库是从253已存库备份而来
    1.数据库
    编号 数据库
    大小
    测试项 bup_xxx_stability bup_cap_stability bup_yyy_stability
    1 测试前数据 15 MB 8157 kB 15 MB
    2 负载测试 15 MB 8245 kB 20 MB
    3 并发测试 15 MB 8789 kB 23 MB
    4 可靠性测试 26 MB 31 MB 57 MB
    2.数据库表大小
    编号 数据库 表名 原始 负载测试 并发测试 可靠性测试
    1 bup_basedata_stability cap.published 16 kB 16 kB 16 kB 16 kB
    。。
    3.数据库表行数
    编号 数据库 表名 原始 负载测试 并发测试 可靠性测试
    1 bup_basedata_stability Xxx_t_xxxx 348 348 348 348

    展开全文
  • 负载测试、压力测试、稳定性测试、容量测试的异同点 1.负载测试是逐步增加压力,来找到性能拐点,主要是为了找性能指标,比如服务器最大承受的并发用户数是45,为了找到这个指标,我们一开始施加的用户是20个,每次...

    负载测试、压力测试、可靠性测试、容量测试的异同点

    1.负载测试是逐步增加压力,来找到性能拐点,主要是为了找性能指标,比如服务器最大承受的并发用户数是45,为了找到这个指标,我们一开始施加的用户是20个,每次递增10个,到40个用户的时候服务器还能抗住,再增加10个到50的时候,服务器已经出现了异常,不能正常提供服务,此时我们可以找到服务器能承载的并发用户在40-50之间,然后再每次增加一个用户,就可以找到服务器最大的并发用户数是45—-关键词:逐步增加压力,找到拐点

    2.压力测试是在测试服务器在高并发的情况下,持续运行较长时间,看服务器是否能正常提供服务,压力测试的前提是已经进行了负载测试,只要服务最大能接受多大的负载,然后再最大的负载下进行长时间运行,一般是运行24小时的倍数。因为较长时间运行,可以测试出系统是否有内存泄漏等问题—关键词:持续运行较长时间

    3.可靠性测试跟压力测试区别不大,最大的区别是稳定性测试没有压力测试那么长时间,常见于秒杀系统,秒杀时时间点是固定的,服务器只在很短的实际内有高并发—关键词:持续时间短

    4.容量测试是值在特别多的数据的情况下进行测试,看服务器响应有没有变慢,同一个查询接口,如果数据过多,查询没有优化,用少量数据是无法测试出来性能的----关键词:大量数据

    个人理解,如有不对,请指正

    展开全文
  • 容错性测试是检查软件在异常条件下自身是否具有防护性的措施或某种灾难性恢复的手段。当系统出错时,能否在指定时间间隔内修正错误并重新启动系统。容错性测试包括两个方面: 输入异常数据或进行异常操作,以检验...
  • 主流邮箱可靠性测试

    千次阅读 2006-03-30 08:53:00
    davies 的这篇文章称,他编写了一个程序分别对 ...测试方法为用mails服务器作为SMTP服务器,各连续发送100封,1000封简短的测试邮件来测试各个邮箱的性能。 在经过几轮的测试后,他的结论是:“GMail的表现是最优秀
  • 服务器稳定性测试方法

    千次阅读 2018-07-07 19:50:24
    正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能,如:数据冗余、网卡荣誉、电源冗余、风扇冗余等。一些测试方法主要分以下几种:压力测试:已知系统高峰期使用人数,验证...
  • 可靠性测试和软件性能测试数据总结 在学习编程的过程中,我觉得不止要获得课本的知识,更多的是解决问题的方法,面对新问题该怎么解决,这样我们才能走在最前方,我是达内的学员,感谢你对本博客的支持;  ...
  • 可靠性测试技术

    千次阅读 2018-07-16 10:58:02
    Security(1)Attribute——可用(Availability)、依赖(Reliability)、安全(Safety)、机密(Confidentiality)、整体、可维护(2)Threats——Faults、Error、Failures(3)Means① Fault Prevention②...
  • 浏览器端可靠性测试的概念和背景 背景 Web 2.0 是一个体现当代网络技术发展趋势的流行概念。它使得基于 Web 的信息交互和用户间协作性更加灵活和丰富。很多的社交网站、博客、wiki,都是 Web 2.0 技术的典型...
  • 好久没在QQ上谈论这么长时间的测试了,而且今晚碰到了很多的老朋友,以下是关于讨论LR进行稳定测试性的一次交流:windy 19:57:56还准备跟你讨论个问题呢 Zee 19:58:05什么?...就是可靠性测试 Zee 19:58:
  • 它要求在网络压力大及服务器宕机等灾害的情况下,保证消息至少被发送到服务器一次。我们需要对大数据平台已提供的消息服务kafka进行测试
  • 九款Web服务器性能压力测试工具

    万次阅读 多人点赞 2018-06-06 10:23:55
    压力测试(StressTesting),也称为强度测试,通过模拟实际应用的软硬件环境及用户使用过程的系统负荷,长时间或超大负荷地运行测试软件,来测试被测系统的性能、可靠性、稳定性等。压力测试需要确定一个系统的瓶颈...
  • 后端服务器的压力测试

    千次阅读 2017-09-08 18:18:03
    比如我要测试服务器的连接数最大能达到多少?以前测试的方法是一个客户端开启N个线程 (N > 1000 或者2000,3000) 但是并没有达到测试的效果。 做过一些测试,基本方法是启动一个客户端,通过多个线程来同时来连接...
  • 2015-03-11杨万民平民大数据 业务场景 ...这些消息具有瞬间爆发,比如热门直播间刚开播,直播表演的高潮等等。而用户的礼物、星星、喇叭、沙发等这类消息是不允许丢失,必须100%送达。这就
  • MQTT再学习 -- 搭建MQTT服务器测试

    万次阅读 多人点赞 2017-08-04 13:56:07
    最近在搞 PM2.5 采集,需要用到 MQTT 传输协议。协议部分看了几天的,讲的七七八八。本身在 intel 上有 写好的MQTT 的源码,现在的工作其实也...不过,对于之前没有接触过的我来说,还是从头开始,搭建服务器及测...
  • 服务器压力测试

    千次阅读 2018-04-04 11:30:37
    博客学院下载GitChat论坛 写博客发Chat登录注册 10大主流压力测试...
  • WAS服务器负载测试软件导读

    千次阅读 2008-06-27 16:05:00
    转帖:出处未知 你的Web服务器和应用到底能够支持多少并发用户访问?在出现大量并发请求的情况下,软件会出现问题吗?这些问题靠通常的测试手段是无法解答的。本文介绍了Microsoft为这个目的而提供的免费工具WAS及其...
  • 早期是用来衡量一个产品(尤其是电器等可维修的产品)的可靠性指标。单位为“小时”。它们反映了产品的时间质量,是体现产品在规定时间内保持功能的一种能力。软件系统在某种意义上也是一种产品,所以用这三项指标来...
  • 上篇说了双端口的一些概念和实现,《浅析U.2接口NVMe SSD双端口模式(上)——应用模式与设计实现》这篇将进一步通过测试介绍NVMe SSD双端口特性的可靠性和性能的验证。(测试均使用双路超微服务器,每路有两个Intel...
  • 宣传6个9的可靠性就真的可靠吗

    千次阅读 2016-09-06 21:48:22
    可靠性是人们长期以来讨论的热点话题,随着分布式系统的发展,可靠性的问题早已是每个存储、分布式系统、融合系统和服务器等厂商的一门必修课程。
  • 几款服务器压力测试软件

    万次阅读 2011-03-29 10:54:00
    <br />本文介绍了几个比较典型的服务器评测软件,无论什么评测工具,基本的技术都是利用线程技术模仿和虚拟用户,在这里主要的难点在于测试脚本的编写,每种工具使用的脚本都不一样,但是大多数工具都提供录制...
  • 文章目录系统测试概述功能测试性能测试负载测试压力测试性能测试、压力测试、负载测试的关系兼容性测试安全测试健壮性测试配置测试可用性测试文档测试 系统测试概述 系统测试的定义 将已经集成好的软件系统,作为...
  • Web服务器性能测试介绍

    千次阅读 2013-12-15 23:34:10
    Web服务器性能测试介绍 一、引言 ... 随着Internet的快速发展,Web服务器已成为Web系统的重要组成部分,同时也...随着Web服务器的重要日益显著,为了及时掌握Web服务器的性能,需要对其进行公证的测试。  
  • 服务器性能测试典型工具介绍

    千次阅读 2007-02-12 15:48:00
    服务器性能测试典型工具介绍来自:JDMBA众所周知,服务器是整个网络系统和计算平台的核心,许多重要的数据都保存在服务器上,很多网络服务都在服务器上运行,因此服务器性能的好坏决定了整个应用系统的性能。...
  • 软件稳定性测试

    万次阅读 2016-02-24 06:23:39
    1 稳定性测试就测试系统的长期稳定运行能力。在系统运行过程中,对系统施压,观察系统的各种性能指标,以及服务器的...所以要尽可能的提高测试的可靠性。可以通过多次测试,延长测试时间,增大测试压力来提高测试的
  • 性能测试工具介绍 ...服务器性能测试典型工具介绍 性能测试工具 http://www.tech-q.cn/archiver/tid-1209.html iozone测试结果分析 http://blog.chinaunix.net/u2/73230/showart_1091304.htm
  • 性能测试之稳定性测试

    千次阅读 2014-07-06 17:00:24
    (8)稳定性测试     1 稳定性测试就测试系统的长期稳定运行能力。在系统运行过程中,对系统施压,观察系统的各种性能指标,以及服务器的指标...所以要尽可能的提高测试的可靠性。可以通过多次测试,延长测试时间,

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 157,300
精华内容 62,920
关键字:

服务器可靠性测试