PHP 5 到 PHP 7 性能评测(含 JIT 版 PHP 8 对比)

自 1994 年 Rasmus Lerdorf 创建 PHP 以来, PHP 语言经历了许多改进,其中性能是开发人员在评估新版本时考虑的主要标准之一。

阅读这篇文章,可以了解从 PHP 5 到 7(包括 7.1)的性能提升,同时也将了解到即将加入到 PHP 8 的试验性的 JIT 分支版本的性能。

简介

本文将根据时间作出更新,增加更多信息和基准测试结果,包括尚未发布的新版本,以便更好地了解多年来 PHP 性能演变。如果您有更正或建议改进,请在文后留言。

自 1994 年 Rasmus Lerdorf 创建 PHP 以来, PHP 语言经历了激烈的演进。虽然第一版是一个简单的一人开发的 CGI 程序,Rasmus Lerdorf、Andi Gutmans 和 Zeev Suraski 加入了该语言的第三个版本的开发,并根本性重新设计。从那之后, PHP 开发组也创建并发展起来。

随着项目的发展,由于 PHP 3 天然的可扩展性, PHP 在核心和附加扩展开发的功能得到了蓬勃发展,如网络通信,解析,缓存和数据库支持。

语言本身也在发展,带来了一系列的改进。这包括支持面向对象的结构,例如类,接口, traits,闭包等。

对于许多开发人员来说,仅有新功能是不够的。随着语言越来越受欢迎, PHP 社区对于提供更好性能,可扩展性和更少内存使用的需求越来越强烈。

PHP 开发团队近 20 年来一直致力于解决这些需求,虽然 PHP 3 的引入大大提高了性能,但直到 Andi Gutmans 和 Zeev Suraski 引入 Zend Engine 并发布 PHP 4, PHP 的性能才开始变得正式起来。

2000 年推出的新的内存编译器和执行器模型大大提高了 PHP 的性能(提高了 5 倍甚至 10 倍),并首次被正式的 Web 应用程序和站点所使用。我们可以说,今天 PHP 的成果远远超出了任何人在 PHP 项目诞生时的期望。

PHP 的蓬勃发展增加了改善性能的欲望。幸运的是, Zend Engine 中设计的模型为持续优化性能提供了良好的基础。

虽然 PHP 5.0 没有带来实质性的性能提升,并且在某些情况下甚至比 PHP4 更慢,一个由 Dmitry Stogov 领导的团队在社区的大力帮助下已经在后续版本中不断优化语言,在 PHP 5.6 发布的时候,在大多数情况下,性能提升在 1.5x 和 3x 之间。

2015 年 12 月, PHP 7.0 取得了重大突破。 2016 年 12 月,7.1 版本也带来了一系列增强功能。

PHP 8 性能展望

这是一个前途光明的版本,目前正在开发当中,由 Zend 的 Dmitry Stogov 主导。虽然它是基于 PHP 7.1 版本基础,但实际版本号尚未定义,所以本文称这个版本为“试验 JIT”分支下。

关键功能 JIT( :Just-In-Time)编译,是一种将代码转换为另一种字节码(比如运行它的机器 CPU 的本地代码)的技术。 JIT 可以使程序运行更快。

本文涵盖了几个基准测试的结果,从 PHP 5 的第一个版本到 PHP 的试验性 JIT 分支版本,PHP 5 之前的版本性能本文不作介绍。

在写这篇文章的时候,我们很难确定 PHP 8 之前是否会有另一个主要版本,比如 PHP 7.2。但是可以假设在 PHP 8 发布时,它已经包括当前试验版 JIT 分支的强大功能。

PHP 性能评估

本文只运行纯 CPU 任务脚本的基准测试(不需要I / O操作的任务例如访问文件,网络或数据库连接)。

使用的基准测试脚本如下所示:

bench.php 可在PHP源代码的 php-src/Zend 目录

micro_bench.php 也可以在 PHP 源代码发布的 php-src/Zend 目录中找到

mandelbrot.php

基准脚本仅使用每个PHP主要版本的最新小版本运行。因此,测试的版本如下:

5.0.5

5.1.6

5.2.17

5.3.29

5.4.45

5.5.38

5.6.28

7.0.13

7.1.0

开发版 JIT 分支

当然,我想确定,我们在相同的基准上运行所有小版本,例如在 5.3.0 到 5.3.29 之间。结果是有说服力的:性能方面的主要增强不是由小版本带来的,而是主要版本号的变化,例如从 PHP 5.4 到 PHP 5.5,或从PHP 5.6 到 PHP 7。

小版本没有显示任何明显的性能改进。这意味着相同的脚本应该以相同的速度运行,无论您使用 PHP 5.4.0 还是 PHP 5.4.45。

您可以查看基准进程部分,详细说明主机系统的设置,各个基准的运行方式以及如何解释时序结果。

纯 CPU 基准测试结果

这部分给出了每个 PHP 版本的基准测试结果。

每个基准列显示 3 个值:

时间:执行时间,以秒和毫秒为单位

%rel。 gain:相对于以前的版本收益的执行时间。 在下面的表格中,例如,%rel。 bench.php 和版本 5.3.29 的收益是 31.89%,意味着该脚本比 5.2.17 版本运行快 31.89%。

abs。 gain:与 PHP 5.0 相比脚本运行的收益。 如果你看看bench.php 和试验性的 JIT 分支的这个列的交集,你会注意到,对于这个特定的测试基准,PHP 8 比 PHP 5.0 快 41 倍以上。

纯CPU基准测试的结果如下所示:

测试不能在 5.3 之前的版本上运行,因为它使用了尚未实现的对象功能。

此列中的结果有点偏颇,因为基准需要至少 PHP 5.3 运行。把它们当成纯粹说明,因为他们不能与 PHP 5.0 性能进行比较。

这是一个 mandelbrot.php 脚本的修改版本,它运行得太快,在 7.1.0 和试验 JIT 分支无法准确的统计时间,我们在脚本中运行计算 100 次而不是 1 次。

当然,这些都是纯 CPU 的基准测试。它们不涵盖 PHP 性能的所有方面,它们可能不代表真实情况。但是结果足够显著,足以说明几个方面的问题:

PHP 5.1 将 PHP 5.0的 性能提高了一倍多

5.2 和 5.3 带来了他们自己的一些性能增强,但他们没有像5.1版本那样引人注目。

5.4 版本是一个大的性能改进。(PHP核心开发者鸟哥曾经ppt说明php5.4性能改进的原因)

opcache 扩展插件与 5.5 和 5.6 版捆绑在一起。当相同的脚本在 Web 服务器连续运行时,由于更快的代码加载会带来性能增强。但是,opcache 不会真正显示其在CLI模式下执行脚本的优势。

PHP 7.0 是性能方面的一个重大突破。 Zend Engine 已经完全重新设计,我们可以在这里看到这项工作的结果。(这里有PHP核心开发者鸟哥的ppt说明php 7性能改进的原因)

PHP 7.1 在 opcache 扩展中引入了 opcode 优化。这再次解释了上述表格中当与 7.0 相比时,性能的增益。

试验 JIT 分支是另一个重大突破,JIT 可以对现有代码提供很大的性能改进,但在某些情况下,你可能会注意到速度提高只有几个百分点,在最坏的情况下,它甚至可能会变慢,因为编译不会生成更快的代码。请记住,此功能目前正在开发中。

本节介绍了 3 个纯 CPU 基准测试脚本的结果。在运行通常执行的以数据库或文件访问典型场景的 PHP 应用程序时,它不会给出同样的数字,但我认为他们能够代表您对代码的某些部分期望的性能改进。

PHP 每个版本的性能提升

PHP 5 相比 PHP 4 带来了明显的改进。 Zend Engine 是 PHP 解释器的核心,它已经完全重新设计( Zend Engine 2),为将来的增强功能奠定了基础。本文不多介绍 PHP 4 和 PHP 5 之间的差异,只简要概述的 PHP 5.0 之后发生了什么。

以下部分列出了在后续 PHP 版本中的改进。请注意,这里仅列出影响 PHP 核心的修改。有关更完整的描述,请查看 PHP 5 和 PHP 7 的change log。

PHP 5.1

Compiled variables

Specialized executor

Real-path cache

Faster switch() statement handling

Faster array functions

Faster variable fetches

Faster magic method invocations

PHP 5.2

New memory manager

Optimized array/HashTable copying

Optimized require_once() and include_once() statements

Small optimization on specific internal functions

Improved compilation of HEREDOCS and compilation of interpolated strings

PHP 5.3

Segmented VM stack

Stackless VM

Compile-time constants substitution

Lazy symbol table initialization

Real-path cache improvement

Improved PHP runtime speed and memory usage

Faster language parsing

Improved PHP binary size and code startup

PHP 5.4

Delayed HashTable allocation

Constant tables

Run-Time binding caches

Interned Strings

Improved the output layer

Improved ternary operator performance when using arrays

PHP 5.5

Improved VM calling convention

OPcache integration

Other misc. optimizations to the Zend Engine

PHP 5.6

Optimized empty string handling, minimizing the need to allocate new empty values

PHP 7.0

下面大部分列出的改进都与 Zend Engine 相关:

Core data structures re-factoring

Better VM calling convention

New parameters parsing API

Yet another new memory manager

Many improvements in VM executor

Significantly reduced memory usage

Improved __call() and __callStatic() functions

Improved string concatenation

Improved character searching in strings

PHP 7.1

New SSA based optimization framework (embedded into opcache)

Global optimization of PHP bytecode based on type inference

Highly specialized VM opcode handlers

PHP 8 / 下一代试验性 JIT 分支版

Just-In-Time compiling

性能如何衡量

基准化比单纯运行 Unix 时间命令来测量脚本的执行有所区别。 这就是为什么我经历了以下步骤:

配置系统

首先我设置了一个具有以下特性的专用系统:

一个带有1个2.4GHz虚拟内核,2GB RAM和两个SSD驱动器的VPS,一个用于存储操作系统数据,另一个用于存储各种PHPyuan dai ma,二进制文件和报告输出

Debian Wheezy操作系统,版本3.2.82-1

Gnu C编译器版本4.9.2-10(Debian Jessie发行版)

虽然系统捆绑了Gnu C编译器版本4.7.2,但需要升级到更新的版本。 试验性 JIT 分支必须用Gnu C> = 4.8编译。

编译源代码

在构建完整发行版之前,使用以下选项运行配置脚本:

--prefix=/usr/local/php 

--disable-debug

--disable-phpdbg

--enable-mysqlnd

--enable-bcmath

--with-bz2=/usr

--enable-calendar

--with-curl

--enable-exif

--enable-fpm

--with-freetype-dir

--enable-ftp

--with-gd

--enable-gd-jis-conv

--enable-gd-native-ttf

--with-gettext=/usr

--with-gmp

--with-iconv

--enable-intl

--with-jpeg-dir

--enable-mbstring

--with-mcrypt

--with-openssl

--enable-pcntl

--with-pdo-mysql=mysqlnd

--with-png-dir

--with-recode=/usr

--enable-shmop

--enable-soap

--enable-sockets

--enable-sysvmsg

--enable-sysvsem

--enable-sysvshm

--enable-wddx

--with-xmlrpc

--with-xsl

--with-zlib=/usr

--enable-zip

--with-mysqli=mysqlnd

注意,在编译旧版时,上面的一些选项需要被禁用或被其他替代,并且并不是所有的扩展都可用或可以被编译。

运行基准测试

每个基准测试都使用 PHP CLI 专用脚本运行,该脚本遵循以下步骤:

使用 microtime()函数从内部获取脚本执行时间。 在此修改后,基准脚本将如下所示:

<?php
    $__start__ = microtime( true );
    /*
        original benchmark script code here
    */
    fprintf( STDERR, microtime( true ) - $__start__);
 ?>

执行 2 次运行,以确保 PHP 可执行文件和基准测试脚本内容都在操作系统缓存中

运行脚本 5 次,并提取最小,最大和平均运行时间,如脚本报告。 本文仅显示平均运行时间,称之为“脚本运行时间”。

php.ini 文件如下所示:

engine = On
short_open_tag = Off
realpath_cache_size = 2M
max_execution_time = 86400
memory_limit = 1024M
error_reporting = 0
display_errors = 0
display_startup_errors = 0
log_errors = 0
default_charset = "UTF-8"

[opcache]
zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
opcache.optimization_level=-1
opcache.fast_shutdown=1
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.use_cwd=1
opcache.max_accelerated_files=100000
opcache.max_wasted_percentage=5
opcache.memory_consumption=128
opcache.consistency_checks=0
opcache.huge_code_pages=1

// PHP 8/Next only
opcache.jit=35
opcache.jit_buffer_size=32M

分析运行结果

使用 Unix time 命令来计时,输出如下所示:

$ time php bench.php
real: 0m1.96s
user: 0m1.912s
sys: 0m0.044s

第一个值,real :, 是命令开始到终止之间的时间(当你回到 shell 提示符)。

第二个值,user :,说明在用户模式中花费的时间(在我们的例子中,这是在 php 可执行文件中花费的时间)。

最后一个值 sys :,说明在操作系统(内核)调用中花费的时间。这个值应该是最小的,但是如果你的代码访问缓慢的设备结果会比较大。重负载的操作系统也可能影响此处报告的值。

在空闲系统上通常,数量(user + sys)应该非常接近 real。这是在上面的例子中的情况:user + sys = 1.956s,real 是 1.960s。 0.004s 的差异不属于当前进程:它仅仅意味着操作系统执行任务所花费的额外时间,例如调度。

同一个脚本在一个负载很重的系统上执行,并行编译 3 个不同的 PHP 版本:

$ time php bench.php
real: 0m7.812s
user: 0m2.02s
sys: 0m0.101s

在这里我清楚地看到,系统本身的重负载对使用的时间(也许在系统时间)有重大影响。

这就是为什么我在这个基准中保留一个额外的值,操作系统开销,这是调用的时间和(用户+系统)时间之间的差。

在纯 CPU 基准测试活动期间,我确保在 99% 以上的时间,这个值严格小于 100 毫秒,即使运行需要几十秒钟完成的脚本。

特别鸣谢

特别鸣谢 Dmitry Stogov 和所有 PHP 核心开发者们。

本文是和 Dmitry Stogov 合作完成的 , 他帮助审阅了文章内容 , 来保证这个文章的正确性。

Dmitry Stogov 曾经是 Truck MMCache 的开发者,在 PHP4 时代就可以用作共享内存中缓存 PHP Opcode,从那时候起,Dmitry Stogov 就加入了 Zend,一直到现在。

Dmitry 是 PHP NG 的主要开发者 , 也就是我们后来知道的 PHP7, 和 Dmitry 一起合作的有 Xinchen Hui(鸟哥),Nikita Popov,正是他们在一起开发了 PHP7 以及后来的版本包括 PHP JIT。

在 PHP7 之前 , PHP5 时代的 Andi Gumans, Zeev Suraski 以及 Stas Malishev 等也做了很多的工作来提升 PHP5 的性能,限于篇幅,本文就不详细介绍。

结论

本文的目的是给你一个不同版本PHP性能的概述,从 5.0 开始,到当前正在开发的最新版本,使用一组已知的基准脚本。

它还为您提供了由每个连续 PHP 版本解决的性能改进方面的列表。

本文来自开源中国社区 [http://www.oschina.net]

时间: 2024-11-17 12:42:49

PHP 5 到 PHP 7 性能评测(含 JIT 版 PHP 8 对比)的相关文章

Android App性能评测分析-cpu占用篇

1.前言 很多时候在使用APP的时候,手机可能会发热发烫.这是因为CPU使用率过高,CPU过于繁忙,会使整个手机无法响应用户,整体性能降低,用户体验就会很差,也容易引起ANR等等一系列问题.以下会根据实际app性能测试案例,展开进行app性能评测之CPU使用率的分析和总结. CPU使用率原理理解 在Linux系统下,CPU利用率分为用户态.系统态.空闲态,分别表示CPU处于用户态执行的时间,系统内核执行的时间,和空闲系统进程执行的时间. 平时所说的CPU利用率是指:CPU执行非系统空闲进程的时间

固态硬盘不同分区格式性能评测

  固态硬盘不同分区格式性能评测 FAT32: 1997年的Windows 95 OSR2第二版系统中首次引入,至今依然很流行,特别是低容量设备上,因为支持实在太过广泛,技术所有的主流操作系统都可以创建.读取.写入FAT32分区. 因为是32位文件系统,FAT32分区的最大容量只有2TB,8KB簇下也不过32TB,单个文件体积更是不能超过4GB,文件名长度也不可以超过255个字符. 另外,FAT32不支持日志.版权管理等高级技术,安全性也很差. NTFS: 全称New Technology Fi

移动App性能评测与优化

实战 移动App性能评测与优化 TMQ专项测试团队 编著  图书在版编目(CIP)数据 移动App性能评测与优化/ TMQ专项测试团队编著. -北京:机械工业出版社,2016.9 (实战) ISBN 978-7-111-54826-3 I. 移- II. T- III. 移动终端-应用程序–程序测试–研究 IV. TN929.53 中国版本图书馆CIP数据核字(2016)第213174号 本书通过六个专题方向介绍腾讯公司移动互联网事业群在移动应用性能评测优化方面的实战经验,涉及内存.电量.流畅度

MaxCompute2.0性能评测:更强大、更高效之上的更快速

MaxCompute2.0(原Odps):通过性能评测,MaxCompute2.0离线计算比同类产品Hive2.0 on Tez性能优势快约90%以上:MaxCompute2.0从新一代执行引擎到编译引擎.基于代价的优化器全流程针对性能提升做出了卓越改进.        本次评测侧重于已发布的MaxCompute2.0与离线处理同类竞品及线上稳定版本的性能对比,通过测试我们看到MaxCompute2.0在功能上更强大.使用和发布更新更高效.开放生态的同时针对线上作业占比80%以上的Sql以及其中

2011年4月份美国最佳虚拟主机TOP12性能评测

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 近日,据Hostpeek最新发布的美国最佳虚拟主机性能评测显示,4月,美国知名IDC服务商HostGator.1and1.JustHost位列最佳虚拟主机性能排行榜前列,在各项性能测试中皆表现不凡.与3月相比,显然,HostGator在历经3个月后,成功夺回榜首行列,1and1惜居第二. 下面,IDC评述网将与大家一起关注2011年4月美国最

11月下旬美国最佳虚拟主机TOP12性能评测

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 据Hostpeek最新发布的美国最佳虚拟主机性能测试显示,11月下旬,美国知名IDC服务商HostGator再次位居榜首,各项性能测试皆在12名最佳虚拟主机性能评测中稳居前列.紧随其后的依旧是表现良好的1and1.HostMonster,继11月上旬成功挤进前三后,在11月下旬的性能测试里,依旧排名第三. 下面,IDC评述网将与大家一起关注1

CYQ.Data 数据框架 性能评测

最近有网友经常关注 CYQ.Data 的性能问题,虽然关注,但没发现谁主动的写过和其它框架的性能评测文章.   个人平常比较忙一些,这么长久以来,一直也没好好的为 CYQ.Data 写一个简单的性能测试.   今天,得为它写了一篇了.   杂七几句: 当很多人问我 CYQ.Data 性能怎样时,我说:比其它ORM的框架性能要好.   当然,我没有给出任何的测试数据来证明,因为我没用过其它框架,所以没法给出数据,所以只能任网友:爱信不信.   说比其它框架要好,当然不是因为卖瓜的赞瓜甜,而是基于以

国内主流云服务器性能评测报告

本文讲的是国内主流云服务器性能评测报告[IT168 评论]作为朋友眼中的资深技术人士,这几年来,我用过不少的云服务.云产品.近段时间以来,总有朋友问我,云服务器这样的产品,虽说方便.安全,可是却不知道怎么选择适合自己的,网上相关的评测文章又很少,希望我能帮帮他们.那今天我就来写一写云服务器这个产品的评测. 以我自己的经验和感受,如果要买云服务器的话,还是应该在阿里云.腾讯云.金山云这些主流云服务商的产品中挑选.那么作为云服务器的深度使用者,我接下来就将对阿里云.腾讯云和金山云最新发布的同类产品进

入侵防御产品性能评测方法之前世今生

网络带宽增加带来的对设备吞吐量增长的要求比近期的北京暴雨有过之无不及,这也让吞吐量成为评价一款网关安全设备的重要指标.对于入侵防御产品来说,在100%检测漏洞时的吞吐量所能达到的峰值,正逐渐成为真实评价产品性能的重要指标. 日前,中国信息安全行业领导企业天融信,推出评价入侵防御产品性能的新标杆指标:满检速率.天融信公司在多年的入侵防御产品研发和测试经验积累基础上,结合国际测评机构的最新技术进展,提出了该评价入侵防御产品性能的新标杆指标. 入侵防御产品性能评测方法之前世今生 经过多年的高速度发展,