HHVM 中的 RepoAuthoritative 模式

HHVM 3.8 中提出了一个 RepoAuthoritative 模式,用于提升 PHP 代码的效率。

PHP 代码是解释型的,也就是每次执行的时候,PHP 引擎都会读取源代码,编译成机器代码之后再执行。这也就是为什么解释型语言比较慢的原因之一,它不能一次编译完成,而是一定要运行到哪里编译到哪里。编译的过程拖慢了整个运行的效率。而这样每次“编译”的过程显得有些多余,因为代码是基本不会变的。于是 PHP-FPM 是提出了 OpCache 来缓存编译的结果,如果代码已经被编译过,且源代码没有改动,则继续使用缓存。

而 HHVM 则更进了一步,在 RepoAuthoritative 开启之后,指定的文件夹会被编译成一个二进制文件,并同时进行优化。官方说法是,这样的优化可以在 HHVM 本身的基础上,再提升 20% 的运行效率。

开启的方法如下,其中 /var/www 是想要编译的文件夹。

关闭的方法如下:

编译的过程使用了 /var/run 做为临时文件夹,实测 WordPress 编译完成之后,要占用 175MB 的空间,如果 /var/run 太小会提示“disk is full”错误。

当然, RepoAuthoritative 也有一定的限制,比如不能使用 eval() 和 create_function() 等动态改变代码的语句。不过 WordPress 中几乎没有用到,说“几乎”是因为实际上有两处用到了,一个是在 wp-includes/pomo/po.php 中,这个文件貌似根本不会被执行到;另一处是在 wp-includes/atomlib.php 中,只要不使用 atom 作为 RSS feed 即可。另外就是编译完成之后,源代码的改动就会“失效”,要再一次编译才会使改动起作用。

然而,由于 HHVM 自身已经相当地高效了,开启 RepoAuthoritative 模式之后没有明显的变化。本站实测下来,TTFB 时间大概减少了 50ms,对于原本只有 700ms 左右的速度来说,看不出效果。我试用了一下之后就把它关闭了。不过至少说明在 WordPress 上使用这个功能是没有问题的。如果你的 WordPress 中有非常慢的功能,不妨试一下 RepoAuthoritative 模式。

在 PHP 中实现 String 的 StartsWith 和 EndsWith

和 Javascript 一样,PHP 中也没有对 String 实现 StartsWith 和 EndsWith 这两个方法。由于这两个方法很常用,我们只好自己来实现一下。

在 PHP 4 中,常见的做法和 Javascript 类似,如下:

上面的方法会使用更多的内存,并且对字符串扫描了两遍,效率不高。这种方法在 PHP 5 中已经过时了,因为 PHP 5 给出了一个 substr_compare 方法,可以直接比较子字符串,如果代码就可以简化成这样:

上述实现的效率至少快了一倍。由于历史遗留的问题,很多现存代码都没有更新,比如 WordPress 的源码中就存在了老版本的实现。如果你已经在使用 PHP 5 或者 HHVM,不妨试试第二种实现。

投靠 Ubuntu

经过一番纠结之后,我还是把博客换到了 Ubuntu 之上。

之前提到过,从 AWS 转到 GCE 的时候,被迫选择了 RHEL 7(Redhat Enterprise Linux),因为只是 RHEL 7 是完全兼容 AmazonLinux 的。虽然 RHEL 需要另外付费,但为了平滑过渡,我还是以谨慎为先。

RHEL 有非常完善的商业支持,文档很齐全,有什么问题一查就可以明白。唯一的问题是,它的收费太高了,GCE 上面用一个月需要 50 刀以上,且不像主机一样用的时间长会打折,这样算下来,年费和一个 Radhat 的订阅差不多价格。但是我并不需要什么客户支持,技术问题都可以靠 Stackoverflow 搞定,这个订阅费用就白白浪费了。这也是我转向 Ubuntu 的主要原因。

还有一个原因是 HHVM。HHVM 是 Facebook 的 PHP 引擎实现,完全兼容 PHP 5.5 (及以上)。WordPress 从 3.9 开始,完整兼容 HHVM。

HHVM 的响应时间,据说是 PHP-FPM 的一半,也就是提升了一倍的吞吐量。原生 PHP 要做到这个效果,需要等 PHP 7 发布才行。看着各种发行版对于新软件的保守程度,不知道 PHP 7 要到什么时候才能成为主流。另一方面,Facebook 的研发能力肯定要比 Zend 来得强,等 PHP 7 发布了,HHVM 的性能肯定会更强。于是我就抛弃了原生 PHP,转投 HHVM。

当然,我也可以在 RHEL 上自己编译安装 HHVM。我试过,GCE 的机器编译了一个小时,我都快睡着了才编译完成,但安装(make install)的时候,告诉我某个文件不存在 -_-。我还是老老实实用官方的安装包吧,而 HHVM 官方只提供了 Debian 系列的安装包。

为什么没有选 Debian?Debian 保守到现在还只提供了 Apache 2.2,无语。

那也可以转投 Nginx 呀?我不高兴重写那一堆的 RewriteRule,并且 PageSpeed 在 Nginx 上也需要自己编译安装,不想再重蹈 HHVM 的覆辙。

由于 HHVM 和 PHP-FPM 的用法几乎一模一样,转换过程没出现任何问题,我做的唯一的工作就是重新设置了 Apache。花了几个小时,不过没什么难度,转换过程很顺利。

现在博客已经运行在 Ubuntu 14.04 + Apache 2.4 + HHVM 3.5 + MySQL 5.6 之上,欢迎测试,有问题请留言。

在 PHP 中生成 UUID

UUID 全称是 Universally unique identifier,它是一种识别符,使用任意的计算机都可以生成,不需要一个中央数据库进行管理,即可以保证几乎没有重复的几率。而 UUID 的值域之大,据说给世界上每一粒沙子分配一个 UUID,也不会有重复的。

最近在改 WordPress 的代码,需要用到 UUID。但是,PHP 中居然没有生成 UUID 的函数,只好自己写一个。

上述代码可以生成一个 UUID version 4。UUID 目前有 5 个版本,其中第四版是完全随机的,生成起来比较容易。而其中的 com_create_guid,是 Windows 中 PHP 的一个函数,它直接调用 COM 的 CreateGuid 函数来生成 UUID,但是在 Linux 没有对应的函数库,只好自己写了。为了方便在不同的平台上使用,就创建了一个同名的函数。其它的代码就是生成随机数了。

至于用法,就直接调用 com_create_guid() 即可。