在高负载项目中使用带有全堆栈框架的PHP是一个坏主意吗？

我知道PHP代码被编译成字节码，并在每次运行时（即每次页面请求时）重新执行。所以引擎应该在每个请求上重新定义所有使用的类、函数、变量等

当使用全堆栈框架（如Laravel或CakePHP）时，这也意味着在每个请求上都会反复执行相同的引导工作，如解析配置文件、注册路由、自动加载类等

这似乎是处理这些东西的非常不理想的方式。即使是缓存，无论是OPcache还是frameworkcachingsystem，也没有足够的帮助，因为脚本仍然需要执行

另一方面，基于NodeJS或Ruby等引擎的应用程序在启动时只编译和引导一次。所以我认为它们应该比PHP具有更好的可伸缩性

但是PHP非常流行，甚至Facebook也在使用它。因此，我想知道，对于一个可能会经历重载的网站来说，什么是正确的选择？将PHP与完整堆栈框架一起用于这种目的是一个坏主意吗

我知道PHP代码被编译成字节码，并在每次运行时（即每次页面请求时）重新执行。所以引擎应该在每个请求上重新定义所有使用的类、函数、变量等

从PHP5.5开始，出现了一个默认值。在此之前，可以使用APC。您还可以使用类似的方法通过JIT编译进一步提高性能（PHP7将包括类似的改进）

当使用全堆栈框架（如Laravel或CakePHP）时，这也意味着在每个请求上都会反复执行相同的引导工作，如解析配置文件、注册路由、自动加载类等

Laravel（我不能代表CakePHP）只在类被使用时加载它们——您的大多数类永远不会在一个普通请求中加载。对于使用像Symfony/Laravel这样的大型框架，大多数偏执狂都是偏执狂

这似乎是处理这些东西的非常不理想的方式。即使是缓存，无论是OPcache还是frameworkcachingsystem，也没有足够的帮助，因为脚本仍然需要执行

---

操作码缓存和框架缓存（文件、Redis等）提供了巨大的好处，而您在这里却不屑一顾。是的，每个请求都需要执行代码（尽管像Varnish这样的东西可以降低这一点），但对于任何语言和任何框架来说都是如此。

HHVM是Facebook在幕后使用的，以使其PHP具有可伸缩性。他们是项目的主要贡献者，因此项目在性能方面得到了很多关注。与我们领域中的大多数事情一样，它归结为特定的用例、需求和偏好/技能集。如果这是一个“坏主意”，那么很多非常成功的公司都采用了这个“坏主意”，并且对他们有效，那么这真的会是一个“坏主意”吗？很多FUD支持的想象并不是一种客观看待应用程序可伸缩性的方式。。。。但设计良好的PHP应用程序可以很好地扩展（我曾经开发过每秒点击数为1000次的应用程序，平均响应时间为300毫秒），而设计糟糕的Ruby或NodeJS应用程序无法很好地扩展