首先，我们来先大致了解下http-->nginx-->php-fpm-->php处理的流程机制
http request --->nginx（代理）---->php-fpm(master 进程，分配）---->php-fpm(worker处理 ) ---->php-cgi(1.启动ZEND引擎，加载配置，载入module,2.初始化php脚本进行词法分析，语法分析，生成语法树，3.ZEND引擎编译语法树，生成可执行字节码。4.执行字节码，返回处理结果)
opcache 就缓存了php脚本预编译的字节码避免每次处理请求都重复执行（php-cgi处理的1，2，3）步骤，这样可以使得php性能大大提高。
php.ini
1.重启php-fpm
2.打印phpinfo()，看到有ZEND OPcache就证明已经开启成功了
1 生成器 yield关键字yield的中文文档在这里：http://php.net/manual/zh/language.generators.overview.php
查看文档，能知道yield的一个功能就是能有效的降低迭代的内存开销。比如官网的这个xrange例子：
<?php
function xrange($start, $limit, $step = 1) {
for ($i = $start$i <= $limit$i += $step) {
yield $i
}
}
echo 'Single digit odd numbers: '
/*
* Note that an array is never created or returned,
* which saves memory.
*/
foreach (xrange(1, 9, 2) as $number) {
echo "$number "
}
echo "\n"
?>
这里的xrange是一个迭代，功能和range是一样的，如果使用range函数的话，那么函数内部实现会储存每个迭代的中间过程，即每个中间变量都有个内存空间，那么首先程序使用的内存空间就大了，而且分配内存，回收内存都会导致程序的运行时间加长。但是如果使用上yield实现的xrange函数的话，里面所有的中间变量都只使用一个内存$i，这样节省的时间和空间都会变小。
那么为什么yield会有这样的效果呢？联想到lua中的yield，这里就算是协程的概念了。在lua语言中，当程序运行到yield的时候，使用协程将上下文环境记录住，然后将程序 *** 作权归还到主函数，当主函数调用resume的时候，会重新唤起协程，读取yield记录的上下文。这样形成了程序语言级别的多协程 *** 作。php 5.5这里的yield也是同样的道理，当程序运行到yield的时候，当前程序就唤起协程记录上下文，然后主函数继续 *** 作，只是php中没有使用如resume一样的关键字，而是“在使用的时候唤起”协程。比如上例中的foreach迭代器就能唤起yield。所以上面的这个例子就能理解了。
其实照着引用yield来说，好多内部函数，特别是迭代有关的函数应该都有可能进行优化。或许后续会有yield版本和非yield版本的实现同一功能的函数把。
2 finally关键字
这个和java中的finally一样，经典的try ... catch ... finally 三段式异常处理。
3 foreach 支持list()
对于“数组的数组”进行迭代，之前需要使用两个foreach，现在只需要使用foreach + list了，但是这个数组的数组中的每个数组的个数需要一样。看文档的例子一看就明白了。
<?php
$array = [
[1, 2],
[3, 4],
]
foreach ($array as list($a, $b)) {
echo "A: $aB: $b\n"
}
?>
4 empty() 支持自定义函数了
之前empty()中的参数是不能为函数的。现在可以了
<?php
function foo(){
return false
}
if(empty(foo())){
echo 11
} else {
echo 12
}
5 非变量array和string也能支持下标获取了
<?php
echo array(1, 2, 3)[0]
echo [1, 2, 3][0]
echo "foobar"[2]
?>
6 类名通过::class可以获取
<?php
namespace Name\Space
class ClassName {}
echo ClassName::class
echo "\n"
?>
7 增加了opcache扩展
使用opcache会提高php的性能，你可以和其他扩展一样静态编译（--enable-opcache）或者动态扩展（zend_extension）加入这个优化项。
希望可以采纳，谢谢。
PHP5.5 和PHP5.6的区别摘要：在一个基于Vagrant的本地环境中，可能是某个错误的原因，导致HHVM测试结果很差；在HHVM伙伴们协助下，该原因仍在研究中！然而，在DigitalOcean的一个4GB虚拟机中，HHVM甚至盖过了最新版的PHP-NG的风头！
结论：它们反映出HHVM的功效更佳（在JIT热启动后），虽然出于某些原因，我们不能在所有装备中获取这些结果。
如果你记得我们在几个月前写过一篇文章，那时WordPress 3.9表明是完全支持HHVM的，当时是那么令我们欢欣鼓舞。最初的基准测试结果显示，HHVM要比驱动着当前所有PHP构建的Zend引擎高级得多。后来，问题就出来了：
HHVM只能以单个用户运行，这意味着（在共享环境中）安全性差了
HHVM在崩溃后不会自动重启，而不幸的是，它至今仍然经常发生
HHVM在启动时使用大量内存，虽然，它和同规模的PHP-FPM比较，单个请求的内存使用量更低
很显然，你不得不根据你的（或者更确切地说是你的站点）的需求采取折中方案，然而这值得吗？切换到HHVM后，你期望获得多少性能改善呢？
在Kinsta，我们真的想要测试所有新技术，并通常会优化这一切来为我们的客户提供最佳的环境。今天，我最终花了点时间来配置测试环境并进行了一些测试来对比两个不同的构建，一个是全新出炉的WordPress安装，另外一个则添加了大量内容的WooCommerce！为了计量脚本的运行时间，我只是简单地添加了
<?php timer_stop(1)?>
这一行到footer.php的/body标记前。
这里是配置环境的详情：
DigitalOcean 4GB 雨滴容器 (2 CPU核心, 4GB RAM)
Ubuntu 14.04, MariaDB10
测试站点： 已导入演示内容的Munditia主题，WooCommerce 2.1.12 &WordPress 3.9.1
PHP 5.5.9, PHP 5.5.15, PHP 5.6.0 RC2, PHP-NG （20140718-git-6cc487d）和HHVM 3.2.0 （版本是PHP 5.6.99-hhvm）
没有进一步大费周章，这些就是我的测试结果，数值越低越好，以秒为单位：
DigitalOcean 4GB 雨滴容器
单位是秒，运行10次，越低越好
看起来似乎PHP-NG在它首次运行后就获得了峰值性能！HHVM需要更多几次重载，但是它们的性能貌似差不多！我等不及PHP-NG合并到开发主干了！：）
一分钟命中数，越高越好。
PHP 5.5.15禁用OpCache
执行： 236 hits
可用性： 100.00 %
消耗时间： 59.03 secs
传输的数据： 2.40 MB
回应时间： 2.47 secs
执行率： 4.00 trans/sec
吞吐量： 0.04 MB/sec
并发数： 9.87
成功的执行： 236
失败的执行： 0
最长执行： 4.44
最短执行： 0.48
PHP 5.5.15启用OpCache
执行： 441 hits
可用性： 100.00 %
消耗时间： 59.55 secs
传输的数据： 4.48 MB
回应时间： 1.34 secs
执行率： 7.41 trans/sec
吞吐量： 0.08 MB/sec
并发数： 9.91
成功的执行： 441
失败的执行： 0
最长执行： 2.19
最短执行： 0.64
PHP 5.6 RC2禁用OpCache
执行： 207 hits
可用性： 100.00 %
消耗时间： 59.87 secs
传输的数据： 2.10 MB
回应时间： 2.80 secs
执行率： 3.46 trans/sec
吞吐量： 0.04 MB/sec
并发数： 9.68
成功的执行： 207
失败的执行： 0
最长执行： 3.65
最短执行： 0.54
PHP 5.6 RC2启用OpCache
执行： 412 hits
可用性： 100.00 %
消耗时间： 59.03 secs
传输的数据： 4.18 MB
回应时间： 1.42 secs
执行率： 6.98 trans/sec
吞吐量： 0.07 MB/sec
并发数： 9.88
成功的执行： 412
失败的执行： 0
最长执行： 1.93
最短执行： 0.34
HHVM 3.2.0（版本是PHP 5.6.99-hhvm）
执行： 955 hits
可用性： 100.00 %
消耗时间： 59.69 secs
传输的数据： 9.18 MB
回应时间： 0.62 secs
执行率： 16.00 trans/sec
吞吐量： 0.15 MB/sec
并发数： 9.94
成功的执行： 955
失败的执行： 0
最长执行： 0.85
最短执行： 0.23
PHP-NG启用OpCache（构建: Jul 29 2014）
执行： 849 hits
可用性： 100.00 %
消耗时间： 59.88 secs
传输的数据： 8.63 MB
回应时间： 0.70 secs
执行率： 14.18 trans/sec
吞吐量： 0.14 MB/sec
并发数： 9.94
成功的执行： 849
失败的执行： 0
最长执行： 1.06
最短执行： 0.13
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）