centOS环境ab性能测试功能

本文涉及的产品
性能测试 PTS,5000VUM额度
简介:

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进行规格选择与性能压测。
相关文章
|
19天前
|
机器学习/深度学习 人工智能 算法
BALROG:基准测试工具,用于评估 LLMs 和 VLMs 在复杂动态环境中的推理能力
BALROG 是一款用于评估大型语言模型(LLMs)和视觉语言模型(VLMs)在复杂动态环境中推理能力的基准测试工具。它通过一系列挑战性的游戏环境,如 NetHack,测试模型的规划、空间推理和探索能力。BALROG 提供了一个开放且细粒度的评估框架,推动了自主代理研究的进展。
31 3
BALROG:基准测试工具,用于评估 LLMs 和 VLMs 在复杂动态环境中的推理能力
|
24天前
|
缓存 Ubuntu Linux
Linux环境下测试服务器的DDR5内存性能
通过使用 `memtester`和 `sysbench`等工具,可以有效地测试Linux环境下服务器的DDR5内存性能。这些工具不仅可以评估内存的读写速度,还可以检测内存中的潜在问题,帮助确保系统的稳定性和性能。通过合理配置和使用这些工具,系统管理员可以深入了解服务器内存的性能状况,为系统优化提供数据支持。
31 4
|
2月前
|
Web App开发 搜索推荐 Unix
Linux系统之MobaXterm远程连接centos的GNOME桌面环境
【10月更文挑战第21天】Linux系统之MobaXterm远程连接centos的GNOME桌面环境
381 4
Linux系统之MobaXterm远程连接centos的GNOME桌面环境
|
1月前
|
机器学习/深度学习 自然语言处理 前端开发
前端神经网络入门:Brain.js - 详细介绍和对比不同的实现 - CNN、RNN、DNN、FFNN -无需准备环境打开浏览器即可测试运行-支持WebGPU加速
本文介绍了如何使用 JavaScript 神经网络库 **Brain.js** 实现不同类型的神经网络,包括前馈神经网络(FFNN)、深度神经网络(DNN)和循环神经网络(RNN)。通过简单的示例和代码,帮助前端开发者快速入门并理解神经网络的基本概念。文章还对比了各类神经网络的特点和适用场景,并简要介绍了卷积神经网络(CNN)的替代方案。
103 1
|
1月前
|
编解码 安全 Linux
网络空间安全之一个WH的超前沿全栈技术深入学习之路(10-2):保姆级别教会你如何搭建白帽黑客渗透测试系统环境Kali——Liinux-Debian:就怕你学成黑客啦!)作者——LJS
保姆级别教会你如何搭建白帽黑客渗透测试系统环境Kali以及常见的报错及对应解决方案、常用Kali功能简便化以及详解如何具体实现
|
2月前
|
分布式计算 Hadoop 大数据
大数据体系知识学习(一):PySpark和Hadoop环境的搭建与测试
这篇文章是关于大数据体系知识学习的,主要介绍了Apache Spark的基本概念、特点、组件,以及如何安装配置Java、PySpark和Hadoop环境。文章还提供了详细的安装步骤和测试代码,帮助读者搭建和测试大数据环境。
69 1
|
2月前
|
前端开发 测试技术 程序员
在工作中会涉及到的几个环境(概念补充) 办公环境、开发环境、测试环境、线下环境、线上环境/生产环境都是什么,他们之间的关系?
本文解释了在职场中可能会接触到的不同环境,包括办公环境、开发环境、测试环境和生产环境(线上环境),以及它们之间的关系和重要性。
97 1
|
2月前
|
安全 Linux 数据库连接
CentOS 7环境下DM8数据库的安装与配置
【10月更文挑战第16天】本文介绍了在 CentOS 7 环境下安装与配置达梦数据库(DM8)的详细步骤,包括安装前准备、创建安装用户、上传安装文件、解压并运行安装程序、初始化数据库实例、配置环境变量、启动数据库服务、配置数据库连接和参数、备份与恢复、以及安装后的安全设置、性能优化和定期维护等内容。通过这些步骤,可以顺利完成 DM8 的安装与配置。
323 0
|
网络协议 前端开发 JavaScript
CentOS 环境下部署 vsftpd
CentOS 环境下部署 vsftpd
221 0
|
存储 关系型数据库 MySQL
CentOS 9 环境编译部署 MySQL 8.0.30
CentOS 9 环境编译部署 MySQL 8.0.30
819 0