博客

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

发表评论