服务器压力测试 性能测试 AB、Webbench、Tsung

原文：https://blog.csdn.net/Jerome_s/article/details/47030671

负载生成器是一些生成用于测试的流量的程序。它们可以向你展示服务器在高负载的情况下的性能，以及让你能够找出服务器可能存在的问题。为了得到更加客观和准确的数值，应该从远程访问、局域网访问和本地等多个方面进行全方位的测试。一般用127.0.0.1进行本机测试。

Apache Benchmark

ab 命令会创建很多的并发访问线程，模拟多个访问者同时对某一 URL 进行访问，可用来测试 Apache 的负载压力，也可以测试 Nginx、lighthttp、IIS 等其它 Web 服务器的压力。

1. 安装

Unix 安装：yum install httpd

Windows安装：下载 http://pan.baidu.com/s/1mifnlUS

在安装目录 bin下可以看到 ab.exe。

2. 使用

为了避免因为网络原因而导致服务器压力测试结果不准确，一般可以用 ab -n 100 -c 50 http://127.0.0.1/index.php 来测试自己服务器Web性能。所有 ab 命令的组成遵循此结构：   ab [options] [full path to web document] 。

ab -n 1000 -c 10 http://www.qq.com/

“-n”表示：每次请求数，默认不能超过1024个，“-c”表示：1个请求的并发连接数，默认最大不能超过50000

可选标记


标记
描述

-A

<username>:<password>
用于提供服务器身份验证信息。

用户名和密码用“:”分隔。

发送的字符串采用base64编码

-c <concurrency

number>
一次模拟的请求数。默认情

况下设置为1。数量不得大于n值

-C cookie-name=value
可重复的标记，包含cookie信息

-d
隐藏“percentage served

within XX[ms] table”

标记
描述

-e
要创建的.csv文件的路径。该文件包

含运行的基准测试的结果，该结果分为

两列，即Percentage和Time in ms。建议

采用“gnuplot”文件

-g
要创建的“gnuplot”或TSV文件的路径。

基准测试的输出将保存到该文件中

-h
显示要用于ab的选项列表

-H custom-header
采用字段值对形式发送有效标头和请求

-i
执行HEAD请求，而不是默认的GET请求

-k
启用Keep-Alive功能。允许通过一个

HTTP会话满足多个请求。默认情况下，

该功能处于禁用状态

-n requests
要执行的请求总数

-p POST-file
包含用于HTTP POST请求的数据的

文件路径。内容应该包含由&分隔的键=值对

-P username:password
采用Base64编码的字符串。字符串包含

基本身份验证，以及由“:”分隔的用户名和密码

-q
执行多于100个请求时隐藏进度输出

-s
使用https协议，而非默认的http协议

——不建议这样做

-S
隐藏中位数和标准偏差值

-t timelimit
指定了这个值以后，基准测试的时间

不会超过指定的值。默认情况下无时间限制

-v verbosity-level
数值为2及以上将打印警告和信息；

为3将打印HTTP响应代码；4及以

上将打印标头信息

-V
显示ab工具的版本号

-w
采用HTML表格打印结果

-x <table-attributes>
表示HTML属性的字符串，

使用–w时将放置在<table>标记中

-X proxy[:port]
指定要使用的代理服务器。

代理端口是可选的

-y <tr-attributes>
表示HTML属性的字符串，

使用–w时将放置在<tr>标记中

-z <td-attributes>
表示HTML属性的字符串，

使用–w时将放置在<td>标记中

响应描述


字段
描述
示　例　值

Concurrency Level
所进行的并发请求总数
1,2,3,…,n，

其中n为任意数字

Time taken for tests
运行所花费的总时间
000.000秒

Complete requests
模拟的请求总数中已

完成的请求总数
1,2,3,…,n，

其中n为任意数字

字段
描述
示　例　值

Failed requests
模拟的请求总数

中失败的请求总数
1,2,3, …,n，

其中n为任意数字

Write errors
使用写入数据时

遇到的错误总数
1,2,3, …,n，

其中n为任意数字

Non-2×× responses
未收到HTTP成功

响应的请求总数(200)
1,2,3,…,n，

其中n为任意数字

Total transferred
整个模拟的响应中

传输的总数据，

大小包括标头数据
725个字节

HTML transferred
整个模拟传输的内容

正文的总大小
137 199个字节

Requests per second
每秒支持的请求总数
5.68 [#/秒]

（平均值）

Time per request
满足一个请求需要

花费的总时间
176.179毫秒

Time per request
满足所有并发请求

中的一个请求需要

花费的总时间
176.179毫秒

Transfer rate
每秒收到的字节总数（KB）
766.27 [KB/秒]

HTML transferred、Requests per second 以及 Time per request 都是关键字段。根据这些数据，我们能大概了解 Web 服务器的性能水平，这些字段使我们能够大概了解Web服务器为一个请求返回的数据量、Web服务器一秒可以处理的请求总数以及一个请求成功地收到来自Web服务器的响应所花费的总时间。

我们的目标是成功降低 HTML transferred，提高 Requests per second 并且降低 Time per request 值。

其他字段解释

1、吞吐率（Requests per second）

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

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

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

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

计算公式：总请求数/处理完成这些请求数所花费的时间，即 Request per second=Complete requests/Time taken for tests 。

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

2、用户平均请求等待时间（Time per request）

计算公式：处理完成所有请求数所花费的时间/（总请求数/并发用户数），即： Time per request=Time taken for tests/（Complete requests/Concurrency Level） 。

3、服务器平均请求等待时间（Time per request:across all concurrent requests）

计算公式：处理完成所有请求数所花费的时间/总请求数，即： Time taken for/testsComplete requests 。

可以看到，它是吞吐率的倒数。 同时，它也等于用户平均请求等待时间/并发用户数，即 Time per request/Concurrency Level 。

最后一个部分包含一个表，其中包含Connect、Processing、Waiting以及Total字段。这些字段告诉我们请求在每个过程状态中所需的时间。我们最感兴趣的是Total字段及其最大、最小值列。这两列提供响应一个请求所需花费的最长和最短时间的数据。

Webbench

Webbench 最多可以模拟3万个并发连接数来测试服务器压力，可以设置压力测试时间和测试请求的成功率。

1. 安装：

[html] view plain copy

  1. wget http://blog.s135.com/soft/linux/webbench/webbench-1.5.tar.gz
  2. tar zxvf webbench-1.5.tar.gz
  3. cd webbench-1.5
  4. make && make install

如果在编译webbench的时候，出现/bin/sh: ctags: command not found，如下所示

[html] view plain copy

  1. [[email protected]]# make
  2. cc -Wall -ggdb -W -O   -c -o webbench.o webbench.c
  3. webbench.c: In function ‘alarm_handler’:
  4. webbench.c:77: warning: unused parameter ’signal’
  5. cc -Wall -ggdb -W -O   -o webbench webbench.o
  6. ctags *.c
  7. /bin/sh: ctags: command not found
  8. make: [tags] Error 127 (ignored)

是没安装ctags组件，使用yum -y install ctags,解决问题

如果安装了ctags, 仍然报错:

[php] view plain copy

  1. install -s webbench /usr/local/bin
  2. install -m 644 webbench.1 /usr/local/man/man1
  3. install: cannot create regular file `/usr/local/man/man1′: No such file or directory
  4. make: *** [install] Error 1

解决方法
mkdir -m 644 -p /usr/local/man/man1

2. 使用

webbench -c 1000 -t 10 http://www.qq.com/index.php

-c是并发数 -t是运行测试时间，即10秒钟内中以每次100个请求进行测试。

这是运行Webbench测试结果，Speed显示的是每分钟响应请求数和每秒钟传输数据量，Requests显示的是成功请求数和失败请求数。

为准确得到服务器的承受压力，测试时并发数可逐渐加大，如并发100时观察一下网站负载是多少、打开页面是否流畅，当网站打开缓慢时并发是多少、网站打不开时并发又是多少。

Tsung

Tsung 是一款重型的（heavy-duty）、分布式的、多协议测试工具。它每秒基本可以产生 40,000 个请求，这绝对是我们想要的工具。类似于 Jmeter，你可以把一些行为记录下来在测试时运行，并且可以测试大多数的协议。比如 SSL、HHTP、WebDAV、SOAP、PostgreSQL、MySQL、LDAP 和 Jabber/XMPP。与 Jmeter 不同的是，它没有让人感到迷茫的 GUI 设置，它仅有一个 XML 配置文件，和一些你选择的分布式节点的 SSH 密钥。它的简洁和效率对我的吸引力，完全不亚于它的健壮性和可扩展性。我发现它是一个很强大的工具，在正确的配置下它可以每秒产生百万级的 HTTP 请求。

除此之外，Tsung 还可以在 HTML 上产生图表以及输入你的测试的详细报告。

在 CentOS 6.2 上安装 Tsung

1. 首先，你要安装（Erlang 需要的） EPEL 源。因此，在进行下一步之前要把它安装好。安装完后，继续安装你用来产生负载的每个节点需要的包。如果你还没有在节点之间建立无密码 SSH 密钥（passwordless SSH key），那么请建之。


1

yum -y install erlang perl perl-RRD-Simple.noarch perl-Log-Log4perl-RRDs.noarch gnuplot perl-Template-Toolkit firefox

2. 从 Github 或者 Tsung 的官网上下载最新的 Tsung。


1

wget http://tsung.erlang-projects.org/dist/tsung-1.4.2.tar.gz

3. 解压并且编译


1

2

3

tar zxfv  tsung-1.4.2.tar.gz

cd tsung-1.4.2

./configure && make && make install

使用

把示例配置复制到 ~/.tsung 目录里。这是 Tsung 的配置文件和日志文件的存放地方（目录不存在创建即可）。


1

cp  /usr/share/doc/tsung/examples/http_simple.xml /root/.tsung/tsung.xml

你可以根据你的需求去编辑这个配置文件，或者使用我的配置文件。经过大量的尝试以及失败后，我目前的配置文件在使用 7 个分布式节点时可以每秒产生 5 百万个 HTTP 请求。


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

<?xmlversion="1.0"?>

<!DOCTYPE tsung SYSTEM "/usr/share/tsung/tsung-1.0.dtd">

<tsungloglevel="notice"version="1.0">

<clients>

<clienthost="localhost"weight="1"cpu="10"maxusers="40000">

<ipvalue="192.168.122.2"/>

</client>

<clienthost="loadnode1"weight="1"cpu="9"maxusers="40000">

<ipvalue="192.168.122.2"/>

</client>

<clienthost="loadnode2"weight="1"maxusers="40000"cpu="8">

<ipvalue="192.168.122.3"/>

</client>

<clienthost="loadnode3"weight="1"maxusers="40000"cpu="9">

<ipvalue="192.168.122.21"/>

</client>

<clienthost="loadnode4"weight="1"maxusers="40000"cpu="9">

<ipvalue="192.168.122.11"/>

</client>

<clienthost="loadnode5"weight="1"maxusers="40000"cpu="9">

<ipvalue="192.168.122.12"/>

</client>

<clienthost="loadnode6"weight="1"maxusers="40000"cpu="9">

<ipvalue="192.168.122.13"/>

</client>

<clienthost="loadnode7"weight="1"maxusers="40000"cpu="9">

<ipvalue="192.168.122.14"/>

</client>

</clients>

<servers>

<serverhost="192.168.122.10"port="80"type="tcp"/>

</servers>

<load>

<arrivalphasephase="1"duration="10"unit="minute">

<usersmaxnumber="15000"arrivalrate="8"unit="second"/>

</arrivalphase>

<arrivalphasephase="2"duration="10"unit="minute">

<usersmaxnumber="15000"arrivalrate="8"unit="second"/>

</arrivalphase>

<arrivalphasephase="3"duration="30"unit="minute">

<usersmaxnumber="20000"arrivalrate="3"unit="second"/>

</arrivalphase>

</load>

<sessions>

<sessionprobability="100"name="ab"type="ts_http">

<forfrom="1"to="10000000"var="i">

<request> <httpurl="/test.txt"method="GET"version="1.1"/> </request>

</for>

</session>

</sessions>

</tsung>

刚开始的时候有很多东西要理解，但你一旦理解了它们后就会变得很简单。

<client> 只是简单地指定了运行 Tsung 的主机。你可以指定 Tsung 使用的 IP 和 CPU 的最大数。你可以使用 maxusers 设置节点能够模拟的用户数量上限。每一个用户都会执行我们之后定义的操作。

<servers> 指定了你要测试的 HTTP 服务器。我们可以使用这个选项去测试一个 IP 集群，或者一个单一的服务器。

<load> 定义了我们的模拟用户将会在什么时候“到达”我们的网站。以及它们达到的有多快。

<arrivalphase> 在持续了 10 分钟的第一个阶段里，以 每秒 8 个用户的速率到达了 15,000 个用户。

<arrivalphase phase=”1″ duration=”10″ unit=”minute”>

<users maxnumber=”15000″ arrivalrate=”8″ unit=”second”/>

这里还有两个 arrivalphases，它们的用户都以同样的方式达到。

这些 arrivalphases 一起组成了一个 <load>，它控制了我们可以每秒产生多少个请求。

<session> 这部分定义了一旦这些用户达到了你的网站，它们将会执行什么动作。

probability 允许你定义用户可能会做的随机事件。有时他们可能点击这里，有时他们可能点击那里。所有的Probability 加起来一定要等于 100% 。

在上面的配置里，用户只做一件事，所以它的 probability 等于 100% 。

<for from=”1″ to=”10000000″ var=”i”> 这就是用户在 100% 的时间里做的事情。它们循环遍历 10,000,000 次并且 <request> 一个网页：/test.txt 。

这个循环结构允许我们使用少量的用户连接去获取比较大的每秒请求数量。

一旦你已经很好地理解了它们，你就可以创建一个便利的别名，去快速观察 Tsung 报告。

vim ~/.bashrc

aliastreport="/usr/lib/tsung/bin/tsung_stats.pl; firefox report.html"

1

source~/.bashrc

然后启动 Tsung


1

2

3

[[email protected] ~] tsung start

Starting Tsung

"Log directory is: /root/.tsung/log/20120421-1004"

结束后观察报告


1

2

cd/root/.tsung/log/20120421-1004

treport #生成图片报告

把20120421-1004通过 ftp下载下来就可以使用查看了，如下图

使用 Tsung 去规划你的集群构造

现在我们拥有了一个足够强大的负载测试工具，我们可以规划余下的集群构造了：

1. 使用 Tsung 去测试一个单一的 HTTP 服务器。获取一个基本的基准。

2. 对 web 服务器进行调优，定期使用 Tsung 进行测试提高性能。

3. 对这些系统的 TCP 套接字进行调优，获取最佳的网络性能。再来一次，测试，测试，不停地测试。

4. 构造 LVS 集群，它包含了这些充分调优过的 web 服务器。

5. 使用 Tsung IP 集群对 LVS 进行压力测试。

原文地址：https://www.cnblogs.com/killall007/p/8952176.html

时间： 2024-10-13 02:18:24

服务器压力测试 性能测试 AB、Webbench、Tsung的相关文章

[转]web服务器压力测试工具

http_load学习心得: 测试网站每秒所能承受的平均访问量(吞吐量) http_load -parallel 5 -fetches 1000 urls.txt这段命令行是同时使用5个进程,随机访问urls.txt中的网址列表,总共访问1000次.运行之后的结果: 1000 fetches, 5 max parallel, 6e+06 bytes, in 58.1026 seconds6000 mean bytes/connection17.2109 fetches/sec, 103266 b

（总结）Web性能压力测试工具之WebBench详解

PS:在运维工作中,压力测试是一项很重要的工作.比如在一个网站上线之前,能承受多大访问量.在大访问量情况下性能怎样,这些数据指标好坏将会直接影响用户体验.但是,在压力测试中存在一个共性,那就是压力测试的结果与实际负载结果不会完全相同,就算压力测试工作做的再好,也不能保证100%和线上性能指标相同.面对这些问题,我们只能尽量去想方设法去模拟.所以,压力测试非常有必要,有了这些数据,我们就能对自己做维护的平台做到心中有数. Webbench是知名的网站压力测试工具,它是由Lionbridge公司(h

Nginx压力测试工具之WebBench

Nginx压力测试工具之WebBench 在Apache中有自带的ab命令可以测试服务的压力,而nginx没有自带的命令,必须要采用第三方软件来测试,今天就简单介绍一下webbench对nginx的压力测试,压力测试是对系统管理员和运维人员必须的,可以很清晰地看清服务器能接受多大压力.注:本人是在虚拟机上做测试. 1.下载webbench软件和安装 wget http://home.tiscali.cz/~cz210552/distfiles/webbench-1.5.tar.gz tar xv

推荐一个linux下的web压力测试工具神器webbench

推荐一个linux下的web压力测试工具神器webbench2014-04-30 09:35:29   来源:   评论:0 点击:880 用多了apache的ab工具之后你就会发现ab存在很多问题, 那么怎么办呢, 今天推荐一个神器---webbench webbench最多可以模拟3万个并发连接去测试网站的负载能力,个人感觉要比Apache自带的ab压力测试工具好, 用多了apache的ab工具之后你就会发现ab存在很多问题, 那么怎么办呢, 今天推荐一个神器---webbench    

Apache自带压力测试工具AB的使用方法

什么是压力测试,为什么要进行压力测试? 压力测试通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大的服务级别的测试.通俗地讲,压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受.再简单点,就是你网站的性能的一个评定,性能由本身程序和网站服务器共同决定. 而进行压力测试,就是为了让你更好得掌握网站的各个信息. Apache自带工具AB是什么? Apache Benchmark简称为ab,是apache自带的用于HTTP Server测试的工具.它可以接受单一的URL,然

Apache中压力测试工具ab的操作说明

1.压力测试工具ab(ApacheBench)的简单说明 1)     网站性能压力测试是性能调优过程中必不可少的一环.只有让服务器处在高压情况下才能真正体现出各种设置所暴露的问题.Apache中有个自带的,名为ab的程序,可以对Apache或其它类型的服务器进行网站访问压力测试. 2)     ApacheBench命令原理: ab命令会创建很多的并发访问线程,模拟多个访问者同时对某一URL地址进行访问.它的测试目标是基于URL的,因此,既可以用来测试Apache的负载压力,也可以测试ngin

【技测】游戏上线前服务器压力测试应该怎么做

伴随手游上线推广,玩家爆发式增长,不少开发者都遇到过玩家冲爆服务器的情况,因此降低服务器崩溃的风险就显得非常重要.游戏上线前如果做了服务器压力测试帮助会很大.今天就来说说压力测试. 编写脚本机器人 为了在游戏上线前实际掌握服务器的承载能力,在游戏的开发流程末端都会引入压力测试.最普遍的一种测试方式是机器人模拟测试.通过脚本机器人在游戏中模拟一个玩家可能进行的操作,几千个机器人在服务器里面连续执行各种操作,测试各处功能的完整度. 脚本机器人是大部分CP在上线前的一个重要压测手段,因为这是低成本下最

C++实现服务器压力测试框架

C++实现服务器压力测试框架 flyfish 2015-3-9 模拟大量客户端对服务器进行压力测试框架 头文件 #pragma once #include <boost/asio.hpp> #include <boost/array.hpp> #include <boost/bind.hpp> #include <boost/asio/deadline_timer.hpp> #include <boost/enable_shared_from_this

Web压力测试工具 ab

ab是apache自带的一款功能强大的测试工具.非常容易使用.并且完全可以模拟各种条件对Web服务器发起测试请求 ab可以直接在Web服务器本地发起测试请求,这对于需要了解服务器的处理性能至关重要,因为它不包括数据的网络传输时间以及用户PC本地的计算时间 安装了apache一般就自带了 ab 的用法 ab [options] [http://]hostname[:port]/path 例如:ab -n 10000 -c 200 http://localhost/index.php 上例表示总共访