简介

ab的全称是ApacheBench，是 Apache 附带的一个小工具，专门用于 HTTP Server 的benchmark testing，可以同时模拟多个并发请求。前段时间看到公司的开发人员也在用它作一些测试，看起来也不错，很简单，也很容易使用，所以今天花一点时间看了一下。

通过下面的一个简单的例子和注释，相信大家可以更容易理解这个工具的使用。

一个简单的例子

/*在这个例子的一开始，我执行了这样一个命令 ab -n 10 -c 10 http://www.google.com/。这个命令的意思是启动 ab ，向www.google.com 发送10个请求(-n 10) ，并每次发送10个请求(-c 10)——也就是说一次都发过去了。跟着下面的是 ab 输出的测试报告，红色部分是我添加的注释。*/

C:\Program Files\Apache Software Foundation\Apache2.2\bin>ab -n 10 -c 10 http

://www.google.com/

This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Copyright 1997-2005 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.google.com (be patient)…..done

Server Software:        GWS/2.1

Server Hostname:        www.google.com

Server Port:            80

Document Path:          /

Document Length:        230 bytes

Concurrency Level:      10

/*整个测试持续的时间*/

Time taken for tests:   3.234651 seconds

/*完成的请求数量*/

Complete requests:      10

/*失败的请求数量*/

Failed requests:        0

Write errors:           0

Non-2xx responses:      10

Keep-Alive requests:    10

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

Total transferred:      6020 bytes

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

HTML transferred:       2300 bytes

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

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

/*每次并发请求时间(所有并发), 大家最关心的指标之二，相当于 LR 中的 平均事务响应时间 ，后面括号中的 mean 表示这是一个平均值*/

Time per request:       3234.651 [ms] (mean)

/*每一请求时间(并发平均)  //每个请求实际运行时间的平均值*/

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

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

Transfer rate:          1.55 [Kbytes/sec] received

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

Connection Times (ms)

min  mean[+/-sd] median   max

Connect:       20  318 926.1     30    2954

Processing:    40 2160 1462.0   3034    3154

Waiting:       40 2160 1462.0   3034    3154

Total:         60 2479 1276.4   3064    3184

/*下面的内容为整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中 50％ 的用户响应时间小于 3064 毫秒，60 ％ 的用户响应时间小于 3094 毫秒，最大的响应时间小于 3184 毫秒*/

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

50%   3064

66%   3094

75%   3124

80%   3154

90%   3184

95%   3184

98%   3184

99%   3184

100%   3184 (longest request)

更多信息

ab 不像 LR 那么强大，但是它足够轻便，如果只是在开发过程中想检查一下某个模块的响应情况，或者做一些场景比较简单的测试，ab 还是一个不错的选择——至少不用花费很多时间去学习 LR 那些复杂的功能，就更别说那 License 的价格了。

下面是 ab 的详细参数解释，大家有兴趣的可以研究一下，最近没有足够多的时间研究，如果哪位朋友有兴趣希望可以帮忙翻译一下每个参数的含义，有问题讨论也欢迎在这里回帖 ^_^

ab [ -A auth-username:password ] [ -c concurrency ] [ -C cookie-name=value ] [ -d ] [ -e csv-file ] [ -g gnuplot-file ] [ -h ] [ -H custom-header ] [ -i ] [ -k ] [ -n requests ] [ -p POST-file ] [ -P proxy-auth-username:password ] [ -q ] [ -s ] [ -S ] [ -t timelimit ] [ -T content-type ] [ -v verbosity] [ -V ] [ -w ] [ -x <table>-attributes ] [ -X proxy[:port] ] [ -y <tr>-attributes ] [ -z <td>-attributes ] [http://]hostname[:port]/path

-A auth-username:password

Supply BASIC Authentication credentials to the server. The username and password are separated by a single : and sent on the wire base64 encoded. The string is sent regardless of whether the server needs it (i.e., has sent an 401 authentication needed).

-c concurrency

Number of multiple requests to perform at a time. Default is one request at a time.

-C cookie-name=value

Add a Cookie: line to the request. The argument is typically in the form of a name=value pair. This field is repeatable.

-d

Do not display the “percentage served within XX [ms] table”. (legacy support).

-e csv-file

Write a Comma separated value (CSV) file which contains for each percentage (from 1% to 100%) the time (in milliseconds) it took to serve that percentage of the requests. This is usually more useful than the ‘gnuplot’ file; as the results are already ‘binned’.

-g gnuplot-file

Write all measured values out as a ‘gnuplot’ or TSV (Tab separate values) file. This file can easily be imported into packages like Gnuplot, IDL, Mathematica, Igor or even Excel. The labels are on the first line of the file.

-h

Display usage information.

-H custom-header

Append extra headers to the request. The argument is typically in the form of a valid header line, containing a colon-separated field-value pair (i.e., "Accept-Encoding: zip/zop;8bit").

-i

Do HEAD requests instead of GET.

-k

Enable the HTTP KeepAlive feature, i.e., perform multiple requests within one HTTP session. Default is no KeepAlive.

-n requests

Number of requests to perform for the benchmarking session. The default is to just perform a single request which usually leads to non-representative benchmarking results.

-p POST-file

File containing data to POST.

-P proxy-auth-username:password

Supply BASIC Authentication credentials to a proxy en-route. The username and password are separated by a single : and sent on the wire base64 encoded. The string is sent regardless of whether the proxy needs it (i.e., has sent an 407 proxy authentication needed).

-q

When processing more than 150 requests, ab outputs a progress count on stderr every 10% or 100 requests or so. The-q flag will suppress these messages.

-s

When compiled in (ab -h will show you) use the SSL protected https rather than the http protocol. This feature is experimental and very rudimentary. You probably do not want to use it.

-S

Do not display the median and standard deviation values, nor display the warning/error messages when the average and median are more than one or two times the standard deviation apart. And default to the min/avg/max values. (legacy support).

-t timelimit

Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally. Use this to benchmark the server within a fixed total amount of time. Per default there is no timelimit.

-T content-type

Content-type header to use for POST data.

-v verbosity

Set verbosity level - 4 and above prints information on headers, 3 and above prints response codes (404, 200, etc.), 2 and above prints warnings and info.

-V

Display version number and exit.

-w

Print out results in HTML tables. Default table is two columns wide, with a white background.

-x <table>-attributes

String to use as attributes for <table>. Attributes are inserted <table here >.

-X proxy[:port]

Use a proxy server for the requests.

-y <tr>-attributes

String to use as attributes for <tr>.

-z <td>-attributes

String to use as attributes for <td>.

相关链接

ab 是 Apache 的一个安装组件，所以需要下载 Apache 安装后才能使用，可以访问 Apache 的项目主页来下载http://httpd.apache.org/download.cgi

ab 的更多信息可以参加 Apache 主页上的描述

合理的使用客户端编程和远程过程调用。
客户端的编程主要都是基于JavaScript的。而JavaScript是一种解释型 的编程语言，它的运行效率相对于Java等都要稍逊一筹。同时JavaScript又是运行在浏览器这样一个严格受限的环境当中。因此开发人员对于哪些逻 辑可以在客户端执行应该有一个清醒的认识。
在实际的应用中究竟应该怎样使用客户端编程，这依赖于开发人员的经验判断。这里很多问题是只可意会的。 由于篇幅有限，在这里我们大致归纳出下面这几个注意事项：

尽可能避免频繁的使用远程过程调用，例如避免在循环体中使用远程过程调用。
如果可能的话尽可能使用AJAX方式的远程过程调用（异步方式的远程过程调用）。
避免将重量级的数据操作放置在客户端。例如：大批量的数据复制操作、需要通过大量的数据遍历完成的计算等。
改进对DOM对象的操作方式。
客户端的编程中，对DOM对象的操作往往是最容易占用CPU时间的。而对于DOM对象的操作，不同的编程方法之间 的性能差异又往往是非常大的。
以下是三段运行结果完全相同的代码，它们的作用是在网页中创建一个10×1000的表格。然而它们的运行速度却有着 天壤之别。
/* 测试代码1 – 耗时: 41秒*/

var table = document.createElement(“TABLE”);
document.body.appendChild(table);
for(var i = 0; i < 1000; i++){
var row = table.insertRow(-1);
for(var j = 0; j < 10; j++){
var cell = objRow.insertCell(-1);
cell.innerText = “( ” + i + ” , ” + j + ” )”;
}
}

/* 测试代码2 – 耗时: 7.6秒 */

var table = document.getElementById(“TABLE”);
document.body.appendChild(table);
var tbody = document.createElement(“TBODY”);
table.appendChild(tbody);
for(var i = 0; i < 1000; i++){
var row = document.createElement(“TR”);
tbody.appendChild(row);
for(var j = 0; j < 10; j++){
var cell = document.createElement(“TD”);
row.appendChild(cell);
cell.innerText = “( ” + i + ” , ” + j + ” )”;
}
}

/* 测试代码3 – 耗时: 1.26秒 */

var tbody = document.createElement(“TBODY”);

for(var i = 0; i < 1000; i++){
var row = document.createElement(“TR”);
for(var j = 0; j < 10; j++){
var cell = document.createElement(“TD”);
cell.innerText = “( ” + i + ” , ” + j + ” )”;
row.appendChild(cell);
}
tbody.appendChild(row);
}
var table = document.getElementById(“TABLE”);
table.appendChild(tbody);
document.body.appendChild(table);

这里的“测试代码1”和“测试代码2”之间的差别在于在创建表格单元时使用了不同的API方法。而“测试代码2”和“测试代码3” 之间的差别在于处理顺序的略微不同。
“测试代码1”和“测试代码2”之间如此大的性能差别我们无从分析，目前所知的是insertRow和 insertCell是DHTML中表格特有的 API，createElement和appendChild是W3C DOM的原生API。而前者应该是对后者的封装。不过，我们并不能因此而得出结论认为DOM的原生API总是优于对象特有的API。建议大家在需要频繁调 用某一API时，对其性能表现做一些基本的测试。
“测试代码2”和“测试代码3”之间的性能差异主要来自于他们的构建顺序不同。“测试代码2”的 做法是首先创建最外层的<TABLE>对象，然后再在循环中依次创建<TR>和<TD>。而“测试代码3”的做法是 首先在内存中由内到外的构建好整个表格，最后再将它添加到网页中。这样做的目的是尽可能的减少浏览器重新计算页面布局的次数。每当我们将一个对象添加到网 页中时，浏览器都会尝试对页面中的控件的布局进行重新计算。所以，如果我们能够首先在内存中将整个要构造的对象全部创建好，然后再一次性的添加到网页中。 那么，浏览器将只会做一次布局的重计算。总结为一句话那就是越晚执行appendChild越好。有时为了提高运行效率，我们甚至可以考虑先使用 removeChild将已存在的控件从页面中移除，然后构造完成后再重新将其放置回页面当中。

提高字符串累加的速度
在使用 AJAX提交信息时，我可能常常需要拼装一些比较大的字符串通过XmlHttp来完成POST提交。尽管提交这样大的信息的做法看起来并不优雅，但有时我 们可能不得不面对这样的需求。那么JavaScript中对字符串的累加速度如何呢？我们先来做下面的这个实验。累加一个长度为30000的字符串。
/* 测试代码1 – 耗时: 14.325秒 */

var str = “”;
for (var i = 0; i < 50000; i++) {
str += “xxxxxx”;
}

这段代码耗时14.325秒，结果并不理想。现在我们将 代码改为如下的形式：

/* 测试代码2 – 耗时: 0.359秒 */

var str = “”;
for (var i = 0; i < 100; i++) {
var sub = “”;
for (var j = 0; j < 500; j++) {
sub += “xxxxxx”;
}
str += sub;
}

这 段代码耗时0.359秒！同样的结果，我们做的只是首先拼装一些较小的字符串然后再组装成更大的字符串。这种做法可以有效的在字符串拼装的后期减小内存复 制的数据量。知道了这一原理之后我们还可以把上面的代码进一步拆散以后进行测试。下面的代码仅耗时0.140秒。
/* 测试代码3 – 耗时: 0.140秒 */

var str = “”;

for (var i1 = 0; i1 < 5; i1++) {
var str1 = “”;
for (var i2 = 0; i2 < 10; i2++) {
var str2 = “”;
for (var i3 = 0; i3 < 10; i3++) {
var str3 = “”;
for (var i4 = 0; i4 < 10; i4++) {
var str4 = “”;
for (var i5 = 0; i5 < 10; i5++) {
str4 += “xxxxxx”;
}
str3 += str4;
}
str2 += str3;
}
str1 += str2;
}
str += str1;
}

不过，上面这种做法也许并不是最好的！如果我们需要提交的信息 是XML格式的（其实绝大多数情况下，我们都可以设法将要提交的信息组装成XML格式），我们还能找到更高效更优雅的方法—利用DOM对象为我们组装字符 串。下面这段代买组装一个长度为950015的字符串仅须耗时0.890秒。

/* 利用DOM对象组装信息 – 耗时: 0.890秒 */

var xmlDoc;

if (browserType == BROWSER_IE) {
xmlDoc = new ActiveXObject(“Msxml.DOMDocument”);
}
else {
xmlDoc = document.createElement(“DOM”);
}
var root = xmlDoc.createElement(“root”);
for (var i = 0; i < 50000; i++) {
var node = xmlDoc.createElement(“data”);
if (browserType == BROWSER_IE) {
node.text = “xxxxxx”;
}
else {
node.innerText = “xxxxxx”;
}
root.appendChild(node);
}
xmlDoc.appendChild(root);
var str;
if (browserType == BROWSER_IE) {
str = xmlDoc.xml;
}
else {
str = xmlDoc.innerHTML;
}

避免DOM对象的内存泄漏。
关于IE中DOM对象的内存泄露是一个常常被开发人员忽略的问题。然而它带来的后果却是非常严重 的！它会导致IE的内存占用量持续上升，并且浏览器的整体运行速度明显下降。对于一些泄露比较严重的网页，甚至只要刷新几次，运行速度就会降低一倍。
比 较常见的内存泄漏的模型有“循环引用模型”、“闭包函数模型”和“DOM插入顺序模型”,对于前两种泄漏模型，我们都可以通过在网页析构时解除引用的方式 来避免。而对于“DOM插入顺序模型”则需要通过改变一些惯有的编程习惯的方式来避免。
有关内存泄漏的模型的更多介绍可以通过Google很快的 查到，本文不做过多的阐述。不过，这里我向您推荐一个可用于查找和分析网页内存泄露的小工具— Drip，目前的较新版本是0.5.

复杂页面的分段装载和初始化
对系统当中某些确实比较复杂而又不便使用IFrame的界面，我们可以对其实施分段装载。例如对于多页标签的界 面，我们可以首先下载和初始化多页标签的默认页，然后利用AJAH（asynchronous JavaScript and HTML）技术来异步的装载其他标签页中的内容。这样就能保证界面可以在第一时间首先展现给用户。把整个复杂界面的装载过程分散到用户的操作过程当中。

用GZIP压缩网络流量。
除了上面提到的这些代码级的改良之外，我们还可以利用GZIP来有效的降低网络流量。目前常见的主流浏览器已经全 部支持GZIP算法，我们往往只需要编写少量的代码就可以支持GZIP了。例如在J2EE中我们可以在Filter中通过下面的代码来判断客户端浏览器是 否支持GZIP算法，然后根据需要利用 java.util.zip.GZIPOutputStream来实现GZIP的输出。

/* 判断浏览器对GZIP支持方式的代码 */
private static String getGZIPEncoding(HttpServletRequest request) {
String acceptEncoding = request.getHeader(“Accept-Encoding”);
if (acceptEncoding == null) return null;
acceptEncoding = acceptEncoding.toLowerCase();
if (acceptEncoding.indexOf(“x-gzip”) >= 0) return “x-gzip”;
if (acceptEncoding.indexOf(“gzip”) >= 0) return “gzip”;
return null;
}
一般而言，GZIP对于HTML、JSP的压缩比可以达到80%左右，而它造成的服务端和客户端的性能损耗几乎是可以忽略 的。结合其他因素，支持GZIP 的网站有可能为我们节约50%的网络流量。因此GZIP的使用可以为那些网络环境不是特别好的应用带来显著的性能提升。使用Http的监视工具 Fiddler可以方便的检测出网页在使用GZIP前后的通讯数据量。Fiddler的下载地址是 /fiddler/
关于Web应用的性能优化 其实是一个非常大的话题。本文由于篇幅有限，只能涉及其中的几个细节，并且也无法将这些细节的优化方式全面的展现给大家。期望本文能够引起大家对Web应 用尤其是客户端性能优化的充分重视。毕竟服务端编程技巧已为大家熟知多年，在服务端挖掘性能的潜力已经不大了。而在客户端的方法改进往往能够得到令人惊奇 的性能提升。

}
</script>
所以我们可以直接这样编写：
if (document.all){
window.attachEvent(’onload’, 调用函数名)//对于IE
}
else{
window.addEventListener(’load’,调用函数 名,false);//对于FireFox
}

用途：
本 函数可以用于一些广告和统计的js文件异步加载，避免了因加载js文件而造成的网页显示速度慢的问题。

将此函数修改如下后 可以动 态加载css文件

但 是这样当加载的js文件含有document.write语句时,在IE下没有反应，但在Mozilla Firefox 下就会让你原来的网页消失，只显示document.write出来的内容.对此问题一网友给出了一种比较好的解决办法,当然是重写 document.write方法.下面网友原做内容:

1. 需跨域调取的url假设为：
2. http://www.1ong1.com/bbtest/json.php
3. 返回：
4. ({ ”TotalCount”:1,”Rows”:[ { "vusername":"zycbob","CompanyName":"BV Ltd,.","UcofcName":"集团公司","CamEndTime":"2010-02-05 16:40:00","ServerID":"1","ServerName":"开天辟地","ServerType":"169"} ]})
5. <?php
6. $jsondata = ’{ ”TotalCount”:1,”Rows”:[ { "vusername":"zycbob","CompanyName":"BV Ltd,.","UcofcName":"集团公司","CamEndTime":"2010-02-05 16:40:00","ServerID":"1","ServerName":"开天辟地","ServerType":"169"} ]}’;
7. echo $_GET['callback'].’(‘.$jsondata.’)';

1. <!DOCTYPE html PUBLIC ”-//W3C//DTD XHTML 1.0 Transitional//EN” ”http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
2. <html xmlns=”http://www.w3.org/1999/xhtml”>
3. <head>
4. <meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />
5. <title>jquery以Jsonp方式跨域获取json配合php示例</title>
6. <script type=”text/javascript” src=”http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js”></script>
7. <script type=”text/javascript”>
8. $.getJSON(“http://www.1ong1.com/bbtest/json.php?callback=?”,
9. function(data){
10. alert(data.Rows[0].ServerName); // 运行结果“开天辟地”
11. });
12. </script>
13. </head>
14. <body>
15. test only
16. </body>
17. </html>

解决浏览器差异： FF:onload ； IE:onreadystatechange。

如果使用了jQuery的话。 跨域问题就更容易解决了。

$.getJSON(
”a.php?callback=?”,
function(data){
alert(“CallBack Data: ” + data );
}
);

在此必须要用 callback=? 进行跨域调用，jQuery会返回一个JSONP的返回值代替‘？’，实际上传递给后台脚本的应该是类似‘&callback=jsonp12126279’。所以需要在后台脚本中截获 callback的参数，然后加在原先的JSON前。（可以理解成是一次验证过程）。

同样可以采用这种方式异步加载图片：
var A = document.createElement(“img”) , B = document.getElementsByTagName(“body”)[0];
A.src = “http://img.openv.tv/t/UserFiles/Image/20090612/20090612_1709056640541058.jpg”;
A.onload = A.onreadystatechange = function(){
alert(this.readyState);
alert(“A”);
}
B.appendChild(A);

<!--[if IE 6]><script type="text/javascript">
try { document.execCommand('BackgroundImageCache', false, true); } catch(e) {}
</script><![endif]-->

注：这个BUG以前就已经发现了，这里只是再次提出来。

与飞速的CPU和内存相比，磁盘和网络的IO慢如蜗牛，这是问题的根源。如果没有大规模廉价而又足够快的存储方案出现的话，这个问题还将继续下去。 我们只能期待这一革命性的技术出现来从根本上解决这一问题吧！

那对于现在的我们该怎么办呢？大家的想法可能都是一样的，一是加快IO速度，二是避免不必要的IO。豆瓣曾经通过购买更高性能的硬盘来解决这个问 题，如果想要更好的效果，需要投入更多的资金来购买整套的高性能存储方案，但是这成本太高了，很多公司后来都会放弃。于是大部分公司都会极力采用后者，就 是避免不必要的IO，缓存就是用来做这样的事的。

将低速介质上的数据放到高速介质上，访问者先访问高速介质，在找不到需要数据时才访问低速介质，以此来提升访问数据的速度，这样的技术就是缓存了。 设在一段时间内有m次没有命中缓存，n次命中，而访问一次缓存的时间是t1， 访问慢速介质的时间是t2，那么为了是缓存有效就得满足不等式： m * (t1 + t2) + n * t1 < (m + n) * t2， 于是有 m / n < t2 / t1 -1 。由此可见，在介质的速度比一定的情况下，命中比率要高于一定的值，缓存才有效果。提高命中比率，就是要把那些最常用的数据放到缓存里。另一方面，缓存里 数据如果被修改了，就要同步到低速存储介质中，同样的，如果低速存储介质的数据被修改了，也要同步到缓存里。如果加上同步的开销，就需要更高的命中率。提 高命中率和保证数据的同步，是使用缓存的两个艰巨的任务。

豆瓣网使用memcache，还使用专门的nigix服务器来提供图片的服务，其实也是cache。linkedin则使用了数十台大内存的服务器 作为缓存服务器，运行着用c++写的专门的缓存程序。可见这些网站在使用缓存方面都是不遗余力呀。如果能把缓存用好，那么就把一大半的IO问题解决掉了。

IO往往会成为程序的瓶颈，因此，程序员应当时刻的注意，你写的代码是否在进行IO操作，是否可以减少IO操作，等等。

本文来自：http://www.sulong.info/archives/232