Badoo 告诉你切换到 PHP7 节省了 100 万美元

介绍

我们成功的把我们的应用迁移到了php7上面（数百台机器的集群），而且运行的很好，据说我们是第二个把如此规模的应用切换到php7的企业，在切 换的过程我们发现了一些php7字节码缓存的bug，庆幸的是这些bug现在已经被修复了，现在我们把这个激动人心的消息分享给所有的php社 区：php7现在已经可以稳定的运行在商用环境上，而且比以前更加节省内存，性能也有的很大的提高。

下面我会详细的介绍下我们是如何把应用前移动php7的，我们在这中间遇到的问题及处理情况，还有最终的结果。但首先让我们回头看看一些更常见的问题：

Web项目的瓶颈在于数据库持久化这是一个常见的误解。一个设计良好的系统应该是平衡的：当访问量增长时，由系统的各个部分分摊这些压力，同样的， 当达到系统阀值时，系统的所有组件(不仅仅包括硬盘数据库，还有处理器和网络)共同分摊压力。基于这个事实，应用集群的处理能力才应该是最重要的因素。在 很多项目中，这种集群由数以百计甚至数以千计的服务器组成，这是因为花时间去调整集群的处理能力更加经济实益(我们因此节省一百多万)。

PHP的Web应用，处理器的消耗跟其他动态高级语言一样多。但是PHP开发者面对着一个特别的障碍(这让他们成为其他社区恶意攻击的的受害者)： 缺少JIT，至少没有一个像C/C++语言那样的可编译文本的生成器。PHP社区无力在核心项目框架上去实现一个类似的解决方案更是树立了一种不良的风 气：主要的开发成员开始整合他们的解决方案，所以HHVM在Facebook上诞生了，KPHP在VKontakte上诞生，还有其他类似的方案。幸运地 是，在2015年，随着PHP7的正式发布，PHP要开始”Grow up”啦。虽然还是没有JIT，但很难去评定这些改变在”engine”中有多重要。现在，尽管没有JIT，PHP7可以跟HHVM相匹敌( Benchmarks from the LightSpeed blog  or PHP devs benchmarks)。新的PHP7体系架构将会让JIT的实现变得简单。

在Badoo的平台开发者已经非常关注近些年出现的每一次问题，包括HHVM试点项目，但是我们还是决定等待很有前途的PHP7的到来。现在我们启 动了已经基于PHP7的Baboo！这是一个史诗般的项目，拥有300多万行的PHP代码，并且经历了60000次的测试。我们为了处理这些挑战，提出了 一个新的PHP引用测试框架（当然，也是开源的），并且在整个过程中节省了上百万美元。

HHVM的试验

在切换到PHP7之前，我们曾花了不少时间来寻找优化后端的方法。当然，第一步就是从HHVM下手。在试验了几周之后，我们获得了值得关注的结果：在给框架中的JIT热身之后，我们看到速度与CPU使用率上升了三倍。

另一方面，HHVM 被证实有一些严重的缺点：

• 部署困难而且慢。在部署过程中，你不得不首先启动JIT-cache。当机器启动的时候，它不能负载产品流量，因为所有的事情进行的相当慢。 HHVM 团队同样不推荐启动并行请求。顺便一提，大量聚类操作在启动阶段并不快速。此外，对于几百个机器构成的大集群你必须学习如何分批部署。这样体系结构和部署 过程相当繁琐，而且很难估算出所需要的时间。对于我们来说，部署应该尽可能简单快捷。我们的开发者将在同一天提供两个开发版并且释出许多补丁。

• 测试不便。我们非常依赖runkit扩展，但是它在HHVM中却不可用。稍后我们将详细介绍runkit，但是无需多言，它是一个能让你几乎随心 所欲更改变量、类、方法、函数行为的扩展。这是通过一个抵达PHP核心的集成来实现的。HHVM引擎仅仅显示了略微相像的PHP外观，但是他们各自的核心 十分不同。鉴 于扩展的特定功能，在HHVM上独立地实现runkit异常困难，而且我们不得不重写数万测试用例以确保HHVM和我们的代码正确的工作。这看起来似乎不 值得。公平的说，我们以后在处理所有其他选项时也会遇到同样的问题，而且我们在迁移到PHP7时仍然要重做许多事情包括摆脱runkit。但是以后会更 多。

• 兼容性。主要问题是不完全兼容PHP5.5(参考此处) ，并且不兼容现有的扩展(许多PHP5.5的)。这些所有的不兼容性导致了这个项目的明显缺点: HHVM 不是被大社区开发的，相反只是Facebook的一个分支。在这种情况下公司很容易不参考社区就修改内部规则和标准，而且大量的代码包含其中。换句话说， 他们关起门来利用自己的资源解决了问题。因此，为了解决相似的问题，一个公司需要有Facebook一样的资源不仅投入最初的实现同样要投入后续支持。这 个提议不仅有风险而且可能开销很大，所以我们决定拒绝它。

• 潜力。尽管Facebook是一个大公司而且拥有无数顶尖程序员，我们仍然怀疑他们的HHVM开发者比整个PHP社区更强。我们猜想PHP的类似于HHVM的东西会很快出现，而前者将慢慢淡出我们的视野。

让我们耐心等待PHP7。

切换到新版本的PHP7解释器是一个重要和艰难的过程，我们准备建立一个精确的计划。这个计划包括三个阶段:

• 修改PHP构建/部署的基础设施和为大量的扩展调整现有的code

• 改变基础设施和测试环境

• 修改PHP应用程序的代码。

我们稍后会给出这些这些阶段的细节。

引擎和扩展的变化

在Badoo中， 我们有积极的支持和更新的PHP分支，我们在PHP7正式版release之前我们就已经开始切换到php7了. 所以我们不得 不在我们的代码树经常整合（rebase）PHP7上游的代码，以便它来更新每个候选发布版。我们每天在工作中所用的补丁和自定义的code都需要在两个 版本之间进行移植。

下载和构建依赖库、扩展程序、还包括PHP 5.5和7.0的构建这些过程都是自动化的完成的。这不仅简化了我们目前的工作，也预示着未来：在版本7.1出来时， 也许这一切（解析引擎和扩展等等）都已经准备到位了；

如上所述，我们将注意力转向扩展。我们提供超过70种扩展，已经比基于我们产品改写的开源产品的半数还要多。

为了尽快能够切换到它们，我们已经决定开始同时进展两件事情。第一个是逐一重写各个关键扩展，包括blitz模板引擎，共享内存/APCu中的数据 缓存，pinba数据分析采集器，以及其他内部服务的自定义扩展（总的来说，我们已经通过自己的力量完成大概20种扩展的重写了）。

第二个是积极的清理仅仅在架构中那些非关键部分使用的扩展，让整个架构更加简洁。我们已经迅速清理了11种扩展，都是那些无足轻重的！

另外，我们也同那些维护主要开放扩展的作者，一起积极地讨论PHP7的兼容性（特别感谢xdebug的开发者Derick Rethans）。

我们迟点将进入更详细的关于移植PHP7扩展的技术细节。

开发者已经对PHP7中的内部API做了大量修改，意味着我们可以修改大量的扩展代码了。

下面是几个最重要的变更：

• zval * -> zval。在早期的版本中，zval一直为新变量来分配内存，但是现在引入了栈。

• char * -> zend_string。PHP7的引擎使用了更先进的字符串缓存机制。理由是，当字符串与自身的长度同时存储时，新的引擎可以将普通字符串完整的转换为zend-string格式。

• 数组API的改变。zend_string作为key来使用，同时基于双向链表的数组实现方法也被替代为普通的数组，需要强调的是，数组占用一个大的文件块，而不是很多小的空间。

所有这些都可以从根本上减少小型内存分配的数量，结果是，提高PHP引擎2%的速度。

（编辑：济南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!