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

    千次阅读 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%)的可靠性?

    展开全文
  • 本次测试采取负载测试、并发测试、可靠性测试。测试方案采取模拟真实用户使用场景,模拟指定人数在一定时间点击界面产生的请求数。 在并发10(单位个/s)、20、40、80、160、500、1000、2000的基准下,调整用户数...
  • 服务器稳定性测试方法

    千次阅读 2019-07-04 16:02:12
     正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能,如:数据冗余、网卡荣誉、电源冗余、风扇冗余等。 一些测试方法主要分以下几种:  压力测试:已知系统高峰期使用...

            服务器稳定性是最重要的,如果在稳定性方面不能够保证业务运行的需要,在高的性能也是无用的。

      正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能,如:数据冗余、网卡荣誉、电源冗余、风扇冗余等。

    一些测试方法主要分以下几种:

      压力测试:已知系统高峰期使用人数,验证各事务在最大并发数(通过高峰期人数换算)下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应(如:宕机、应用异常中止等)。
    Ramp Up 增量设计:如并发用户为75人,系统注册用户为1500人,以5%-7%作为并发用户参考值。一般以每15s加载5人的方式进行增压设计,该数值主要参考测试加压机性能,建议Run几次。以事务通过率与错误率衡量实际加载方式。
    Ramp Up增量设计目标: 寻找已增量方式加压系统性能瓶颈位置,抓住出现的性能拐点时机,一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数,如早晨的登录,下班后的退出,工资发送时的消息系统等。
      另一种极限模拟方式,可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变,在各脚本事务点中设置同集合点名称(如:lr_rendzvous("same");)在场景设计中,使用事务点集合策略。以同时达到集合点百分率为标准,同时释放所有正在Run的Vuser。
      稳定性测试:已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景,测试时将每个场景按照一定人数比率一起运行,模拟用户使用数年的情况。并监控在测试中,系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。
      根据上述测试中,各事务条件下出现性能拐点的位置,已确定稳定性测试并发用户人数。仍然根据实际测试服务器(加压机、应用服务器、数据服务器三方性能),估算最终并发用户人数。

    场景设计思想:
         从稳定性测试场景的设计意义,应分多种情况考虑:

      针对同一个场景为例,以下以公文附件上传为例简要分析场景设计思想:

    1)场景一:已压力测试环境下性能拐点的并发用户为设计测试场景,目的验证极限压力情况下测试服务器各性能指标。

    2)场景二:根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。

      测试方法:采用1)Ramp Up-Load all Vusers simultaneously

    2)Duration-Run Indefinitely

    3)在Sechedule-勾选Initalize all Vusers before Run

      容错性测试:通过模拟一些非正常情况(如:服务器突然断电、网络时断时续、服务器硬盘空间不足等),验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA(自动容灾系统),还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。

      问题排除性测试:通过原有案例或经验判断,针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如:上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。

      测评测试是用于获取系统的关键性能指标点,而进行的相关测试。主要是针对预先没有明确的预期测试结果,而是要通过测试获取在特定压力场景下的性能指标(如:事务响应时间、最大并发用户数等)。

      评测事务交易时间:为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值,获取事务在这种压力下的响应时间。

    评测事务最大并发用户数:为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境,评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义(如响应时间,CPU占用率,内存占用率,已出现点击率峰值,已出现吞吐量峰值等)。

      评测系统最大并发用户数:为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率,定义各事务在综合场景中所占的比率,以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境,评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义(如响应时间,CPU占用率,内存占用率,已出现点击率峰值,已出现吞吐量峰值等)。取值标准以木桶法则为准(并发数最小的事务为整个系统的并发数)。

      评测不同数据库数据量对性能的影响:针对不同数据库数据量的测试,将测试结果进行对比,分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后,或某些模块客户要求数据量较大时可能存在的隐患。

      问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能,可以直接找出引起性能问题所在的代码或模块。

      该类测试主要还是通过测试出问题的脚本场景,并可以增加发现和检测的工具,如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试

     

    展开全文
  • 可靠性测试

    2021-07-23 11:42:40
    可靠性测试就是为了评估产品在规定的寿命期间内,在预期的使用、运输或储存等所有环境下,保持功能可靠性而进行的活动。是将产品暴露在自然的或人工的环境条件下经受其作用,以评价产品在实际使用、运输和储存的环境...

    可靠性测试就是为了评估产品在规定的寿命期间内,在预期的使用、运输或储存等所有环境下,保持功能可靠性而进行的活动。是将产品暴露在自然的或人工的环境条件下经受其作用,以评价产品在实际使用、运输和储存的环境条件下的性能,并分析研究环境因素的影响程度及其作用机理。通过使用各种环境试验设备模拟气候环境中的高温、低温、高温高湿以及温度变化等情况,加速反应产品在使用环境中的状况,来验证其是否达到在研发、设计、制造中预期的质量目标,从而对产品整体进行评估,以确定产品可靠性寿命。

    中文名

    可靠性测试

    外文名

    Reliability test别    名

    可靠性评估

    分    类

    软件、硬件可靠性测试

    测试方式

    组件压力测试等

    可靠性测试分类

    编辑

    语音

    二、硬件可靠性测试

    可靠性测试软件

    编辑

    语音

    可靠性测试概念

    可靠性测试也称可靠性评估,指根据产品可靠性结构、寿命类型和各单元的可靠性试验信息,利用概率统计方法,评估出产品的可靠性特征量。

    软件可靠性是软件系统在规定的时间内以及规定的环境条件下,完成规定功能的能力。一般情况下,只能通过对软件系统进行测试来度量其可靠性。

    可靠性测试测试方式

    测试可靠性是指运行应用程序,以便在部署系统之前发现并移除失败。因为通过应用程序的可选路径的不同组合非常多,所以在一个复杂应用程序中不可能找到所有的潜在失败。但是,可测试在正常使用情况下最可能的方案,然后验证该应用程序是否提供预期的服务。如果时间允许,可采用更复杂的测试以揭示更微小的缺陷。

    组件压力测试

    压力测试是指模拟巨大的工作负荷以查看应用程序在峰值使用情况下如何执行操作。利用组件压力测试,可隔离构成组件和服务、推断出它们公开的导航方法、函数方法和接口方法以及创建调用这些方法的测试前端。对于那些进入数据库服务器或一些其他组件的方法,可创建一个提供所需格式的哑元数据的后端。测试仪器在观察结果的同时,反复插入哑元数据。

    这里的想法是在隔离的情况下,对每个组件施加远超过正常应用程序将经历的压力。例如,以尽可能快的速度使用 1 – 10,000,000 循环,查看是否有暴露的问题。单独测试每个 DLL 可帮助确定组件的失败总次数。

    对于分布式 Web 应用程序,Microsoft 提供“Web 应用程序压力工具”。有关更多信息,请参见“Microsoft Web Application Stress Tool”(Microsoft Web 应用程序压力工具).如果您购买了 Visual Studio .NET 企业版,还会提供另一个名为 Application Center Test 的工具,它用来预览 Application Center 2000 中某些技术的介绍性信息。

    集中压力测试

    对每个单独的组件进行压力测试后,应对带有其所有组件和支持服务的整个应用程序进行压力测试。集中压力测试主要关注与其他服务、进程以及数据结构(来自内部组件和其他外部应用程序服务)的交互。

    集中测试从最基础的功能测试开始。您需要知道编码路径和用户方案、了解用户试图做什么以及确定用户运用您的应用程序的所有方式。

    测试脚本应根据预期的用法运行应用程序。例如,如果您的应用程序显示 Web 页,而且 99% 的客户只是搜索该站点、只有 1% 的客户将真正购买,这使得提供对搜索和其他浏览功能进行压力测试的测试脚本才有意义。当然,也应对购物车进行测试,但是预期的使用暗示搜索测试应在测试中占很大比重。

    在日程和预算允许的范围内,应始终尽可能延长测试时间。不是测试几天或一周,而是要延续测试达一个月、一个季度或者一年之久,并查看应用程序在较长时期内的运行情况。

    真实环境测试

    在隔离的受保护的测试环境中可靠的软件,在真实环境的部署中可能并不可靠。虽然隔离测试在早期的可靠性测试进程中是有用的,但真实环境的测试环境才能确保并行应用程序不会彼此干扰。这种测试经常发现与其他应用程序之间的意外的导致失败的交互。

    需要确保应用程序能够在真实环境中运行,即能够在具有所有预期客户事件配置文件的服务器空间中,使用最终配置条件运行。测试计划应包括在最终目标环境中或在尽可能接近目标环境的环境中运行应用程序。这一点通常可通过部分复制最终环境或小心地共享最终环境来完成。

    随机破坏测试

    测试可靠性的一个最简单的方法是使用随机输入。这种类型的测试通过提供虚假的不合逻辑的输入,努力使应用程序发生故障或挂起。输入可以是键盘或鼠标事件、程序消息流、Web 页、数据缓存或任何其他可强制进入应用程序的输入情况。应该使用随机破坏测试测试重要的错误路径,并公开软件中的错误。这种测试通过强制失败以便可以观察返回的错误处理来改进代码质量。

    随机测试故意忽略程序行为的任何规范。如果该应用程序中断,则未通过测试。如果该应用程序不中断,则通过测试。这里的要点是随机测试可高度自动化,因为它完全不关心基础应用程序应该如何工作。

    可能需要某种测试装备,以驱使混乱的、高压力的、不合逻辑的测试事件进入应用程序的接口中。Microsoft 使用名为“注射器”的工具,使得以将错误注射到任何 API 中,而无需访问源代码。“注射器”可用于:模拟资源失败,修改调用参数,注射损坏的数据,检查参数验证界限,插入定时延迟,以及执行许多其他功能。

    可靠性测试硬件

    编辑

    语音

    也称产品的可靠性评估,产品在规定的条件下、在规定的时间内完成规定的功能的能力。产品在设计、应用过程中,不断经受自身及外界气候环境及机械环境的影响,而仍需要能够正常工作,这就需要以试验设备对其进行验证,这个验证基本分为研发试验、试产试验、量产抽检三个部分。可靠性试验包括:老化试验、温湿度试验、气体腐蚀试验、机械振动试验、机械冲击试验、碰撞试验和跌落试验、防尘防水试验以及包装压力试验等多项环境可靠性试验。

    可靠性测试项目

    编辑

    语音

    可靠性测试是为了保证产品在规定的寿命期间内,在预期的使用、运输或储存等所有环境下,保持功能可靠性而进行的活动。是将产品暴露在自然的或人工的环境条件下经受其作用,以评价产品在实际使用、运输和储存的环境条件下的性能,并分析研究环境因素的影响程度及其作用机理。通过使用各种环境试验设备模拟气候环境中的高温、低温、高温高湿以及温度变化等情况,加速反应产品在使用环境中的状况,来验证其是否达到在研发、设计、制造中预期的质量目标,从而对产品整体进行评估,以确定产品可靠性寿命。可靠性测试可分为机械和环境两大块。可靠性测试项目如下:

    词条图册

    更多图册

    展开全文
  • 软件系统在某种意义上也是一种产品,所以用MTBF、MTTF、MTTR这三项指标来衡量软件系统的可靠性同样也是合适的。本文着重介绍这三项指标的定义以及它们之间的关系。
  • 从而团队提出对平台进行稳定性分析,通过给系统施加一定业务压力大情况下,使系统持续运行一段时间,以此来检测系统是否稳定运行(下统称稳定性测试或测试)。 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-101011101个用户,每个用户每秒提交10次请求
    10-10-1-110101110个用户,每个用户每秒提交1次请求
    10-20-2-110202120个用户,每个用户2秒内提交1次请求
    10-20-4-210204220个用户,每个用户4秒内提交2次请求
    10-40-4-110404140个用户,每个用户4秒内提交1次请求
    10-40-8-210408240个用户,每个用户8秒内提交2次请求
    10-80-8-110808180个用户,每个用户8秒内提交1次请求
    10-80-16-2108016280个用户,每个用户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-2100383401181294.89055.4330.9630.92572.00稳定
    100-100-1-110024441962192.77068.6338.3440.37572.00稳定
    100-200-2-1200768392969716.67055.8731.2133.03572.00稳定
    100-1000-10-1100050779387935829633.030.73912.173.977.35334.04极差
    100-1000-20-2很卡无法测试

    登录接口(线程池1000)

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

    登录接口(线程池1500)

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

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

    策略编号样本平均值最小值最大值标准偏差异常%吞吐量接收发送平均字节数评价
    1-10-10-1
    10-100-10-1
    100-1000-10-11000418932130702803.22054.3830.5933.06576一般
    100-1000-10-1
    100-1000-10-13110544334176753858.24021.6712.1913.17576一般
    100-1000-10-14120489530176753654.62013.777.758.37576一般
    1-10-10-1
    1-10-10-14130488330176753657.94011.796.637.16576

    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-1200021131447.950.0032.2319.7019.67626稳定

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

    3.1.4 编辑接口

    1)更新用户

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

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

    2)修改用户密码

    修改用户密码

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

    3.1.5 删除接口

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

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

    3.1.6 分页接口

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

    分页查询角色

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

    3.1.7 其他接口

    用户服务

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

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

    比较突出的四个为评价“普通”,“一般”的。登录请求请看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平均字节数
    登录133333333300.00%3.0031.670.91 568
    获得当前登录用户信息1001103522379757.520.00%3.1718823.721.567656.2
    。。。
    总体45011303523499865.010.00%48.365611987.830.8142085.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平均字节数
    登录72637137353871393.340.00%0.0003800568
    获得当前登录用户信息56005118329353493.230.00%0.24883102.870.12423337.8
    总体26738790347601051867.880.50%10.406722425.96.61238703.3

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

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录212412312510.00%0.058110.030.02568
    。。。

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

    图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平均字节数
    登录10478642635101294.540.00%0.00200568
    创建用户1102634219153125481224.20.00%21.947856.3214.69295
    总体1102734219153125481224.160.00%21.931166.3214.67295

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

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录144744744700.00%2.237141.240.68568
    创建用户10000016091775784468.860.00%61.7266417.7841.3 295
    总体10000116091775784468.880.00%61.7095117.7841.29295

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

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

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

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录24873451252343610.00%0.0028400568
    创建功能接口10870828291289021910.880.00%30.636978.8323.47295
    总体10871028291289021910.920.00%30.598518.8223.44295

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

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录240937544434.50.00%0.017320.010.01568
    创建功能接口10000012081153842432.260.00%81.569223.562.48295
    总体10000212081153842432.270.00%81.5402323.4962.45295

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

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

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

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

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录542804167441582.150.00%0.0007600568
    编辑用户130000476190305284445.930.15%17.246584.413.42261

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

    Label# 样本平均值最小值最大值标准偏差异常 %吞吐量接收 KB/sec发送 KB/sec平均字节数
    登录49283522303805.260.00%0.0013800568
    编辑用户34264833884304557267.910.59%11.7566639.15261.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

    展开全文
  • 可靠性测试到底在测什么?

    千次阅读 2020-07-21 10:16:35
    平时我们对功能、安全、性能都有深入的认识和了解,但对可靠性测试这样的多特性的特质,应该怎么做呢? 先让我们来认识一下什么是:可靠性测试可靠性测试 可靠性特性:在指定条件下使用时,软件产品维持规定的...
  • 宣传6个9的可靠性就真的可靠吗

    千次阅读 2016-09-06 21:48:22
    可靠性是人们长期以来讨论的热点话题,随着分布式系统的发展,可靠性的问题早已是每个存储、分布式系统、融合系统和服务器等厂商的一门必修课程。
  • 1、LTP--linux稳定性测试: LTP套件是由 Linux Test Project 所开发的一套系统测试套件。它基于系统资源的利用率统计开发了一个测试的组合,为系统提供足够的压力。通过压力测试来判断系统的稳定性和可靠性。 2、...
  • 安博检测是业内为数不多拥有做平均无故障寿命测试的机构,安博拥有完善的台式,微型计算机,计算机服务器的CNAS和CMA授权的实验,目前已经给国内多家国企,央企做过此标准测试和报告 计算机服务器的GB/T9813.3测试...
  • 但是,与具有许多用于测试的工具和框架的本地文件系统不同,(仍然)没有用于评估分布式文件系统及其独特故障模式(如节点和网络故障)的可靠性标准框架! 这不仅意味着每个系统都必须实施自己的测试,而且还难以...
  • 传统的网络存储系统采用集中的存储服务器存放所有数据,存储服务器成为系统性能的瓶颈,也是可靠性和安全性的焦点,不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构,利用多台存储服务器分担...
  • 浏览器端可靠性测试的概念和背景 背景 Web 2.0 是一个体现当代网络技术发展趋势的流行概念。它使得基于 Web 的信息交互和用户间协作性更加灵活和丰富。很多的社交网站、博客、wiki,都是 Web 2.0 技术的典型...
  • 前几期的评测中,我们对比了Kafka和RocketMQ的吞吐量和稳定性,本期我们要引入一个新的评测标准——软件可靠性。 何为“可靠性”? 先看下面这种情况:有A,B两辆越野汽车,在城市的周边地区均能很好应对泥泞的路况...
  • 数据系统 ...可靠性 是指系统在困境中也可以正常工作,讲包括故障和失效 故障 指系统的一部分状态偏离其标准 硬件故障:磁盘可以提供 RAID;双路电源;热插拔 CPU 等等可以解决 软件故障:系统错误,特定
  • 阿里云GPU云服务器是基于GPU应用的计算服务,多适用于AI深度学习,视频...GA1实例计算能力 GA1实例最多可提供 4 颗AMD S7150 GPU、56 个 vCPU 和 160GB 主机内存,以及共计 32GB 的 GPU显存、总计提供8192个并行处理核
  • 服务器压力测试

    千次阅读 2018-04-04 11:30:37
    博客学院下载GitChat论坛 写博客发Chat登录注册 10大主流压力测试...
  • 实时软件的可靠性设计

    万次阅读 2013-11-24 01:33:13
    随着实时软件在可靠性和安全性要求极高的环境和系统中的广泛使用,对软件可靠性的依赖正在以前所未有的速度增长,实时软件的可靠性设计与保证在实时系统中占据着越来越重要的位置。可靠性是实时软件的一个重要指标。 ...
  • 系统性能评测和可靠性基础

    千次阅读 2012-09-05 17:43:54
    当数据处理部件的可靠性为0.6时,为使整个软件系统的可靠性不小于0.66,则数据存储部件的可靠性至少应为(31)。   (31)A.0.6 B.0.66 C.0.79 D.1.0 分 析:两个数据处理部件...
  • 首先非常感谢华为云微信小助手,让我免费领取到了鲲鹏弹性云服务器KC1的免费体验资格。 领取的服务器配置详情: 规格: 4vCPUs | 8GB | kc1.xlarge.2 镜像:CentOS 7.4 64bit with ARM 虚拟私有云、弹性公网IP、云...
  • 服务器选型是Linux性能调优的第一步。无论你是自行购买服务器进行托管,还是租用服务器,购买云主机,都要面临的一个问题:选择服务器...我们要根据服务器的用途,来决定服务器的性能、容量和可靠性需求。这里我们按...
  • 弹性云服务器(Elastic Cloud Server,ECS) https://support.huaweicloud.com/ecs/index.html ...
  • 测试技术-兼容性测试

    千次阅读 2019-09-24 14:38:07
    兼容性测试 ** 1 兼容性测试概述 兼容性测试将验证软件与其所依赖的环境的依赖程度,包括对硬件的依赖程度,对平台软件、其他软件的依赖程度等。 2 兼容性测试环境的准备 测试中的硬件环境指进行测试所必需的服务器...
  • 性能测试标准及准则

    千次阅读 2019-05-05 16:41:51
    明确目的 {描述本次性能测试的主要目的,例如:评估系统性能,为性能调优提供依据和建议,或者做对比分析的性能测试等,或对系统的未来容量等作出预测和规划等} ...1、系统新上线、测试明确的数字标准对比情况下...
  • 服务器端技术

    千次阅读 2019-10-08 16:56:08
    服务器分为web服务器和应用服务器。Web服务器是离客户端最近的服务器,负责监听和处理HTTP请求。应用服务器比web服务器更靠近后端,主要处理复杂的业务逻辑和数据库的访问。 如果是静态资源(例如HTML页面或图片),...
  • obs链接不到服务器

    千次阅读 2021-08-13 06:58:23
    obs链接不到服务器 内容精选换一换obsutil是适用于Windows、macOS和Linux操作系统的命令行工具,支持通过配置内网DNS服务器地址的方式,使在华为云上的Linux ECS通过内网直接访问OBS,下面将介绍其具体操作流程和...
  • 软件架构设计之九:系统可靠性

    千次阅读 2013-08-31 13:00:26
    一、本章要点 系统可靠性是系统在规定的时间内及规定的环境下完成规定功能的能力,也...包括系统的故障模型和可靠性模型、系统的可靠性分析和可靠度计算、提高系统可靠性的措施、系统的故障对策、系统的备份与恢复。
  • 在上一篇服务器基础知识文章“[收藏] 最全服务器基础知识科普”中,读者阅读量超过了1.1W,既然大家这么喜欢此类科普文章,今天笔者再次给大家带来服务器深度知识相关文章,请大家搬好椅子,精彩内容马上开始。...
  • 兼容性测试 安全测试 健壮性测试 配置测试 可用性测试 文档测试 系统测试概述 系统测试的定义 将已经集成好的软件系统,作为整个计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等...
  • 什么叫做服务器

    万次阅读 多人点赞 2019-03-15 09:54:39
    服务器的构成包括处理器、硬盘、内存、系统总线等,和通用的计算机架构类似,但是由于需要提供高可靠的服务,因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。 在网络环境下,根据...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 93,959
精华内容 37,583
关键字:

服务器可靠性测试标准