事实：我们正在谈论一家小公司（5人），有许多赚钱（我们没有）的客户。我们提供了自己的软件，该软件具有针对电子商务完成的独特功能。
问题：该问题在2012年左右首次出现，并在2014年左右通过Web套接字明确了。一些客户不希望与客户进行简单的聊天，而是想要一个完整的在线eShop，在这里他们可以协商产品的价格，甚至可以与访客进行讨论。解决方案是在我们的框架中实现Web套接字，并且可以正常工作，但使用令人难以置信的资源，而没有任何横向补偿。那可能是什么？：1）我们使用应用程序范围缓存（针对对象或对象列表），并认为这是在服务器内存中完成的，因此每个请求都必须反序列化/序列化（如果有更改）对象（是CPU昂贵且耗时的时间，我计算出每个响应花费了近2毫秒的时间。此外，如果我在应用程序中运行某些内容，为什么不拥有一个数据库池，其中最常见的预处理语句仍然存在？
第一个解决方案：是一个新的PHP框架，基本上是一个C ++扩展，一切正常（几乎（如果有兴趣的人我可以分享更多））（它仅在一个项目中投入生产）。当这些对象更新时，应用程序范围缓存正在与储物柜一起使用，并且我们可以对PHP中的数据库池有一个初步的了解。此外，它还可以消除DNS查找，因为SPA应用程序将钩到WebSocket（如果可用）或AJAX（如果没有）。 （当我在这里谈论SPA时，如果您第一次访问某个URL，就像通过内部链接访问该URL一样，您将看到相同的内容）。
然后出现了PHP 7.0.2：PHP的失禁是巨大的，但是所有事情都粉碎了。实际上，我们并不是在试图产生一个框架，而是试图产生一个能够容纳该框架的应用服务器。应用服务器部分可以用更多的资源和特定的PHP版本来完成，但是我们没有资源，也不想将自己绑定到特定的PHP版本。
/ let往回移动/时刻：有一种语言，您可以使用应用程序服务器，可以共享应用程序范围的缓存对象而无需反序列化/序列化，并且还具有许多用于Web套接字的附加组件，而且更容易使用，我知道从十几岁开始（不是我的第一语言），该语言就是Java，例如Tomcat之类的应用服务器。
做出决定很困难，切换到Java需要重写我们所有的应用程序，但是将实现两个主要目标（应用程序范围缓存，数据库池）。另一方面，使用系统扩展（例如imageMagick）来了解JVM的内部工作方式并为此编写良好的代码是有局限性的。
Java的一个优点是，之后我们可以共享不带类的Java代码，而一个严重的缺点是我们不能编写更多的C ++扩展来使我们的生活更轻松+更快+更高效。但是维护一个PHP应用服务器比我最初想的要困难得多。
由于我处在十字路口，因此我对此表示感谢。
在我看来，您不满意PHP和其他框架，语言随着时间的推移而发展以及过去的工作方式在升级时会中断。我已经在JAVA以及PHP，Python和其他系统中看到了这一点。
当新的PHP破坏了您的代码时，修复所破坏的代码（花费数小时）比迁移到另一个框架或系统上更便宜。
您可能想看看的是如何安全地将已构建的应用程序拆分为较小的服务。仅仅因为您更改了语言并不意味着您必须更改持久性存储（数据库）。隔离可以安全地转换为您使用的新语言并开始迁移到新语言的服务。
其他需要考虑的事情只是重新编写了受PHP负面影响的系统方面。您还可以引入用于服务间通信的Message Queues等（PHP更改Java需要了解的对象）。如果您打算走Java路线，我强烈建议您调查Spring Boot，并尽量避免使用较大的Enterprise Application Server。
是的，您可以将apache和tomcat放在同一台服务器中，也可以将它们作为完全独立的环境（在不同的端口中使用），另一种选择是手动将apache的请求转发给tomcat（有点困难），但是对于cpanel也有easyapache您可以将其设置为使用tomcat（甚至具有自动发布选项）。 Easyapache 3与Tomcat 7一起使用，而easyapache 4与Tomcat 8.5一起使用（直到在实验模式下为止）。但是问题不在于使用相同的服务器，我们可以有更多只运行Tomcat的服务器（如今，这并不是很昂贵的选择）
这超出了我的理解。您将能够托管Java和PHP服务器吗？ G.tomcat和apache在一起？如在8080和80端口一样？还是我遗漏了所有要点？
您可能希望首先使用Java和PHP的混合环境，在Java中实现新项目，同时暂时在PHP中维护旧项目，直到需要进行更改以保证完全重写为止。
这就是我们多年来摆脱（大部分）广泛的Perl代码库的方式。
谢谢大家的回答，有些问题我认为有些问题很重要，在我自己思考之前，先阅读一下。这里的难题是，如果我试图使一种语言表现出一种非预期的行为，并且考虑到我是一家有限的公司的一部分，那么这种影响是否证明了成本（时间和挫败感）是合理的资源。我们的实验证明，可以为具有应用程序范围共享对象（不进行序列化和反序列化）的PHP构建应用服务器，并为每个具有本地websockets支持的应用（以及对PHP的C ++扩展）构建一个下降的DB池系统，但这也证明了考虑到我们的资源和PHP的性质，这很难维持（这非常不稳定）。我在一个我想将其创建为稳定替代方案之上的地方。那是Java诞生的时候。当我首先为此编写线程系统时，每个应用程序都有一个线程池，该线程具有递增的线程池，按最大最小限制和使用量递减，然后搜索该线程的其他实现，然后碰到了Tomcat的工作方式（可能是WebSphere在同样的方式，但是没有太多免费文档可供阅读）。在PHP中将其构建为C ++扩展，并附带所有随之而来的失败，我的脑子一直在思考一个问题：“值得吗？为什么不完全转向Java？”
今天，我们有了一个纯PHP框架，其影响是每个请求3到7毫秒左右，并且未记录CPU /内存使用情况。应用程序范围缓存需要根据更改进行序列化/反序列化，但是其普通文件存储在每个服务器的内存中。鉴于使用存储库文件夹通过该通道提供非UI图像的事实，这会增加影响。更重要的是，我们无法为websocket提供一个下降的解决方案（不使用荒谬的资源来完成真正简单的事情），当然，我们也没有数据库池机制。
谢谢大家的回答，即使这意味着坚持使用特定的PHP版本（目前为7.0.1），我也可能会尝试更多，如果再次失败，我将逐步将其移至Java。
Java在各个方面都更有前途。