centOS环境ab性能测试功能

简介:

1.ab原理

ab的原理:ab命令会创建多个并发访问线程,模拟多个访问者同时对某一URL地址进行访问。它的测试目标是基于URL的,因此,它既可以用来测试apache的负载压力,也可以测试nginx、lighthttp、tomcat、IIS等其它Web服务器的压力。

ab命令对发出负载的计算机要求很低,它既不会占用很高CPU,也不会占用很多内存。但却会给目标服务器造成巨大的负载,其原理类似CC攻击。自己测试使用也需要注意,否则一次上太多的负载。可能造成目标服务器资源耗完,严重时甚至导致死机


2.ab的安装

yum install httpd-tools


3.ab参数说明

ab --help

下面我们对这些参数,进行相关说明。如下:

-n在测试会话中所执行的请求个数。默认时,仅执行一个请求。

-c一次产生的请求个数。默认是一次一个。

-t测试所进行的最大秒数。其内部隐含值是-n 50000,它可以使对服务器的测试限制在一个固定的总时间以内。默认时,没有时间限制。

-p包含了需要POST的数据的文件。

-P对一个中转代理提供BASIC认证信任。用户名和密码由一个:隔开,并以base64编码形式发送。无论服务器是否需要(即, 是否发送了401认证需求代码),此字符串都会被发送。

-T POST数据所使用的Content-type头信息。

-v设置显示信息的详细程度-4或更大值会显示头信息,3或更大值可以显示响应代码(404,200等),2或更大值可以显示警告和其他信息。

-V显示版本号并退出。

-w以HTML表的格式输出结果。默认时,它是白色背景的两列宽度的一张表。

-i执行HEAD请求,而不是GET。

-x设置

属性的字符串。

-X对请求使用代理服务器。

-y设置

属性的字符串。

-z设置

属性的字符串。

-C对请求附加一个Cookie:行。其典型形式是name=value的一个参数对,此参数可以重复。

-H对请求附加额外的头信息。此参数的典型形式是一个有效的头信息行,其中包含了以冒号分隔的字段和值的对(如,"Accept-Encoding:zip/zop;8bit")。

-A对服务器提供BASIC认证信任。用户名和密码由一个:隔开,并以base64编码形式发送。无论服务器是否需要(即,是否发送了401认证需求代码),此字符串都会被发送。

-h显示使用方法。

-d不显示"percentage served within XX [ms] table"的消息(为以前的版本提供支持)。

-e产生一个以逗号分隔的(CSV)文件,其中包含了处理每个相应百分比的请求所需要(从1%到100%)的相应百分比的(以微妙为单位)时间。由于这种格式已经“二进制化”,所以比'gnuplot'格式更有用。

-g把所有测试结果写入一个'gnuplot'或者TSV(以Tab分隔的)文件。此文件可以方便地导入到Gnuplot,IDL,Mathematica,Igor甚至Excel中。其中的第一行为标题。

-i执行HEAD请求,而不是GET。

-k启用HTTP KeepAlive功能,即在一个HTTP会话中执行多个请求。默认时,不启用KeepAlive功能。

-q如果处理的请求数大于150,ab每处理大约10%或者100个请求时,会在stderr输出一个进度计数。此-q标记可以抑制这些信息。


4.ab性能指标

在进行性能测试过程中有几个指标比较重要:

1、吞吐率(Requests per second)

服务器并发处理能力的量化描述,单位是reqs/s,指的是在某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数,称之为最大吞吐率。

记住:吞吐率是基于并发用户数的。这句话代表了两个含义:

a、吞吐率和并发用户数相关

b、不同的并发用户数下,吞吐率一般是不同的

计算公式:总请求数/处理完成这些请求数所花费的时间,即

Request per second=Complete requests/Time taken for tests

必须要说明的是,这个数值表示当前机器的整体性能,值越大越好。

2、并发连接数(The number of concurrent connections)

并发连接数指的是某个时刻服务器所接受的请求数目,简单的讲,就是一个会话。

3、并发用户数(Concurrency Level)

要注意区分这个概念和并发连接数之间的区别,一个用户可能同时会产生多个会话,也即连接数。在HTTP/1.1下,IE7支持两个并发连接,IE8支持6个并发连接,FireFox3支持4个并发连接,所以相应的,我们的并发用户数就得除以这个基数。

4、用户平均请求等待时间(Time per request)

计算公式:处理完成所有请求数所花费的时间/(总请求数/并发用户数),即:

Time per request=Time taken for tests/(Complete requests/Concurrency Level)

5、服务器平均请求等待时间(Time per request:across all concurrent requests)

计算公式:处理完成所有请求数所花费的时间/总请求数,即:

Time taken for/testsComplete requests

可以看到,它是吞吐率的倒数。

同时,它也等于用户平均请求等待时间/并发用户数,即

Time per request/Concurrency Level


5.ab测试实例

ab -c 10 -n 100 http://127.0.0.1/index.php

-c10表示并发用户数为10

-n100表示请求总数为100

这行表示同时处理100个请求并运行10次index.php文件

Server Software:        Apache/2.0.54

//平台apache 版本2.0.54

Server Hostname:        127.0.0.1

//服务器主机名

Server Port:            80

//服务器端口

Document Path:          /index.html.zh-cn.gb2312

//测试的页面文档

Document Length:        1018 bytes

//文档大小

Concurrency Level:      1000

//并发数

Time taken for tests:   8.188731 seconds

//整个测试持续的时间

Complete requests:      1000

//完成的请求数量

Failed requests:        0

//失败的请求数量

Write errors:           0


Total transferred:      1361581 bytes

//整个场景中的网络传输量

HTML transferred:       1055666 bytes

//整个场景中的HTML内容传输量

Requests per second:    122.12 [#/sec] (mean)

//大家最关心的指标之一,相当于 LR 中的 每秒事务数 ,后面括号中的 mean 表示这是一个平均值

Time per request:       8188.731 [ms] (mean)

//大家最关心的指标之二,相当于 LR 中的 平均事务响应时间 ,后面括号中的 mean 表示这是一个平均值

Time per request:       8.189 [ms] (mean, across all concurrent requests)

//每个请求实际运行时间的平均值

Transfer rate:          162.30 [Kbytes/sec] received

//平均每秒网络上的流量,可以帮助排除是否存在网络流量过大导致响应时间延长的问题

Connection Times (ms)

              min mean[+/-sd] median   max

Connect:        4 646 1078.7     89    3291

Processing:   165 992 493.1    938    4712

Waiting:      118 934 480.6    882    4554

Total:        813 1638 1338.9   1093    7785

//网络上消耗的时间的分解,各项数据的具体算法还不是很清楚

Percentage of the requests served within a certain time (ms)

50%   1093

66%   1247

75%   1373

80%   1493

90%   4061

95%   4398

98%   5608

99%   7368

100%   7785 (longest request)

//整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间,其中50%的用户响应时间小于1093 毫秒,60%的用户响应时间小于1247 毫秒,最大的响应时间小于7785 毫秒

由于对于并发请求,cpu实际上并不是同时处理的,而是按照每个请求获得的时间片逐个轮转处理的,所以基本上第一个Time per request时间约等于第二个Time per request时间乘以并发请求数


6.报错如下:

报错1:apr_socket_recv: Connection reset by peer (104)

报错2:[crit] 4503#0: accept4() failed (24: Too many open files)

以下方法没解决:

一看就知道系统对打开文件数目做了限制,用下面命令

ulimit -n    查看当前用户的

命令查看了一下,结果显示文件打开数目限制为1024,我们需要让这个数字更大一些,好让我们的网站访问并发更高一些。

下面是修改 ulimit 限制数的方法:

1.首先你得修改nginx.conf配置文件,在定义error.log日志路径的位置添加一行

worker_rlimit_nofile 65535;

2.在/etc/profile文件最后面添加下面内容

ulimit -n 65535

3.在/etc/security/limits.conf文件最后面添加下面内容

* soft nofile 65535

* hard nofile 65535


7.shell封装ab的测试脚本

#!/bin/sh


total_request=10000

concurrency=100

times=1

cmd_idx=1

param_count=$#


while [ $cmd_idx -lt $param_count ]

do

        cmd=$1

        shift 1 #remove $1

        case $cmd in

        -n)

                total_request=$1

                shift 1;;

        -c)

                concurrency=$1

                shift 1;;

        -t)

        times=$1

        shift 1;;

        *)

        echo "$cmd, support parameter: -n, -c, -t";;

        esac

        cmd_idx=`expr $cmd_idx + 2`

done


url=$1

if [ $url = '' ];then

        echo 'the test url must be provided...'

        exit 2

fi


echo "Total Request: $total_request, Concurrency: $concurrency, URL: $url, Times: $times"


ab_dir=/usr/bin

ab_cmd="$ab_dir/ab -n $total_request -c $concurrency $url"


echo $ab_cmd

idx=1

rps_sum=0

max=-1

min=99999999

while [ $idx -le $times ]

do

        echo "start loop $idx"

        result=`$ab_cmd | grep 'Requests per second:'`

        result=`echo $result | awk -F ' ' '{ print $4 }' | awk -F '.' '{ print $1 }'`

        rps_sum=`expr $result + $rps_sum`

        if [ $result -gt $max ];then

                max=$result

        fi

        if [ $result -lt $min ];then

                min=$result

        fi

        idx=`expr $idx + 1`

done

echo "avg rps: "`expr $rps_sum / $times`

echo "min rps: $min"

echo "max rps: $max"


本文转自 guowang327 51CTO博客,原文链接:http://blog.51cto.com/guowang327/1712553,如需转载请自行联系原作者

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
15天前
|
人工智能 搜索推荐 Serverless
使用金庸的著作,来测试阿里通义千问最新开放的长文档处理功能
使用金庸的著作,来测试阿里通义千问最新开放的长文档处理功能
35 7
使用金庸的著作,来测试阿里通义千问最新开放的长文档处理功能
|
1月前
|
敏捷开发 运维 测试技术
探索自动化测试在持续集成环境中的关键作用
【2月更文挑战第18天】 随着敏捷开发和DevOps文化的普及,持续集成(CI)已成为软件开发过程中不可或缺的组成部分。本文将深入探讨自动化测试在持续集成环境中的重要性,分析其如何提高软件交付速度、保障质量并减少人工干预。通过对现代软件工程实践中自动化测试策略的剖析,揭示了其在维护高效率和高质量软件产品中的核心地位。
30 7
|
1月前
|
Java
【Java每日一题】— —第二十一题:编程把现实生活的手机事物映射成一个标准类Phone,并定义一个测试类PhoneDemo测试Phone类的功能
【Java每日一题】— —第二十一题:编程把现实生活的手机事物映射成一个标准类Phone,并定义一个测试类PhoneDemo测试Phone类的功能
35 0
|
1月前
|
敏捷开发 监控 jenkins
探索自动化测试在持续集成环境中的关键作用
【2月更文挑战第14天】 随着敏捷开发和持续集成(CI)的普及,自动化测试已成为确保软件质量和加速交付过程的重要环节。本文旨在深入探讨自动化测试在持续集成环境中的核心价值,分析其如何提高测试效率,减少人工错误,并保障产品的快速迭代与发布。通过对自动化测试工具、策略及最佳实践的综合评述,为读者呈现一个全面的自动化测试实施指南。
18 0
|
2月前
|
关系型数据库 MySQL Linux
centos7.0环境下安装MySql_8.0.12
centos7.0环境下安装MySql_8.0.12
|
1月前
|
存储 JavaScript Linux
Linux环境下安装nmp(Centos环境)保姆级教学 一步到位
Linux环境下安装nmp(Centos环境)保姆级教学 一步到位
|
1月前
|
敏捷开发 监控 Devops
探索自动化测试在持续集成环境中的关键作用
【2月更文挑战第15天】 本文旨在探讨自动化测试作为软件开发过程中不可或缺的一环,尤其在持续集成(CI)环境中的显著影响。通过深入分析自动化测试的实施策略和最佳实践,文章揭示了如何有效提升软件交付速度和质量。文中不仅讨论了自动化测试的基本概念和框架选择,还详细阐述了其在CI流程中的关键步骤及潜在挑战,并提出了相应的解决方案。
19 4
|
1月前
|
敏捷开发 测试技术 持续交付
探索自动化测试在持续集成环境中的关键作用
【2月更文挑战第15天】 随着敏捷开发和持续集成(CI)实践的普及,自动化测试已成为确保软件质量和加速产品上市速度的核心环节。本文将深入探讨自动化测试在持续集成环境中的重要性,分析其如何提高测试效率,减少人工干预的错误,并实现快速反馈循环。通过案例分析和最佳实践分享,我们将揭示自动化测试策略对提升软件开发流程的影响,以及如何有效地将其整合到现代软件生命周期管理中。
|
13天前
|
jenkins 测试技术 持续交付
软件测试|docker搭建Jenkins+Python+allure自动化测试环境
通过以上步骤,你可以在Docker中搭建起Jenkins自动化测试环境,实现Python测试的自动化执行和Allure报告生成。 买CN2云服务器,免备案服务器,高防服务器,就选蓝易云。百度搜索:蓝易云
32 6
|
1月前
|
敏捷开发 监控 数据管理
探索自动化测试在持续集成环境中的关键角色
【2月更文挑战第24天】 在当今软件开发的快节奏环境中,自动化测试不再是一个选择,而是确保产品质量和加速市场交付的必要条件。本文将深入探讨自动化测试在持续集成(CI)环境中的重要性,分析其如何提高测试效率、降低错误率,并最终促进开发流程的持续改进。我们将通过具体的案例研究和最佳实践,揭示自动化测试策略的关键要素,以及如何在CI流程中有效集成自动化测试。

热门文章

最新文章