月度归档:2016年03月

一组PHP7在Nginx与Apache下的测试数据

概述

PHP7作为迄今为止性能最强的PHP版本,希望通过一些测试来了解它在Nginx与Apache下的表现。数据仅供参考。

由于个人水平有限,对测试的理解可能有所偏差,如有错误麻烦指出。

运行环境

测试环境一共分为两台机器,机器A用作PHP运行环境,机器B作为压测机。A与B的CPU均为12 x Xeon E5 + 16GB RAM

两台机器位于同一网段。

测试工具使用ab

为了便于测试,调整了内核参数:

测试使用的软件版本为:

  • Apache 2.2
  • Nginx 1.2.7
  • PHP 7.0.4

Apache在httpd-mpm.conf中的配置为:

由于Apache+modphp7Nginx+PHP-FPM二者的工作模式差别较大,想要均衡的配置出一个均衡的测试比较环境很困难,从简单出发,考虑到Apache在上述配置下最大会fork出512个进程处理请求,将PHP-FPM最大进程数也设成512个,即:

测试方法

测试主要针对三种操作进行:输出Hello WorldRedis KV读取操作输出phpinfo()

选择Redis KV读取操作的目的主要想测试下这一常用扩展的在Apache与Nginx作为WebServer环境下的表现。

测试分为2组,分别在25并发以及512并发下进行,测试时长为1min,同时记录服务器的load情况。

关注的数据为:

  • 最小响应时间
  • 平均响应时间
  • 平均每秒请求数
  • load
  • 相关进程数

测试结果

测试从性能指标以及系统负载两个方面进行观察。

性能指标

最小响应时间

min_response_time.png

针对最小响应时间,并发数高低对最小响应时间没有显著的影响。在测试初期系统负载较低,测试数据应该表现最佳的阶段,推断二者在此阶段差距不大。

平均每秒请求数

requests_per_sec.png

针对平均每秒请求数,Nginx+PHP-FPM的组合处理能力稍低于Apache+modphp7的组合,考虑到Nginx与PHP-FPM之间有网络通信(测试中采用了tcp socket)的开销,这个结果是可以接受的。高并发下考虑系统开销较大,请求处理能力会稍有下降。

平均响应时间

mean_response_time.png

针对平均响应时间,高并发下同样由于系统开销较大的缘故,平均的请求处理响应时间升高也是符合预期的。

系统负载

从性能指标上看,Nginx+PHP-FPM的组合与Apache+modphp7的组合在表现上没有巨大的差距,但是在系统负载上,Nginx+PHP-FPM的配置在高并发的情况下远优于Apache+modphp7的组合。 在512并发时,在测试Hello world时,系统load的表现就有巨大的差距:

load_hello_world.png

同样的情况还出现在512并发之下对Redis KV操作的测试case之下:

load_redis_kv.png

即便是在低并发(25并发)下,Redis KV此类需要操作网络资源的操作,Apache+modphp7在系统负载上的表现也差于Nginx+PHP-FPM

load_redis_kv_c25.png

对于这类需要操作I/O的操作来说,Apache+modphp7的组合表现差于使用了异步I/O的Nginx与PHP-FPM的组合是符合预期的。

在测试phpinfo()输出时,虽然二者在load上的区别不大,但是Nginx+PHP-FPM的组合在进程数这一指标上完全占优

processes_count_phpinfo.png

考虑到Nginx+PHP-FPM的组合无需fork出新的子进程处理新到的客户端请求,以及phpinfo()的执行时间较长这两个因素,同时fork子进程等操作属于消耗系统资源较大的操作,这个现象是符合预期的。

总结

使用php7时,在性能上Apache+modphp7的组合与Nginx+PHP-FPM的组合相差无几,但对于系统负载上来说,Nginx+PHP-FPM组合综合表现优于Apache+modephp7的组合,可以推断Nginx+PHP-FPM的组合对于构建高并发的服务更有优势。

综合考虑,Nginx+PHP-FPM表现较优。

TODO

  • 尝试阅读ab源码,了解其测试原理
  • 比对fpm在动静模式之间的区别

一组Logstash与elasticsearch的压测数据

概述

组内的日志系统基于ELK搭建,本文中的数据在生产环境中进行测试得到,仅供参考。

系统构成

系统可以简要的分为:

  • 日志接收机
  • 日志数据队列
  • 日志数据处理机
  • ES集群

日志接收机上通过一个 Logstash 进程 parse 日志数据,将 parse 后的结构写入由 Redis List 实现的日志数据队列中,之后在ES集群前,再使用一个日志处理机 Logstash 进程从 Redis 中 pop 出数据写入ES集群中。

使用 Redis List 的原因是在于当 parse 能力大于ES集群的处理能力时,缓存数据。

运行环境

日志接收机为CPU为4 * Xeon E5强IO型机器,Redis List 与向ES集群写入的 Logstash 位于同一机器上,即日志数据处理机,CPU为12 * Xeon E5。

处理日志为Nginx access日志,记录了如时间、域名、访问IP、URL、HTTP Method、响应时间、返回体长度等,约10+字段。

参数配置

日志接收机上的 Logstash 配置成了10个线程,output 中的 redis 的参数配置为:

日志数据处理机上的 input 对已配置为:

而 output 配置为:

测试方法

测试分为测试 Logstash 分析日志能力,以及ES集群写入能力。

Logstash 的分析能力通过每秒取样 Redis List 中的新增队列长度获得(日志接收机上的 Logstash 生产)。

ES集群的写入能力通过每秒取样 Redis List 中减少的队列长度获得(日志数据处理机 上的 Logstash 消费)。

在测试一个阶段时,会关闭另一端的 Logstash

数据

平均数据后,可供参考的数据为:

Logstash 分析速度为:2352.94 lines/s

ES集群写入速度为:9345.79 records/s