如何正确配置Nginx+PHP
对很多人而言，配置Nginx+PHP无外乎就是搜索一篇教程，然后拷贝粘贴。听上去似乎也没什么问题，可惜实际上网络上很多资料本身年久失修，漏洞百出，如果大家不求甚解，一味的拷贝粘贴，早晚有一天会为此付出代价。
假设我们用PHP实现了一个前端控制器，或者直白点说就是统一入口：把PHP请求都发送到同一个文件上，然后在此文件里通过解析「REQUEST_URI」实现路由。
此时很多教程会教大家这样配置Nginx+PHP：
listen 80;
location / {
index index.html index.htm index.
if (!-e $request_filename) {
rewrite . /index.
location ~ \.php$ {
include fastcgi_
fastcgi_param SCRIPT_FILENAME /path$fastcgi_script_
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.
这里面有很多错误，或者说至少是坏味道的地方，大家看看能发现几个。
我们有必要先了解一下Nginx配置文件里指令的继承关系：Nginx配置文件分为好多块，常见的从外到内依次是「http」、「server」、「location」等等，缺省的继承关系是从外到内，也就是说内层块会自动获取外层块的值作为缺省值（有例外，详见参考）。
参考：UNDERSTANDING THE NGINX CONFIGURATION INHERITANCE MODEL
让我们先从「index」指令入手吧，在问题配置中它是在「location」中定义的：
location / {
index index.html index.htm index.
一旦未来需要加入新的「location」，必然会出现重复定义的「index」指令，这是因为多个「location」是平级的关系，不存在继承，此时应该在「server」里定义「index」，借助继承关系，「index」指令在所有的「location」中都能生效。
参考：Nginx Pitfalls
接下来看看「if」指令，说它是大家误解最深的Nginx指令毫不为过：
if (!-e $request_filename) {
rewrite . /index.
很多人喜欢用「if」指令做一系列的检查，不过这实际上是「try_files」指令的职责：
try_files $uri $uri/ /index.
除此以外，初学者往往会认为「if」指令是内核级的指令，但是实际上它是rewrite模块的一部分，加上Nginx配置实际上是声明式的，而非过程式的，所以当其和非rewrite模块的指令混用时，结果可能会非你所愿。
参考：IfIsEvil and How nginx “location if” works
下面看看「fastcgi_params」配置文件：
include fastcgi_
Nginx有两份fastcgi配置文件，分别是「fastcgi_params」和「fastcgi.conf」，它们没有太大的差异，唯一的区别是后者比前者多了一行「SCRIPT_FILENAME」的定义：
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_
注意：$document_root 和 $fastcgi_script_name 之间没有 /。
原本Nginx只有「fastcgi_params」，后来发现很多人在定义「SCRIPT_FILENAME」时使用了硬编码的方式，于是为了规范用法便引入了「fastcgi.conf」。
不过这样的话就产生一个疑问：为什么一定要引入一个新的配置文件，而不是修改旧的配置文件？这是因为「fastcgi_param」指令是数组型的，和普通指令相同的是：内层替换外层；和普通指令不同的是：当在同级多次使用的时候，是新增而不是替换。换句话说，如果在同级定义两次「SCRIPT_FILENAME」，那么它们都会被发送到后端，这可能会导致一些潜在的问题，为了避免此类情况，便引入了一个新的配置文件。
参考：FASTCGI_PARAMS VERSUS FASTCGI.CONF – NGINX CONFIG HISTORY
此外，我们还需要考虑一个安全问题：在PHP开启「cgi.fix_pathinfo」的情况下，PHP可能会把错误的文件类型当作PHP文件来解析。如果Nginx和PHP安装在同一台服务器上的话，那么最简单的解决方法是用「try_files」指令做一次过滤：
try_files $uri =404;
参考：Nginx文件类型错误解析漏洞
依照前面的分析，给出一份改良后的版本，是不是比开始的版本清爽了很多：
listen 80;
index index.html index.htm index.
location / {
try_files $uri $uri/ /index.
location ~ \.php$ {
try_files $uri =404;
include fastcgi.
fastcgi_pass 127.0.0.1:9000;
实际上还有一些瑕疵，主要是「try_files」和「fastcgi_split_path_info」不够兼容，虽然能够解决，但方案比较丑陋，具体就不多说了，有兴趣的可以参考问题描述。
补充：因为「location」已经做了限定，所以「fastcgi_index」其实也没有必要。
原文出处：
如何正确配置Nginx+PHPBadoo 告诉你切换到 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都需要在两个版本之间进行移植。
下载和构建依赖库、扩展程序、还包括PHP5.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进入稳定产品。
更改测试基础设施
我们为我们在Badoo上做测试感到特别骄傲。我们部署服务器的PHP代码到产品环境，每天两次，每次部署包含20-50份任务量（我们使用功能分支Git和自动化紧JIRA集成版本）。鉴于这种时间表和任务量，我们没有办法不选择自动测试。目前，我们大约有6万个单元测试，约50％的覆盖率，其运行在云上，平均2-3分钟（参见我们的 文章 了解更多）。除了单元测试，我们使用更高级别的自动测试，
集成和系统测试，并为网页做了S elenium测试，为 手机客户端做了C alabash测试 。
作为一个整体，这使我们能够迅速达成与结论有关的代码，每个具体版本的质量，并应用相应的解决方案。
切换到新版本的解释器是一个充满潜在问题的重大变化， 所以所有测试工作都是极其重要的。为了弄清我们到底做了什么，以及我们如何设法做到这一点，让我们来看看近几年测试开发在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. /krakjoe/uopz/issues/18 ）。为了解决这种困境而重写测试程序的付出将会非常高昂，即使重写了也很容易再次暴露出问题。
鉴于我们不得不重写大量的代码，而且还要依赖于runkit和uopz这种不知道有没有问题的项目。很明显,我们有了结论:我们应该重写我们的代码,而且要尽可能独立。我们也承诺将尽一切可能来避免今后发生类似的问题，即使我们最终切换到HHVM或任何类似的产品。最终我们做出来了自己的框架。
我们的系统名为“SoftMocks”，“soft”意思是纯php实现,未使用扩展。该项目目前是一个 开源的php库 。 SoftMocks不跟PHP引擎绑定，它是在运行中动态重写代码,功能类似于 Go语言的AOP!框架 。
以下功能在我们的代码里已经测试过：
override类方法
覆盖函数执行结果
更改全局常量或类常量的值
类新增方法
所有这些东西都是用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极其自身扩展的一些潜在的问题（这些都可以证实）。并且不幸的是，不是所有的问题都可以在测试环境中重现出来；有一些我们只在产品的大负载时才见过。
实践出真知
很明显我们需要一种简单快速的方法在任何数量以及类型的服务器上切换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数据中心的移动应用后端的使用。
响应时间分布：
RUsage (CPU 时间):
CPU 加载 (%)-移动后台集群
这一切到位，处理时间减少了一半，从而提高整体响应时间约40%，由于一定量的请求处理时间是花在与数据库和守护进程通信。从逻辑上讲，我们不希望这部分加快切换到php7。除此之外，由于超线程技术，集群的整体负载下降到50%以下，进一步促进了令人印象深刻的结果。广义而言，当负载增加超过50%，HT-engines，而不是作为有用的物理引擎开始工作。但这已经是另一篇文章的主题。此外，记忆的使用，这从来没有一个瓶颈，我们，减少了大约八倍以上！最后，我们节省了机器的数量。换句话说，服务器的数量可以承受更大的负载，从而降低获取和维修设备的费用。在剩余的聚类结果相似，除云上的收益是一个更温和的（大约40%个CPU），由于opcache操作的减少。
来算算我们能节省多少费用呢？大致测算一下，一个Badoo应用服务器集群大概包含600多台服务器。如果cpu使用率减半，我们可以节省大约300台服务器。考虑服务器的硬件成本和折旧， 每台 大约4000美元。总的算下来我们能节省大约100万美元，另加每年10万的主机托管费。而且这还没有计算对服务云性能的提升带来的价值，这个结果很令人振奋。
另外，您是否也考虑切换到PHP 7.0版本呢？ 我们很希望听听您关于此问题的观点，而且非常愿意在下面的评论中回答您的疑问。
Badoo 团队
最新教程周点击榜
微信扫一扫}