静怡家园

1 Apache附带的工具ab

ab的全称是ApacheBench，是Apache附带的一个小工具，专门用于HTTP Server的benchmark testing，可以同时模拟多个并发请求。

在这个例子的一开始，我执行了这样一个命令ab -n 10 -c 10http://www.google.com/。这个命令的意思是启动ab，向www.google.com发送10个请求(-n 10) ，并每次发送10个请求(-c 10) ——也就是说一次都发过去了。

apache ab做重复压力测试不错，但是每次只能测试一个链接

D:\apahce\bin>ab.exe -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 2006 The Apache Software Foundation, http://www.apache.org/

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

Server Software: gws
Server Hostname: www.google.com
Server Port: 80

Document Path: /
Document Length: 4941 bytes

Concurrency Level: 10
Time taken for tests: 5.218750 seconds//**整个测试持续的时间**
Complete requests: 10//**完成的请求数量**
Failed requests: 9//**失败的请求数量**
(Connect: 0, Length: 9, Exceptions: 0)
Write errors: 0
Total transferred: 52730 bytes**整个场景中的网络传输量**
HTML transferred: 49540 bytes**整个场景中的HTML内容传输量**
Requests per second: 1.92 [#/sec] (mean) **大家最关心的指标之一，相当于LR中的每秒事务数，后面括号中的mean表示这是一个平均值**
Time per request: 5218.750 [ms] (mean) *大家最关心的指标之二，相当于LR中的平均事务响应时间，后面括号中的mean表示这是一个平均值**
Time per request: 521.875 [ms] (mean, across all concurrent requests)
Transfer rate: 9.77 [Kbytes/sec] received*平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题**

Connection Times (ms)
min mean[+/-sd] median max
Connect: 187 488 257.6 437 921
Processing: 312 1673 1204.4 1547 3985
Waiting: 296 1668 1206.3 1546 3984
Total: 593 2162 1432.6 1890 4906
**下面的内容为整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于**毫秒，60％的用户响应时间小于**毫秒，最大的响应时间小于 **毫秒**
Percentage of the requests served within a certain time (ms)
50% 1890
66% 2406
75% 3093
80% 3984
90% 4906
95% 4906
98% 4906
99% 4906
100% 4906 (longest request)

实际测试

Server Software: Apache/2.2.3
Server Hostname: www.netnov.cn
Server Port: 80

Document Path: /
Document Length: 18958 bytes

Concurrency Level: 10
Time taken for tests: 8.949 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 1912100 bytes
HTML transferred: 1895800 bytes
Requests per second: 11.17 [#/sec] (mean)
Time per request: 894.906 [ms] (mean)
Time per request: 89.491 [ms] (mean, across all concurrent requests)
Transfer rate: 208.66 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 78 87 8.9 94 109
Processing: 219 752 122.2 781 875
Waiting: 219 510 179.9 515 843
Total: 312 839 121.3 859 953

Percentage of the requests served within a certain time (ms)
50% 859
66% 859
75% 875
80% 890
90% 921
95% 937
98% 953
99% 953
100% 953 (longest request)

-----------------------------------------------------------------------------


格式： ./ab [options] [http://]hostname[:port]/path
参数：
-n requests Number of requests to perform
//在测试会话中所执行的请求个数。默认时，仅执行一个请求
-c concurrency Number of multiple requests to make
//一次产生的请求个数。默认是一次一个。
-t timelimit Seconds to max. wait for responses
//测试所进行的最大秒数。其内部隐含值是-n 50000。它可以使对服务器的测试限制在一个固定的总时间以内。默认时，没有时间限制。
-p postfile File containing data to POST
//包含了需要POST的数据的文件.
-T content-type Content-type header for POSTing
//POST数据所使用的Content-type头信息。
-v verbosity How much troubleshooting info to print
//设置显示信息的详细程度 - 4或更大值会显示头信息， 3或更大值可以显示响应代码(404, 200等), 2或更大值可以显示警告和其他信息。 -V 显示版本号并退出。
-w Print out results in HTML tables
//以HTML表的格式输出结果。默认时，它是白色背景的两列宽度的一张表。
-i Use HEAD instead of GET
// 执行HEAD请求，而不是GET。
-x attributes String to insert as table attributes
//
-y attributes String to insert as tr attributes
//
-z attributes String to insert as td or th attributes
//
-C attribute Add cookie, eg. 'Apache=1234. (repeatable)
//-C cookie-name=value 对请求附加一个Cookie:行。其典型形式是name=value的一个参数对。此参数可以重复。
-H attribute Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
//-P proxy-auth-username:password 对一个中转代理提供BASIC认证信任。用户名和密码由一个:隔开，并以base64编码形式发送。无论服务器是否需要(即, 是否发送了401认证需求代码)，此字符串都会被发送。
-X proxy:port Proxyserver and port number to use
-V Print version number and exit
-k Use HTTP KeepAlive feature
-d Do not show percentiles served table.
-S Do not show confidence estimators and warnings.
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-h Display usage information (this message)

2 webbench

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 -c 100 -t 10 http://192.168.200.100/info.php

参数说明：-c表示并发数，-t表示持续时间(秒)

root@ubuntu-desktop:/etc/nginx/sites-available# webbench -c 100 -t 10 http://192.168.200.100/info.php
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://192.168.200.100/info.php
100 clients, running 10 sec.

Speed=19032 pages/min, 18074373 bytes/sec.
Requests: 3172 susceed, 0 failed.

3 Siege

apache ab做重复压力测试不错，但是每次只能测试一个链接

如何测试一组链接（比如从日志中导出的1个小时的日志，做真实压力测试），后来找到了这个：
Siege是一个压力测试和评测工具，设计用于WEB开发这评估应用在压力下的承受能力：可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。

下载/安装
Siege时一个开放源代码项目：http://www.joedog.org/siege/

下载：
wget ftp://sid.joedog.org/pub/siege/siege-latest.tar.gz

安装：
#./configure ; make
#make install

#siege -help （如果有help出现，则已经安装成功）

siege包含了一组压力测试工具：
SIEGE (1) Siege是一个HTTP压力测试和评测工具.
使用样例：
任务列表：www.chedong.com.url文件
http://www.chedong.com/tech/
http://www.chedong.com/tech/acdsee.html
http://www.chedong.com/tech/ant.html
http://www.chedong.com/tech/apache_install.html
http://www.chedong.com/tech/awstats.html
http://www.chedong.com/tech/cache.html
http://www.chedong.com/tech/click.html
http://www.chedong.com/tech/cms.html
http://www.chedong.com/tech/compress.html
http://www.chedong.com/tech/cvs_card.html
http://www.chedong.com/tech/default.html
http://www.chedong.com/tech/dev.html
http://www.chedong.com/tech/gnu.html
….
siege -c 20 -r 2 -f www.chedong.com.url
参数说明：
-c 20 并发20个用户
-r 2 重复循环2次
-f www.chedong.com.url 任务列表：URL列表

输出样例：

** Siege 2.59
** Preparing 20 concurrent users for battle. 这次“战斗”准备了20个并发用户
The server is now under siege.. done. 服务在“围攻”测试中：
Transactions: 40 hits 完成40次处理
Availability: 100.00 % 成功率
Elapsed time: 7.67 secs 总共用时
Data transferred: 877340 bytes 共数据传输：877340字节
Response time: 1.65 secs 相应用时1.65秒：显示网络连接的速度
Transaction rate: 5.22 trans/sec 平均每秒完成5.22次处理：表示服务器后台处理的速度
Throughput: 114385.92 bytes/sec 平均每秒传送数据：114385.92字节
Concurrency: 8.59 最高并发数 8.59
Successful transactions: 40 成功处理次数
Failed transactions: 0 失败处理次数


辅助工具：
增量压力测试：
为了方便增量压力测试，siege还包含了一些辅助工具：
bombardment (1)
是一个辅助工具：用于按照增量用户压力测试：
使用样例：
bombardment urlfile.txt 5 3 4 1
初始化URL列表：urlfile.txt
初始化为：5个用户
每次增加：3个用户
运行：4次
每个客户端之间的延迟为：1秒

输出成CSV格式：
siege2csv.pl (1)
siege2csv.pl将bombardment的输出变成CSV格式：
Time Data Transferred Response Time Transaction Rate Throughput Concurrency Code 200 (note that this is horribly broken.)
242 60.22 603064 0.02 4.02 10014.35 0.08
605 59.98 1507660 0.01 10.09 25136.05 0.12
938 59.98 2337496 0.02 15.64 38971.26 0.26
1157 60 2883244 0.04 19.28 48054.07 0.78

4 http_load

下载地址：http://www.acme.com/software/http_load/http_load-12mar2006.tar.gz

程序非常小，解压后也不到100K 居家旅行 携带方便 呵呵

http_load以并行复用的方式运行，用以测试web服务器的吞吐量与负载。但是它不同于大多数压力测试工具，它可以以一个单一的进程运行，一般不会把客户机搞死。可以可以测试HTTPS类的网站请求。

命令格式：http_load -p 并发访问进程数 -s 访问时间 需要访问的URL文件
例如：
引用
http_load -p 30 -s 60 urllist.txt

准 备URL文件：tst.list，文件格式是每行一个URL，URL最好超过50－100个测试效果比较好，另外，测试结果中主要的指标是 fetches/sec 这个选项，即服务器每秒能够响应的查询次数，用这个指标来衡量性能。似乎比 apache的ab准确率要高一些，也更有说服力一些。

官方的例子：
引用

% ./http_load -rate 10 -seconds 60 urllist.txt
49 fetches, 4 max parallel, 289884 bytes, in 10.0148 seconds
5916 mean bytes/connection
4.89274 fetches/sec, 28945.5 bytes/sec
msecs/connect: 28.8932 mean, 44.243 max, 24.488 min
msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min

4.89274 fetches/sec 这个值得就是说服务器每秒能够响应的查询次数为4.8左右
这个值得是根据 49 fetches / 10.0148 seconds 秒计算出来的

5 Web Application Stress 【附下载】
http://www.microsoft.com/downloads/details.aspx?FamilyID=e2c0585a-062a-439e-a67d-75a89aa36495&displaylang=en

说明：

1. 在“settings”的功能设置中，一个是Stress level (threads)这里是指定程序在后台用多少线程进行请求，也就是相当于模拟多少个客户机的连接，更加形象的就是说设置多少轰炸的线程数。一般填写 500～1000，因为这个线程数是根据本机的承受力来设置的，如果你对自己的机器配置有足够信心的话，那么设置的越高，轰炸的效果越好。

2.在“Test Run Time”中来指定一次压力测试需要持续的时间，分为天、小时、分、秒几个单位级别，你根据实际情况来设置吧！

使用：

在工具中点右键，选择Add命令，增加了一个新的测试项目：New script，对它进行设置，在主选项中的server中填写要测试的服务器的IP地址[192.168.200.100]。在下方选择测试的Web连接方式，这里的方式Verb选择 get，path选择要测试的Web页面路径[/info.php]，

在“Settings”的功能设置中将Stress level (threads)线程数设置为1000。完毕后，点工具中的灰色三角按钮即可进行测试（如图4）。测试完毕，等待朋友把任务管理器以及连接查看的截图发过来！

攻 击开始后，朋友从任务管理器中可以看到CPU使用率已经达到100%，损耗率达到最大。在CMD窗口中使用命令netstat -an,可以看到我的IP地址在朋友服务器上的80端口进行了非常多的连接。而且它的Web网站已经打不开了，提示过多用户连接，达到了跟 D.O.S攻击一样的目的。

数据分析：
选择“View”菜单下的“Reports”命令，或单击工具栏上的 按钮，打开报告窗口，在左侧列表中展开相应的报告。

检查Socket Errors部分是否有任何的socket有关的错误（值不为0）。

Socket Errors
--------------------------------------------------------------------------------
Connect: 406
Send: 0
Recv: 306
Timeouts: 0

这里列出每种socket错误的解释：Connect——客户端不能与服务器取得连接的次数。如果这个值偏高，检查在客户端与服务器之间产生的任何潜在的错误。从每个客户端Ping服务器或telnet服务器的端口80验证你得到正确的回应；Send——客户端不能正确发送数据到服务器的次数。如果这个值偏高，检查服务器是否正确地工作着。在客户端打开一个浏览器然后手工点击站点页面验证站点正确地工作着；Recv——客户端不能正确从服务器接收数据的次数。如果这个值偏高，执行和Send错误相同的操作，还要检查一下如果你减低负载系数，错误是否跟着减少；Timeouts——超时的线程的数目，而且随后就关闭了。如果这个值偏高，在客户端打开一个浏览器，然后手工点击站点页面验证是否即使只有一个用户你的程序也会很慢。再做一个不同负载系数的压力测试，看看程序的潜在特征。

Result Codes
Code Description Count
================================================================================
200 OK 11058
NA HTTP result code not given 306
如果“socket”错误很低或为0，在左侧的报告列表中找到“Result Codes”部分。检查一下是否所有结果代码都是200，200表示所有请求都被服务器成功地返回。如果找到大于或等于400的结果，单击报告列表中的 “Page Data”节点，展开所有项目，查看每个脚本项在右边窗口页面数据的报告，找出出现错误的项目。

今天查看系统日志发现大量的nf_conntrack: table full, dropping packet. 错误
cat /var/log/messages | more
Jun  7 09:52:05 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:05 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:05 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:05 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:05 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:05 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:05 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:05 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:10 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:10 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:10 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:10 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:10 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:10 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:10 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:10 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:10 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:10 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:15 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:15 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:15 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:15 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:15 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:15 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:15 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:15 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:15 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:15 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:23 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:23 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:23 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:23 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:23 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:23 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:23 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:23 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:23 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:23 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:30 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:30 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:30 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:30 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:30 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:30 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:30 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:30 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:30 localhost kernel: nf_conntrack: table full, dropping packet.
Jun  7 09:52:30 localhost kernel: nf_conntrack: table full, dropping packet.
解决办法：
vi /etc/sysctl.conf
加入：
net.nf_conntrack_max = 655350
net.netfilter.nf_conntrack_tcp_timeout_established = 1200
CENTOS 6.1或以上版本使用：
net.netfilter.nf_conntrack_max = 655350
net.netfilter.nf_conntrack_tcp_timeout_established = 1200
保存后执行 sysctl -p 使之生效，然后观察该错误是不是没有了。

第一种安装方法：
# /usr/local/php/bin/pecl install apc
然后按提示进行直至安装完成，安装完成之后修改/etc/php.ini 文件加入：
extension=apc.so

第二种安装方法：
首先要下载安装文件，打开 http://pecl.php.net/package/APC 下载最新的软件包，当前最新版3.1.9。
wget http://pecl.php.net/get/APC-3.1.9.tgz
# tar -zxvf APC-3.1.9.tgz
# cd APC-3.1.9
# /usr/bin/phpize
# ./configure –enable-apc –enable-apc-mmap –with-php-config=/usr/bin/php-config
# make
# make install

创建apc的配置文件
vi /etc/php.d/apc.ini
加入以下内容：
extension=apc.so
apc.enabled = 1
apc.cache_by_default = on
apc.shm_segments = 1
apc.shm_size = 128
apc.ttl = 7200
apc.user_ttl = 7200
apc.num_files_hint = 1024
apc.write_lock = On
apc.gc_ttl=3600
apc.ttl=0
apc.mmap_file_mask=/tmp/apc.XXXXXX

WEB服务器是APACHE的话，重启apache生效，如果是NGINX 重启php-fpm生效，注意如果你已经安装了eAccelerator或其他的加速工具了，再安装APC有冲突，常用的有APC、eAccelerator、XCache这三款，选择安装一个就可以了。

今天查看/var/log/secure日志文件，发现里面出现大量的错误，如下：
[root@localhost log]# cat /var/log/secure|more
Mar 16 00:00:01 localhost crond[11717]: pam_limits(crond:session): unknown limit item 'noproc'
Mar 16 00:00:01 localhost crond[11718]: pam_limits(crond:session): unknown limit item 'noproc'
Mar 16 00:00:01 localhost crond[11717]: pam_limits(crond:session): unknown limit item 'noproc'
Mar 16 00:00:01 localhost crond[11718]: pam_limits(crond:session): unknown limit item 'noproc'
Mar 16 00:01:01 localhost crond[11739]: pam_limits(crond:session): unknown limit item 'noproc'
Mar 16 00:01:01 localhost crond[11738]: pam_limits(crond:session): unknown limit item 'noproc'
Mar 16 00:01:01 localhost crond[11739]: pam_limits(crond:session): unknown limit item 'noproc'
Mar 16 00:01:01 localhost crond[11738]: pam_limits(crond:session): unknown limit item 'noproc'
Mar 16 00:02:01 localhost crond[11786]: pam_limits(crond:session): unknown limit item 'noproc'
Mar 16 00:02:01 localhost crond[11786]: pam_limits(crond:session): unknown limit item 'noproc'
Mar 16 00:03:01 localhost crond[11808]: pam_limits(crond:session): unknown limit item 'noproc'
Mar 16 00:03:01 localhost crond[11808]: pam_limits(crond:session): unknown limit item 'noproc'
Mar 16 00:04:01 localhost crond[11833]: pam_limits(crond:session): unknown limit item 'noproc'
几乎每分钟都有一到两个，看错误信息应该和limits.conf有关，执行 ulimit -n 看一下当前系统设置的是什么数值。
[root@localhost log]# ulimit -n
65535
打开/etc/security/limits.conf配置文件发现问题

接下来我们看看配置文件中注释是怎么写的，底部画红线的部分

* soft noproc 65535
* hard noproc 65535
应该改为
* soft nproc 65535
* hard nproc 65535
才对，至此该错误解决。有碰到和我一样错误的朋友不妨看一下limits.conf文件是否也是这样写的。

一、PHP加速器介绍

PHP加速器是一个为了提高PHP执行效率，从而缓存起PHP的操作码，这样PHP后面执行就不用解析转换了，可以直接调用PHP操作码，这样速度上就提高了不少。

Apache中使用mod_php的请求、响应执行流程：

　　1、Apache接收请求。
        2、Apache传递请求给mod_php。
        3、mod_php定位磁盘文件，并加载到内存中。
        4、mod_php编译源代码成为opcode树。
        5、mod_php执行opcode树。

PHP加速器相应的就是第四步，它的目的就是防止PHP每次请求都重复编译PHP代码，因为在高访问量的网站上，大量的编译往往没有执行速度快呢？所以这里面有个瓶颈就是PHP的重复编译既影响了速度又加载了服务器负载，为了解决此问题，PHP加速器就这样诞生了。

二、PHP加速器安装与配置

1、安装配置APC

APC全称是Alternative PHP Cache,官方翻译叫”可选PHP缓存”,它是PHP PECL中的一个扩展，好像是facebook在使用它，下面开始安装（ubuntu环境）：
#wget http://pecl.php.net/get/APC-3.0.19.tgz
#tar xvzf APC-3.0.19.tgz
#cd APC-3.0.19/APC-3.0.19
#/usr/local/php/bin/phpize
#./configure –enable-apc –enable-apc-mmap –with-php-config=/usr/local/php/bin/php-config
#make
#make install

下面我们再配置APC,因为我的PECL扩展路径改变了，所以我得移动下编译好的文件：
#mv /usr/local/php/lib/php/extensions/no-debug-non-zts-20060613/apc.so /usr/local/php/lib/php/extensions/PECL

然后我们再编辑php.ini文件进行配置，请把下面的代码加入到php.ini中即可：
extension_dir = "/usr/local/php/lib/php/extensions/PECL"
extension = apc.so
; APC
apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 64
apc.optimization = 1
apc.num_files_hint = 0
apc.ttl = 0
apc.gc_ttl = 3600
apc.cache_by_default = on

这样重启apache就会在phpinfo()信息中显示。

2、安装配置eAccelerator

eAccelerator的前身其实是truck-mmcache，因为开发truk-mmcache的人被Zend给招安了，所以开发eAccelerator的人继承了truk-mmcache的一些特性，设计出eAccelerator加速器。安装如下：
#wget http://jaist.dl.sourceforge.net/sourceforge/eaccelerator/eaccelerator-0.9.5.tar.bz2
#tar -jxf eaccelerator-0.9.5.tar.bz2
#cd eaccelerator-0.9.5
#/usr/local/php/bin/phpize
#./configure –enable-eaccelerator=shared –with-php-config=/usr/local/php/bin/php-config
#make
#sudo make install
#sudo mv /usr/local/php/lib/php/extensions/no-debug-non-zts-20060613/eaccelerator.so /usr/local/php/lib/php/extensions/PECL

将下面代码加入php.ini文件中
extension = eaccelerator.so
; eAccelerator
eaccelerator.shm_size = "16"
eaccelerator.cache_dir = "/tmp/eaccelerator"
eaccelerator.enable = "1"
eaccelerator.optimizer = "1"
eaccelerator.check_mtime = "1"
eaccelerator.debug = "0"
eaccelerator.filter = ""
eaccelerator.shm_max = "0"
eaccelerator.shm_ttl = "0"
eaccelerator.prune_period = "0"
eaccelerator.shm_only = "0"
eaccelerator.compress = "1"
eaccelerator.compress_level = "9"

创建缓存目录,重启apache

# mkdir /tmp/eaccelerator
#chmod 777 /tmp/eaccelerator
#/usr/local/apache/apachectl restart

在phpinfo()检查是否安装成功.

3、安装配置XCache

XCache作为国人自己开发的东西，做小菜鸟的我也感到骄傲，而且XCache无论在速度还是性能上都做的不错。下面就赶紧让我们品尝它吧！

#wget http://xcache.lighttpd.net/pub/Releases/1.2.2/xcache-1.2.2.tar.gz
#tar xvzf xcache-1.2.2.tar.gz
#cd xcache-1.2.2
#/usr/local/php/bin/phpize
#./configure –enable-xcache –enable-xcache-coverager –with-php-config=/usr/local/php/php-config
#make
#make install
#mv /usr/local/php/lib/php/extensions/no-debug-non-zts-20060613/xcache.so /usr/local/php/lib/php/extensions/PECL

在php.ini添加配置信息：

extension = xcache.so
; xcache
xcache.admin.user = "admin"
xcache.admin.pass = "(执行) echo ’(你的密码)’|md5sum(得出的密文)"
;
xcache.size = 24M
xcache.shm_scheme = "mmap"
xcache.count = 2
xcache.slots = 8k
xcache.ttl = 0
xcache.gc_interval = 0

xcache.var_size = 8M
xcache.var_count = 1
xcache.var_slots = 8k
xcache.var_ttl = 0
xcache.var_maxttl = 0
xcache.var_gc_interval = 300
xcache.test = Off
xcache.readonly_protection = On
xcache.mmap_path = "/tmp/xcache"
xcache.coredump_directory = ""
xcache.cacher = On
xcache.stat = On
xcache.optimizer = Off
;
xcache.coverager = On
xcache.coveragedump_directory = ""

创建缓存目录，重启apache

#mkdir /tmp/xcache
#chmod 777 /tmp/xcache
#/usr/local/apache/bin/apachectl restart

去查看phpinfo()信息吧！

三、PHP加速器测试

1、测试环境

硬件: AMD Athlon 64 X2 Dual Core Processor 4400+ @ 2.2GHz CPU, 2GB 内存. 160GB SATA 硬盘

软件: Linux Ubuntu server Gutsy 7.10, Apache 2.2.4, MySQL 5.0.45 和 PHP 5.2.3

测试指令: ab -c5 -n3000 http://example.com/ (我们使用的是Apache Benchmark (ab) 工具，并发连接为5，3000次请求)

2、测试结果

无任何加速器:

Document Path: /
Document Length: 21757 bytes
Concurrency Level: 5
Time taken for tests: 288.255212 seconds
Complete requests: 3000
Failed requests: 0
Write errors: 0
Total transferred: 66777000 bytes
HTML transferred: 65271000 bytes
Requests per second: 10.41 [#/sec] (mean)
Time per request: 480.425 [ms] (mean)
Time per request: 96.085 [ms] (mean, across all concurrent requests)
Transfer rate: 226.23 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.5 0 19
Processing: 181 479 186.0 444 1822
Waiting: 166 461 184.7 427 1708
Total: 181 479 186.0 444 1822
Percentage of the requests served within a certain time (ms)
50% 444
66% 525
75% 577
80% 619
90% 732
95% 819
98% 946
99% 1012
100% 1822 (longest request)

APC加速器:

Document Path: /
Document Length: 21757 bytes
Concurrency Level: 5
Time taken for tests: 98.530068 seconds
Complete requests: 3000
Failed requests: 0
Write errors: 0
Total transferred: 66777000 bytes
HTML transferred: 65271000 bytes
Requests per second: 30.45 [#/sec] (mean)
Time per request: 164.217 [ms] (mean)
Time per request: 32.843 [ms] (mean, across all concurrent requests)
Transfer rate: 661.84 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 2
Processing: 58 163 71.2 155 2452
Waiting: 53 158 69.6 150 2329
Total: 58 163 71.2 155 2452
Percentage of the requests served within a certain time (ms)
50% 155
66% 178
75% 193
80% 204
90% 235
95% 258
98% 285
99% 302
100% 2452 (longest request)

eAccelerator加速器:

Document Path: /
Document Length: 21757 bytes
Concurrency Level: 5
Time taken for tests: 95.983986 seconds
Complete requests: 3000
Failed requests: 0
Write errors: 0
Total transferred: 66777000 bytes
HTML transferred: 65271000 bytes
Requests per second: 31.26 [#/sec] (mean)
Time per request: 159.973 [ms] (mean)
Time per request: 31.995 [ms] (mean, across all concurrent requests)
Transfer rate: 679.39 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 3
Processing: 57 159 91.3 148 3830
Waiting: 50 152 89.8 142 3704
Total: 57 159 91.3 148 3830
Percentage of the requests served within a certain time (ms)
50% 148
66% 174
75% 193
80% 205
90% 239
95% 263
98% 289
99% 309
100% 3830 (longest request)

XCache加速器:

Document Path: /
Document Length: 21757 bytes
Concurrency Level: 5
Time taken for tests: 99.76300 seconds
Complete requests: 3000
Failed requests: 0
Write errors: 0
Total transferred: 66777000 bytes
HTML transferred: 65271000 bytes
Requests per second: 30.28 [#/sec] (mean)
Time per request: 165.127 [ms] (mean)
Time per request: 33.025 [ms] (mean, across all concurrent requests)
Transfer rate: 658.19 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 2
Processing: 59 164 83.4 155 3367
Waiting: 52 156 66.4 148 1802
Total: 59 164 83.4 155 3367
Percentage of the requests served within a certain time (ms)
50% 155
66% 178
75% 196
80% 206
90% 237
95% 263
98% 287
99% 305
100% 3367 (longest request)

3、结果摘要

请求时间(秒)	单次请求时间(毫秒)	最大内存占用(MB)	最小内存占用(MB)
None	10.41	96.08	24	24
APC	30.45	32.84	21	21
eAccelerator	31.26	31.99	23	18
XCache	30.28	33.02	29	19

四、PHP加速器比较结果总结

1、通过测试得出eAccelerator在请求时间和内存占用综合方面是最好的。

2、通过测试得出使用加速器比无加速器在请求时间快了3倍左右。

3、通过各个官方观察，XCache是更新最快的，这也说明最有发展的。

以上是总结结果，你也许会问我到底用那个加速器好呢？我只能告诉你，首先，用一定比不用好，其次每个加速器还有一些可以调优的参数，所以要根据你的系统环境而定，然后，我个人觉得你可以详细研究下eAccelerator和XCache，这两款潜力还是很大的，最后我从比较专业的测试网站搞了一张结果图：