介绍

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

图片 1

下面我会详细的介绍下我们是如何把应用前移动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引用测试框架(当然,也是开源的),并且在整个过程中节省了上百万美元。

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

系列笔记:Modern PHP 笔记:语言特性Modern PHP 笔记:良好实践Modern 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应用程序的代码。

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

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

可选:

引擎和扩展的变化

在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%的速度。

我们能够注意到,所有这些修改都至少需要改变所有的扩展(即使不是完全重写)。虽然我们可以依赖内置扩展的作者进行必要的修改,我们也当然有责任自己修改他们,虽然工作量很大。由于内部API的修改,使得只修改一些代码段变得简单。

不幸的是,引入使代码执行速度提升的垃圾回收机制让引擎变得更加复杂并且变得更加难以定位问题。涉及到OpCache的问题。在缓存刷新期间,当可用于别的进程的已缓存的文件字节码在此时损坏,就会导致崩溃。这就是它从外部看起来的样子(zend_string):使用方法名或者常量突然崩溃并且垃圾就会出现。

鉴于我们使用了大量的内部扩展,其中许多处理都是专门针对字符串的,我们怀疑这个问题与如何使用字符串在内部扩展有关。我们写了大量的测试,并进行了大量的实验,但没有得到我们预期的结果。最后,我们从PHP引擎开发人员 Dmitri
Stogov 那里寻求了帮助。
他的第一个问题是“你有没有清除缓存?”我们解释说,事实上,我们每一次都在清除缓存。在这一点上,我们意识到这个问题并不在我们这里,而是opcache。我们很快就转载了这一案例,这有助于我们在几天内回复并解决这个问题。在7.0.4版本,这个修复没有出来,就不可能使php7进入稳定产品。

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
blogorPHP
devs
benchmarks)。新的PHP7体系架构将会让JIT的实现变得简单。

  • 共享服务器
  • 虚拟私有服务器VPS
  • 专用服务器
  • PaaS

更改测试基础设施

我们为我们在Badoo上做测试感到特别骄傲。我们部署服务器的PHP代码到产品环境,每天两次,每次部署包含20-50份任务量(我们使用功能分支Git和自动化紧JIRA集成版本)。鉴于这种时间表和任务量,我们没有办法不选择自动测试。目前,我们大约有6万个单元测试,约50%的覆盖率,其运行在云上,平均2-3分钟(参见我们的文章了解更多)。除了单元测试,我们使用更高级别的自动测试,集成和系统测试,并为网页做了Selenium测试,为手机客户端做了Calabash测试。作为一个整体,这使我们能够迅速达成与结论有关的代码,每个具体版本的质量,并应用相应的解决方案。

切换到新版本的解释器是一个充满潜在问题的重大变化,所以所有测试工作都是极其重要的。为了弄清我们到底做了什么,以及我们如何设法做到这一点,让我们来看看近几年测试开发在Badoo上是如何演变的。

通常,当我们开始考虑实施产品测试(或在某些情况下,已经开始实施的话)时,在测试过程中我们会发现他们的代码“并没有达到测试阶段”。出于这个原因,在大多数情况下,开发者在写代码时要牢记,代码的可测试性是很重要的。架构师应允许用单元测试去取代调用和外部依赖对象,以便代码测试能与外部环境相隔离。当然,毫无疑问这是一个备受憎恨的要求,很多程序员认为写“可测试性”的代码是完全不可接受的。他们认为,这些限制完全不顾“优秀代码”的标准而且通常不会取得成功。你能想象到,大量不按规则编写的代码,导致测试为了等“一个更好的时机”被延迟,或者通过运行小型测试来满足并且在测试结果被推迟,或实验者为了使自己运行的小测试能够通过,只做了能够通过的那部分(也就是指测试没有产生预期的结果)。
我并不是说我们公司是一个例外,从一开始,我们的项目也未执行测试。因为依然有几行代码在生产过程中正常运作,带来效益,所以正如文献中建议的,如果只是为了运行测试重写代码将是一件愚蠢的事情。那将占用太长的时间,花费太多。

幸运的是我们有一个很棒的工具来解决“未测试代码”的大问题——runkit。当脚本在运行时,这个
PHP
扩展允许你对方法、类及函数进行增、删、改的操作。此工具还有很多其它的功能但我们这里用不到它们。从
2005 年到 2008 年这个工具由 Sara Goleman(就职于
Facebook,有趣的是他在做 HHVM 方向的工作)开发和支持了多年。从 2008
年至今则由 Dmitri Zenovich (带领 Begun 和 Mail.ru
的测试部门)进行维护。我们也对这个项目做了些许贡献。

同时,runkit
是一个非常危险的扩展,它允许你在使用它的脚本在运行的时候对常量、函数及类进行修改。就像是一个允许你在飞行中重建飞机的工具。runkit
有直达 PHP “心脏”的权力,一个小错误或缺陷就能让一切毁掉,导致 PHP
失败或者你要用很多时间来查找内存泄漏或做一些底层的调试。尽管如此,这个工具对于我们的测试还是必要的:不需要做大的重构来完成项目测试只能在程序运行的时候改变代码来实现。

但是在切换到PHP7的时候发现runkit带来了很大麻烦,因为它并不支持新的版本。我们当然也可以在新版本中添加支持,但是从长远考虑,这看起来并不是最可靠的解决途径。因此我们选择了其他方法。

最适合的方法之一就是从runkit迁移到uopz。后者也是PHP的扩展,有着(与runkit)类似的功能性,于2014年正式推出。我在Wamba的同事建议使用uopz,它将有很好的速度体验。顺便说一下uopz的维护者就是Joe
Watkins(First Beat
Media公司,英国)。不幸的是我们迁移到uopz的测试程序无论怎样都无法成功运行。在某些地方总会发生致命的错误,出现在段错误中。我们提交了一些报告,但很遗憾他们并没有动作(e.g.
)。为了解决这种困境而重写测试程序的付出将会非常高昂,即使重写了也很容易再次暴露出问题。

鉴于我们不得不重写大量的代码,而且还要依赖于runkit和uopz这种不知道有没有问题的项目。很明显,我们有了结论:我们应该重写我们的代码,而且要尽可能独立。我们也承诺将尽一切可能来避免今后发生类似的问题,即使我们最终切换到HHVM或任何类似的产品。最终我们做出来了自己的框架。
我们的系统名为“SoftMocks”,“soft”意思是纯php实现,未使用扩展。该项目目前是一个开源的php库。
SoftMocks不跟PHP引擎绑定,它是在运行中动态重写代码,功能类似于Go语言的AOP!框架。
以下功能在我们的代码里已经测试过:

  1. override类方法
  2. 覆盖函数执行结果
  3. 更改全局常量或类常量的值
  4. 类新增方法

所有这些东西都是用runkit实现的。动态修改代码使项目临时变更有了可能性。

我们没有更多篇幅来讨论关于SoftMocks的细节,但我们计划写一篇关于这个主题的文章。
这里我们给出一些关键点:

  • 通过重写中间函数来适配原有的用户代码。因此所有的包含操作将自动被中间函数重写。
  • 在每一个用户定义的方法内都增加了是否有重写的检查。如果存在重写,相应的重写代码就会被执行。
    原来直接函数调用的方式将被通过中间函数调用的方式所替换;这样内嵌函数和用户自定义函数都能被执行到。
  • 对中间函数的动态调用将覆盖代码中变量的访问权限

SoftMocks 可以和 Nikita Popov’s
的 PHP-Parser 配合:
这个库不是很快(解析速度大概比token_get_all
慢15倍),但他的接口让你绕过语法解析树,并且包含了一个方便的API
用来处理不确定的语法结构。

现在让我们回到本文主题:切换到PHP 7.0版本。
 当我们通过SoftMocks把整个项切换过来后,我们依然有1000多个测试需要手动处理。你可以说这还不算太差的结果,和我们在开始时提到的60000个测试相比的话。
和runkit相比,测试速度没有下降,所以SoftMocks并没有性能问题。
为了公平起见,我们认为uopz 明显的快很多。

尽管PHP7包含了许多新功能,但是仍然存在一些与老版本兼容的问题。首要的解决办法是阅读官方的移植文档,之后我们会马上明白如果不去修改现有代码,我们将会面对的不仅仅是在生产环境中遇到致命的未知错误并且由于升级后代码的改变,我们无法在日志中查找到任何信息。这将会导致程序无法正常运行。

Badoo中有许多PHP代码仓库,其中最大的有超过2百万行代码。此外,我们还使用PHP实现了很多功能,从网站业务逻辑到手机应用后段再到集成测试和代码部署。就目前来说,我们的情况很复杂,毕竟Badoo有很长的历史,我们使用它已经快十年了,最不幸的是仍然有采用PHP4的环境在运行。在Badoo中,我们不推荐用‘just
stare at it long
enough’的方式来发现问题。一套所谓的’Brazilian’系统将代码部署在生产环境,你需要等待直到它发生错误,这很容易引发大面积用户在使用中遇到业务上的错误,使其不明原因。综上所诉,我们开始寻找一种方法能自动发现不兼容的地方。

最初,我们试图用IDE的,这是开发者中很受欢迎,但不幸的是,他们要么不支持PHP7的语法和特征,要么没有函数可以在代码中找到所有的明显的危险的地方,发现所有明显危险的地方。进行了一些研究(如谷歌搜索)后,我们决定尝试php7mar工具,它是用PHP实现一个静态代码分析仪。这PHP7工具使用起来非常简单,很快工程,并为您提供了一个文本文件。当然,它不是万能的;
找特别是精心隐藏的问题点。尽管如此,该实用程序帮助我们铲除约
90%的问题,大大加快和简化了准备 PHP7 的代码的过程。

对我们来说,最常遇到的和潜在危险的问题是以下内容:

  • 在func_get_arg()以及func_get_args的行为变化()。在PHP的第5版本中,这些功能中的传输的时刻返回参数值,但在七个版本发生这种情况的时刻时func_get_args()被调用。换句话说,如果函数内func_get_args前参数变量的变化()被调用,则该代码的行为可以由五个版本不同。同样的事情发生时,应用程序的业务逻辑坏了,但并没有什么在日志中。
  • 间接访问对象变量,属性和方法。并再次,危险在于,该行为可以更改“静默”。对于那些寻找更多的信息,版本间的差异进行了详细的描述在这里。

     

  • 使用保留类名。在PHP7,可以不再使用布尔,整型,浮点,字符串,空,真假类名称。,是的,我们有一个空的类。它的缺席实际上使事情变得更容易,但因为它常常导致错误。

     

  • 使用引用许多潜在的问题的foreach结构被发现了。由于我们试图早不改变迭代数组中的foreach或虽在其内部指针数,几乎所有的人都表现在版本5和7相同。

剩余的不兼容性的情况下也很少遇到了 (像 ‘e’
修饰符在正则表达式),或他们固定的一个简单的替换
(例如,现在所有构造函数应该被命名为
__construct()。类名称不允许使用)。
但是,我们即使在开始修复代码之前,我们很担心,一些开发商做一些必要的兼容性变化,其他人会继续写不符合
PHP7 的代码。为了解决这一问题,我们把 pre-receive 钩在已更改的文件
(换句话说,确保语法匹配 PHP7) 上执行 php7-l 在每一个 git
存储库中。这并不能保证不会有任何兼容性问题,但它不会清除主机问题。在其他情况下,开发人员只是不得不变得更加专注。除此之外,我们开始在
PHP7 上运行的测试整个集并与 PHP5 的结果进行了比较。

此外,开发者不允许使用任何PHP7的新功能,例如,我们没有禁止老版本的预接收钩子
php5
-l。这允许我们让代码兼容PHP5和PHP7。为什么这个很重要?因为除了php代码的问题之外,还有PHP7极其自身扩展的一些潜在的问题(这些都可以证实)。并且不幸的是,不是所有的问题都可以在测试环境中重现出来;有一些我们只在产品的大负载时才见过。

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

目标:安装Web服务器,以便接收HTTP请求;设置并管理一组PHP进程,处理PHP请求,进程可以与web服务器通信。

实践出真知

很明显我们需要一种简单快速的方法在任何数量以及类型的服务器上切换php版本。要启用的话,所有指向CLI-interpreter的代码路径都替换成了
/local/php,相应的,是/local/php5或者/local/php7。这样的话,要在服务器上改变php版本,需要改变链接(为cli脚本操作设置原子操作是很重要的),停止php5-fpm,然后启动php7-fpm。在nginx中,我们使用不同的端口为php-fpm和启动php5-fpm,php7-fom设置两个不同的upstream,但我们不喜欢复杂的nginx配置。

在执行完以上的清单后,我们接着在预发布环境运行Selenium
测试,这个阶段暴露更多我们早期没注意到的问题。这些问题涉及到PHP代码(比如,我们不再使用过期全局变量$HTTP_RAW_POST_DATA,取而代之是
file_get_contents(“php://input”))以及扩展(这里存在各种不同类型的段错误)。
修复完早期发现的问题和重写单元测试(这个过程中我们也发现若干隐藏在解析器的BUG比如这里)后,进入到我们称为“隔离”发布阶段。这个阶段我们在一定数量的服务器上运行新版PHP。一开始我们在每个主要PHP集群(Web后台,移动APP后台,云平台)上只启动一个服务,然后在没有错误出现情况下,一点一点增加服务数量。云平台是第一个完全切换到PHP7的大集群,因为这个集群没有php-fpm需求。
fpm 集群必须等到我们找到或者Dmitri
Stogov修复了OpCache问题。之后,我们也会将fpm集群切换到PHP7。

现在看下结果,简单的说,他们是非常出色的。在这里,你能看到响应时间图,包括内存消耗和我们的最大的集群(包括263服务器)的处理器的使用情况,以及在
Prague 数据中心的移动应用后端的使用。

HHVM的试验

一般选择nginx。因为apache为每个PHP请求派生一个子进程,比较耗资源。

响应时间分布:

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

然后作者展示了一个登陆VPS的例子:需要ssh登陆、创建非根用户管理web服务器,不要使用root

图片 2

另一方面,HHVM 被证实有一些严重的缺点:

因为使用密码登陆有漏洞,尽量使用SSH密钥对认证。SSH密钥对登录流程如下:

RUsage (CPU 时间):

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

使用SSH密钥对认证方式登录远程设备时,远程设备随机创建一个消息,使用公钥加密,然后把密文发给本地设备,本地设备收到密文后使用私钥解密,然后把解密后的消息发给远程服务器。远程服务器验证解密后的消息之后,再赋予你访问服务器的权限。

图片 3

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

适合在一台电脑中登录远程,多台不适合。

内存使用:

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

 // 生成私钥、公钥文件 ~/.ssh/id_rsa 和 ~/.ssh/id_rsa.pub ssh-keygen // 复制公钥到服务器 scp ~/.ssh/id_rsa.pub deploy@100.10.3.1: // 末尾要加':',会复制到家目录 // deploy用户登录服务器 // 确认有~/.ssh目录,没有则创建目录和文件,文件存储允许登录的公钥 touch ~/.ssh/authorized_keys cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys // 修改几个目录和文件的权限,只让deploy用户访问 chown -R deploy:deploy ~/.ssh chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys

图片 4

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

禁用密码,禁止根用户登录

这样最安全

 // /etc/ssh/sshd_config PassWordAuthentication 设置为no PermitRootLogin 设置为no

PHP FastCGI Process Manager(PHP
FastCGI进程管理器)。它会创建一个主进程,控制何时以及如何把HTTP请求转发给一个或多个子进程处理。PHP-FPM还需控制何时创建、销毁PHP子进程。

CPU 加载 (%)-移动后台集群

让我们耐心等待PHP7。

全局配置

CentOS主配置文件:/etc/php-fpm.conf建议修改默认配置:

 emergency_restart_threshold = 10 // 指定时间内,失效的PHP-FPM子进程超过这个值,让PHP-FPM主进程优雅重启 emergency_resttart_interval = 1m // 指定时间跨度

图片 5

这一切到位,处理时间减少了一半,从而提高整体响应时间约40%,由于一定量的请求处理时间是花在与数据库和守护进程通信。从逻辑上讲,我们不希望这部分加快切换到php7。除此之外,由于超线程技术,集群的整体负载下降到50%以下,进一步促进了令人印象深刻的结果。广义而言,当负载增加超过50%,HT-engines,而不是作为有用的物理引擎开始工作。但这已经是另一篇文章的主题。此外,记忆的使用,这从来没有一个瓶颈,我们,减少了大约八倍以上!最后,我们节省了机器的数量。换句话说,服务器的数量可以承受更大的负载,从而降低获取和维修设备的费用。在剩余的聚类结果相似,除云上的收益是一个更温和的(大约40%个CPU),由于opcache操作的减少。

来算算我们能节省多少费用呢?大致测算一下,一个Badoo应用服务器集群大概包含600多台服务器。如果cpu使用率减半,我们可以节省大约300台服务器。考虑服务器的硬件成本和折旧,每台大约4000美元。总的算下来我们能节省大约100万美元,另加每年10万的主机托管费。而且这还没有计算对服务云性能的提升带来的价值,这个结果很令人振奋。

另外,您是否也考虑切换到PHP 7.0版本呢?
我们很希望听听您关于此问题的观点,而且非常愿意在下面的评论中回答您的疑问。

Badoo 团队

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

配置进程池

让各个PHP-FPM进程池都以指定的操作系统用户和用户组的身份运行,每个PHP用户一个非根用户,这样查看和管理都很方便。

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

配置虚拟主机

CentOS: /etc/nginx/conf.d/example.conf

 server { listen 80; server_name example.com; index index.php; client_max_body_size 50M; error_log /home/deploy/apps/logs/example.error.log; access_log /home/deploy/apps/logs/example.access.log; root /home/deploy/apps/example.com; location / { try_files $uri $uri/ /index.php$is_args$args; } location ~ \.php { try_files $uri =404; fastcgi_split_path_info ^$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_index index.php; fastcgi_pass 127.0.0.1:9000; } }

location / {}使用try_files指令查找匹配所请求的URI文件,先查询所请求的URI文件,找不到则查询目录,也找不到会改写URL为index.php开头的,交给location ~ \.php {}处理。把请求交给9000端口处理,前面已经设置PHP-FPM监听9000端口。

  • Puppet
  • Chef
  • Ansible
  • SaltStack

一般在/etc/php5/fpm/,
命令行php运行的是另一个php.ini文件,一般在/etc/php5/cli/

我也在安装目录下lib找到了这个文件。

memory_limit = 128M

这个值可以考虑总共分配内存,和每个PHP进程占用内存,大概算出。也可以用apache
bench或seige做压测

主要是ini文件里一堆opcache开头的配置,用的时候查文档吧

 file_uploads = 1 upload_max_filesize = 10M max_file_uploads = 3

默认同时上传20个,每个2M,不很合适。

 max_execution_time = 5

PHP进程最长用时,默认30秒太长了。如果有长时间运行的任务,要在单独的职程中运行。

PHP中的exec()函数调用bash的at命令。用于派生单独的非阻塞进程,不耽误当前PHP进程。exec()要使用escapeshellarg()函数转义shell参数。比如要生成一个pdf文件,需要等待10分钟,应该单独编写一个php文件create_report.php,让这个文件运行10分钟。

 <?php exec('echo "create_report.php" | at now'); echo 'Report pending...';

create_report.php脚本在单独的后台执行,运营完毕后可以更新数据库或者通过电子邮件把报告发给收件人。

如果要派生很多后台进程,最好用专门的队列。PHPResque等。

php默认的会话处理会拖慢大型程序,因为需要把会话数据存储在硬盘。我们应该保存在内存中,使用memcached或者redis。也便于伸缩,硬盘上数据不适合增加额外服务器。

使用memcashed需要安装PECL扩展,然后更改ini

使用较少的块发送更所数据,下面是等凑够4096字节再发

 out_buffering = 4096 implict_flush = false

php会缓存应用使用的文件路径,这样每次包含或导入文件时就无需不断搜索包含路径了。这个缓存叫真实路径缓存。realpath_cache_size
= 64k

  • 让部署变得简单
  • 部署结果可预知
  • 部署可逆

capistrano运行在本地设备,通过ssh与远程服务器通信。

改变基础设施和测试环境

capistrano的工作方式

capistrano会在远程服务器中保存之前部署的应用,而且每次部署的版本放在各自的目录中。capistrano还会创建一个current/目录,通过符号连接指向当前部署的应用所在的目录。当部署应用时,capistrano会首先从git仓库获取最新代码,然后把代码放到realeases/的一个新子目录,然后把current/符号连接指向新目录。

  • Deployer
  • Magallanes
  • Rocketeer

从长远来看,测试省钱,省精力

  • 开发前:把测试工具当做项目开发的重要依赖
  • 开发中,每个功能都要编写并运行测试
  • 开发后,编写新测试,确保修补缺陷的方式是正确的

单元测试和功能测试

  • 单元测试:使用PHPUnit或者PHPSpec
  • 测试驱动开发: 编写之前写测试,再开发,然后再写测试,再开发
  • 行为驱动开发: 编写故事,描述应用的表现。
    • SpecBDD:也是单元测试,使用人类能读懂的语言。比如PHPUnit风格测试命名为testRenderTemplate(),
      等价SpecBDD命名为itRendersTheTemplate(),
      而且会使用诸如$this->shouldReturn()、$this->shouldbe()之类易于理解的辅助方法。
    • StoryBDD:类似,但是更多关注整体行为。StoryBDD用于测试产品经理的需求(要生成报告,并且电子邮件发送给用户),SpecBDD测试开发的需求(这个类方法只能接收一个数组)

术语:PHPUnit测试在一起组成测试用例(test
case),测试用例在一起组成测试组件(test
suite),PHPUnit会使用测试运行程序(test runner)运行测试组件。

一个测试用例是一个PHP类(且以Test结尾,文件名以Test.php结尾),扩展自PHPUnit_Framework_TestCase类。测试用例中有一些以test开头的公开方法,一个方法是一个测试,在方法中我们断言会发生什么事。断言可能通过也可能失败,目标是使断言都通过。

测试运行程序默认使用命令行运行程序,调用phpunit命令。

修改PHP应用程序的代码。

安装

PHPUnit用于测试,用composer安装;XDebug用于生成覆盖度信息,是PHP扩展,用包管理器安装。

紧接着,书中有一个具体的测试用例,用的时候找更详细的blog看看吧

原生提供钩子,可以集成github仓库,每次提交后,都能自动测试,并在多个版本中测试。

指的是分析应用的性能。

什么时候使用?

当遇到性能瓶颈时再使用。

  • 在开发环境:XDebug。它的结果人类读不懂,需要KCacheGrind或者WinCacheGrind形象化展示。
  • 在生产环境:XHprof,使用XHGUI展示结果。

为节省资源,配置成触发执行,具体配置略

接下来讨论的是PHP的未来。

传统的PHP解释器是Zend Engine, HHVM(Hip Hop Virtual
Machiane)由Facebook开发,目的是提高性能,HHVM先把PHP代码转换成字节码,然后缓存字节码,然后使用JIT编译器(Just
in
Time)转换并优化成x86_64机器码。这样传统的解释型语言就有了一些编译型语言的速度。JIT提供了很多底层性能优化。

HHVM和Zend Engine是等价的。相当于PHP+PHP-FPM。

HHVM配置也是用php.ini文件

推荐使用Supervisord监控,HHVM挂掉后立即重启。

他们把自己看做PHP的方言,为PHP引入了新的数据类型和结构,以及静态类型。

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

从PHP转向Hack

<?php改成<?hh

引擎和扩展的变化

类型

静态语言,通常都要编译,编译器提供类型检查和错误报告,通常更稳定。缺点是要先编译,反馈回路长。

动态语言,通常解释执行,在运行时发现错误。迭代速度快,反馈及时。缺点是,没有类型检查,缺少内在的准确性。

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

hack两者兼有

hack基本兼容PHP

查了下最新的情况,PHP7性能卓越,Hack优势不明显了,前景不明。

以上就是这本书的精华,不过瘾的话强烈推荐购买。欢迎交流

下载和构建依赖库、扩展程序、还包括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格式。

Author

发表评论

电子邮件地址不会被公开。 必填项已用*标注