charles服务器压力测试怎么看压测结果 服务器 压力测试

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

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

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

[root@webbench-1.5]# make  
cc -Wall -ggdb -W -O   -c -o webbench.o webbench.c  
webbench.c: In function ‘alarm_handler’:  
webbench.c:77: warning: unused parameter ’signal’  
cc -Wall -ggdb -W -O   -o webbench webbench.o  
ctags *.c  
/bin/sh: ctags: command not found  
make: [tags] Error 127 (ignored)

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

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

install -s webbench /usr/local/bin  
install -m 644 webbench.1 /usr/local/man/man1  
install: cannot create regular file `/usr/local/man/man1′: No such file or directory

报错：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），那么请建之。

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

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

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

tar zxfv tsung-1.4.2. tar .gz cd tsung-1.4.2 . /configure && make && make install

使用

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

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

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

<? xml version = "1.0" ?> <!DOCTYPE tsung SYSTEM "/usr/share/tsung/tsung-1.0.dtd"> < tsung loglevel = "notice" version = "1.0" > < clients > < client host = "localhost" weight = "1" cpu = "10" maxusers = "40000" > < ip value = "192.168.122.2" /> </ client > < client host = "loadnode1" weight = "1" cpu = "9" maxusers = "40000" > < ip value = "192.168.122.2" /> </ client > < client host = "loadnode2" weight = "1" maxusers = "40000" cpu = "8" > < ip value = "192.168.122.3" /> </ client > < client host = "loadnode3" weight = "1" maxusers = "40000" cpu = "9" > < ip value = "192.168.122.21" /> </ client > < client host = "loadnode4" weight = "1" maxusers = "40000" cpu = "9" > < ip value = "192.168.122.11" /> </ client > < client host = "loadnode5" weight = "1" maxusers = "40000" cpu = "9" > < ip value = "192.168.122.12" /> </ client > < client host = "loadnode6" weight = "1" maxusers = "40000" cpu = "9" > < ip value = "192.168.122.13" /> </ client > < client host = "loadnode7" weight = "1" maxusers = "40000" cpu = "9" > < ip value = "192.168.122.14" /> </ client > </ clients > < servers > < server host = "192.168.122.10" port = "80" type = "tcp" /> </ servers > < load > < arrivalphase phase = "1" duration = "10" unit = "minute" > < users maxnumber = "15000" arrivalrate = "8" unit = "second" /> </ arrivalphase > < arrivalphase phase = "2" duration = "10" unit = "minute" > < users maxnumber = "15000" arrivalrate = "8" unit = "second" /> </ arrivalphase > < arrivalphase phase = "3" duration = "30" unit = "minute" > < users maxnumber = "20000" arrivalrate = "3" unit = "second" /> </ arrivalphase > </ load > < sessions > < session probability = "100" name = "ab" type = "ts_http" > < for from = "1" to = "10000000" var = "i" > < request > < http url = "/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 alias treport= "/usr/lib/tsung/bin/tsung_stats.pl; firefox report.html"

source ~/.bashrc

        然后启动 Tsung

[root@loadnode1 ~] tsung start Starting Tsung "Log directory is: /root/.tsung/log/20120421-1004"

        结束后观察报告

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 进行压力测试。