服务器压力测试方法与流程

文档序号:14777675发布日期:2018-06-26 07:20阅读:450来源:国知局

本发明涉及一种测试方法,尤其涉及一种分布式应用的服务器压力测试方法。



背景技术:

当前,互联网行业飞速发展的今天,人们的生活和一个个互联网应用息息相关,给广大群众的生活带来了极大的便捷。

然而随着越来越多的互联网应用被广大用户所使用,如何处理高并发数据请求成为了互联网技术中急需解决的问题。如何模仿互联网应用中的高并发数据请求的场景,成为了解决问题的关键。

申请号:201210314606.3的中国发明申请公开了一种服务器压力测试方法,其包括将网络中分散的电子设备分级以形成测试集群,其中初始级以下的每一级中的电子设备与上一级中的一个电子设备耦接,且位于最低级的电子设备还与被测服务器耦接;发送测试报文给测试集群,在测试集群中,测试报文从初始级中的各电子设备向下传送到最低级中的各电子设备,在测试报文传送到最低级之前,各级中的电子设备复制测试报文并将所复制的报文传送到下一级;最低级中的各电子设备将测试报文传送给服务器以进行对服务器的测试;以及收集测试结果。还提供一种测试系统。本发明所述方法及系统可利用网络中分散的电子设备对待测web服务器进行压力测试。其采用网络中分散的电子设备进行压力测试,由于网络原因,容易导致测试结果不稳定,测试压力程度不足等问题。

因此,本领域的技术人员致力于开发一种能有效的还原互联网应用中的高并发数据请求的场景,并且在不影响生产业务的情况下,能有效对服务器进行压力测试的方法。



技术实现要素:

有鉴于现有技术的上述缺陷,本发明所要解决的技术问题是提供一种服务器压力测试方法,其中,在主机内创建多个模仿用户请求的容器;每个容器向待测试服务器请求返回值生成测试日志;将多个测试日志传送至日志存储服务器;对多个测试日志进行分析,导出分析结果进行展示。

优选的,创建多个主机,在每一主机内分别创建多个模仿用户请求的容器。

优选的,模仿用户请求采用RESTfulAPI的请求。

优选的,测试日志包括:RESTfulAPI返回值及请求耗时。

优选的,每一容器具有一用于存储测试日志的固定目录;通过一插件对固定目录进行监控,获取固定目录有写入信息则将测试日志传送至日志存储服务器。

优选的,根据待测试服务器需要通过持续集成工具设定容器数量,持续集成工具发送执行命令至压力测试管理服务器;压力测试管理服务器从代码服务器获取容器镜像,并将容器镜像发送至多个主机,完成在主机内创建容器的操作。

优选的,对多个测试日志进行分析包括:提取测试日志中的返回值及请求耗时信息。

优选的,分析结果包括:请求返回值的数量、请求返回值的成功率、每次请求耗时信息。

优选的,根据待测试服务器的API确定RESTfulAPI的URL。

优选的,根据测试服务器需要通过持续集成工具设定容器个数。

优选的,压力测试管理服务器根据执行命令控制每个容器向待测试服务器请求返回值至压力测试管理服务器的高性能消息列队程序,通过高性能消息列队程序后生成标准格式的测试日志传送至日志存储服务器。

本发明服务器压力测试方法较之于现有技术,有效解决了缺少一种有效对服务器进行压力测试的方法的问题,通过在主机内创建多个模仿用户请求的容器,模仿互联网应用高并发数据请求的场景,在不影响生产业务的情况下,能够实现快速部署,有效的进行服务器的压力测试,测试互联网应用的并发请求带宽,从而可以根据测试的结果进行服务器架构的调整。

以下将结合附图对本发明的构思、具体结构及产生的技术效果作进一步说明,以充分地了解本发明的目的、特征和效果。

附图说明

图1是本发明的系统架构图;

图2是本发明的具体实施架构图。

具体实施方式

如图所示,图1是本发明的系统架构图,一种服务器压力测试方法,其中,在主机3内创建多个模仿用户请求的容器31,由于容器31技术的轻量性的特征,使得通过本发明的方法很容易在一台主机3(机器/虚拟机)内建立起大量的容器31,从而使得可以通过主机3来模仿多用户的高并发请求;每个容器31向待测试服务器2请求返回值生成测试日志;将多个测试日志传送至日志存储服务器4;对多个测试日志进行分析,导出分析结果进行展示。

进一步的,创建多个主机3,在每一主机3内分别创建多个模仿用户请求的容器31,采用多个主机3的方式进行测试,进一步的增加了容器31的数量,从而可以模仿更多的并发数据请求,根据具体测试的需要,安排相应的主机3数量。在具体实施的过程中,可以采用一定数量的主机3组,根据测试的需求,启用主机3组中部分的主机3,进行测试。

如图所示,图2是本发明的具体实施的架构图,在本发明的具体实施过程中,创建多个主机3,在每一主机3内分别创建多个模仿用户请求的容器3的操作具体可以采用:通过代码服务器12拉代码(Docker镜像14)至一压力测试管理服务器11,压力测试管理服务器11获取Docker(Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化)镜像14;压力测试管理服务器11将Docker镜像14上传至一Docker Registry(镜像仓库)13中;Docker Registry13拉Docker镜像14至每一主机3内,也就完成了在多个主机3内均创建多个容器31的操作。

具体的,压力测试管理服务器11向代码服务器12拉代码时需要进行身份健全认证。进一步的,本发明可以根据测试服务器需要通过持续集成工具(Jenkins,Jenkins是一个开源软件项目,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能)1设定容器31个数。本发明的方法可以通过持续集成工具1控制同时连接待测试服务器2以及排队等待测试的排队服务器6,通过一键部署的方式,部署对待测试服务器2的测试顺序及每台待测试服务器2配套的主机3数量,也就是容器31的数量,测试的顺序,并且可以通过持续集成工具1自动完成状态监控,实现整套方案的自动化部署、自动化测试、自动化生成结果。

如图所示,图2是本发明的具体实施的架构图,在本发明的具体实施过程中,通过一执行机器10执行持续集成工具1,持续集成工具1发布执行命令至压力测试管理服务器11;压力测试管理服务器11按照需要创建任务,并且根据执行命令控制获取Docker镜像14,并且执行测试代码,使主机3执行Docker Daemon程序32,实现模拟。

进一步的,本发明的方法还支持JSON格式的参数配置,具体包括:容器31个数设定、设定存储测试日志的固定目录地址等。

进一步的,模仿用户请求可以具体采用RESTfulAPI的请求(RESTful:Representational State Transfer),在每个容器31中实现基于RESTfulAPI的请求。

具体的,根据待测试服务器2的API确定RESTfulAPI的URL,使得每个容器31能够模拟一个用户的请求,采用本发明公开的方式使得容器31技术具有轻量性的特征,便于在主机3内建立大量的容器31。

进一步的,测试日志包括:RESTfulAPI返回值及请求耗时。

进一步的,每一容器31具有一用于存储测试日志的固定目录。

进一步的,通过一插件对固定目录进行监控,获取固定目录有写入信息则将测试日志传送至日志存储服务器4。

更进一步的,由于多个主机3短时间内向日志存储服务器4发送大量的测试日志,因此,在每个容器31与日志存储服务器4之间采用消息列队的方式,从而有效的提高了传输的效率与成功率。

如图所示,图2是本发明的具体实施的架构图,在本发明的具体实施过程中,主机3完成测试后将多个测试日志发送给压力测试管理服务器11中的高性能消息列队程序(RabbitMQ)15,MQ全称为Message Queue,是一种应用程序对应用程序的通信方法,应用程序通过读写出入队列的消息(针对应用程序的数据)来通信,而无需专用连接来链接它们,消息传递指的是程序之间通过在消息中发送数据进行通信,而不是通过直接调用彼此来通信,直接调用通常是用于诸如远程过程调用的技术;高性能消息列队程序15实现了在每个容器31与日志存储服务器4之间采用消息列队的方式;高性能消息列队程序15将标准格式的测试日志发送给存储服务器4的Logstash,Logstash是一个完全开源的工具,他可以对你的日志进行收集、分析,并将其存储供以后使用(如,搜索),logstash带有一个web界面,搜索和展示所有日志。

进一步的,对多个测试日志进行分析包括:提取测试日志中的返回值及请求耗时信息。

进一步的,分析结果包括:请求返回值的数量、请求返回值的成功率、每次请求耗时信息。

进一步的,通过WEB界面对分析结果进行测试结果展示5,直观的显示测试结果,从而便于用户对平台、互联网应用的性能瓶颈进行裁定。

如图所示,图2是本发明的具体实施的架构图,在本发明的具体实施过程中,通过日志存储服务器4将测试日志发送给流式数据分析服务器(Elastic Search Server)16,通过流式数据分析服务器16将测试日志发送给日志展现服务器(Kibana)17,kibana 17也是一个开源和免费的工具,他可以帮助您汇总、分析和搜索重要数据日志并提供友好的web界面,他可以为Logstash和ElasticSearch提供的日志分析的Web界面,从而最终实现测试结果的展示5。本发明中的压力测试管理服务器11、执行机器10、日志存储服务器4、流式数据分析服务器16、日志展现服务器17可以是在同一个总服务器内虚拟的分服务器,也可以采用单独的服务器。

以上详细描述了本发明的较佳具体实施例。应当理解,本领域的普通技术人员无需创造性劳动就可以根据本发明的构思作出诸多修改和变化。因此,凡本技术领域中技术人员依本发明的构思在现有技术的基础上通过逻辑分析、推理或者有限的实验可以得到的技术方案,皆应在由权利要求书所确定的保护范围内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1