Debian+ISPCP 环境下 eAccelerator效果测试

硬件:CPU 2.5 / 1G内存 / VMEsxi虚拟环境 :roll:

软件:Debian Lenny 5.0 + ISPCP 1.0.2 stable

工具:apache 里的AB

声名:这是在一个非标准环境下的测试,测试结果不具有普遍可比性,仅供参考

eAccelerator的对比测试结果

测试应用网站:3个

  • A 一个简单的模拟PHPINFO类页面,提取系统信息,显示,单文件程序
  • B 一个自己开发的CMS系统
  • C Wordpress BLOG,加载了一些常见插件

测试方式:使用 ab -t 60 -c 5 参数测试,每阶段2次测试取评价值,分2个阶段

  • P1 没有安装eAcceleratr
  • P2  安装了eAccelerator
AB 测试结果表 (请求处理/秒)
       P1 P2  
Req/S CPU%  Req/S  CPU%
A INFO   73 40   75  20
B CMS   8.72  100  16.77  95
C WordPress  1.22  100  1.76 100 

分析:

依照CMS应用为典型WEB应用需要环境,可以看到eAccelerator提高效率高达100%,综合环境变化情况,至少我们可以期望有50%的提高,从A和B成绩对比来看,过于简单的脚本和过于复杂的脚本环境下,eAccelerator表现就不是很突出,当然,这也木桶原理的表现。

从A/B的对比成绩,我们还可以看出,eAccelerator因为可以缓存脚本编译结果,由此带来的CPU占用率的降低是很明显的。

eAccelerator环境下的压力测试:

测试应用网站:

  • A 一个简单的模拟PHPINFO类页面,提取系统信息,显示,单文件程序
  • B 一个自己开发的CMS系统
  • C Wordpress BLOG,加载了一些常见插件
  • D 一个最简单的静态HTML文件,仅显示几个字符,主要测试APACHE的静态响应能力

测试方法:使用 ab -t 30 -c X 参数测试,每阶段2次测试取平均值

X分别取 1 / 2 /5 /15 /60 分段测试,根据具体应用,某些分段没有测试意义,跳过了

A INFO 页面压力分段测试成绩

并发线程数 请求处理/秒 平均页面读取时间 CPU
5 75 65  
10 85 116 20
15 83.92 178  
20 81.11 546  
50 72 692  
60 84.23 712 50

B CMS页面压力分段测试成绩

并发线程数 请求处理/秒 平均页面读取时间 CPU
1 13.84 72 75
2 14.4 138 91
5 16.77 298 95
10 16.22 98
60 11.89 5045 100

C WordPress页面压力分段测试成绩

并发线程数 请求处理/秒 平均页面读取时间 CPU
1 1.93 517 97
5 1.76 2848 100
10 1.82 5505 100
60 1.81 5520 100

D 简单静态HTML页面

并发线程数 请求处理/秒 平均页面读取时间 CPU
1 524 1.5 20
5 689 7  35
10 694 14 38
50 713 70 43 

分析:

  1. 此测试环境典型WEB应用的最佳并发连接支持大约在每秒十个左右(低不低?)
  2. WordPress确实是个巨无霸
  3. 针对A的测试结果,我们可以认为,系统响应瓶颈应该在IO部分
  4. 针对 B / C 的测试结果,我们可以认为系统响应的瓶颈在CPU
  5. 本来想进一步提高静态页面测试压力的,可是ab在我的Windows Server环境下总是有问题
    先是报这个错,后来换个AB版本解决了
    apr_pollset_create failed: Invalid argument (22)      
    又开始报这个错。。。郁闷
    apr_socket_recv: 您的主机中的软件放弃了一个已建立的连接。   (730053)

 BTW:我一开始的测试结果很低,后来发现问题出在我的测试客户端需要通过一条RouterOS路由器访问服务器,而且还要NAT转换一下,严重影响了测试结果,我把当时使用RouterOS路由时的测试结果也贴上来吧,仅供娱乐:

 娱乐测试结果表 (请求处理/秒)
请求处理/秒 P1 P2
A INFO 10.22 10.39
B WordPress 1.35 1.57
C CMS 3.10 3.43

(61)

发表评论

电子邮件地址不会被公开。