与 mvc/oop 相比，Spaghetti php 代码的性能和可扩展性？答案

【问题标题】：Spaghetti php code performance and scalability compared to mvc/oop?与 mvc/oop 相比，Spaghetti php 代码的性能和可扩展性？
【发布时间】：2011-05-15 22:20:43
【问题描述】：

我有一个包含大约 50-55 个代码文件的 php 应用程序。代码量最大的文件大约有 1200 行代码（包括空格、制表符和多个换行符...），其余代码文件相对较小。

几乎每个文件中的应用程序代码都是 html、sql 和 php（你称之为意大利面条）的混合体，除了少数纯 php 包含文件的文件......例如包含所需函数的文件在许多其他地方。

我一直在考虑将这个应用程序重构为 mvc 类型的架构是否是个好主意。

现在我知道 mvc 应用程序提供了许多优点，例如易于维护、重用和易于进一步开发等，但可伸缩性和性能呢？特别是在这种情况下？

我的假设是，由于这是一个小型应用程序（我相信如此，你认为它足够小吗？），我不认为维护或添加更多功能（最多）不会有困难只是可能意味着在现有文件中添加一些内容，或者说最多添加 5-10 个新文件。

所以我认为我不应该仅仅为了维护而转换为 mvc。

据我了解，您可以将 mvc 的每个组件放在单独的服务器上以分散负载，以便让不同的服务器为 html、数据库和逻辑提供服务，并进一步进行其他优化/缓存以提高效率mvc 应用程序规模和性能。

我认为即使在一个小型意大利面条应用程序中，我们不能为 html、数据库等设置不同的服务器，但我们可以通过在 Web 服务器、数据库服务器等前面安装负载平衡器来轻松扩展而不会降低性能。（假设它涉及一台服务器不够用的情况）

更重要的是它自己的意大利面条代码应该比 mvc 执行得更好，因为它没有任何开销，例如需要包含或文件或从属于 mvc 不同组件的文件夹下的文件调用函数。

那么，考虑到所有这些因素，您真的认为将一个相对较小的意大利面条式应用程序重构为 mvc 以提高可扩展性和性能是否有用？

请不要告诉我重构将来会有用（我知道这会有所帮助，并且会考虑我们是否真的需要向现有代码库添加更多代码）但请给我一个明确的答案

1)我真的需要将此应用程序转换为 mvc 架构以获得可扩展性和性能吗？

2) 像这样的意大利面条式应用程序是否可以扩展并执行每天至少 100 万个请求，其中一半发生在某个高峰时间？

【问题讨论】：

常用框架实际实现的称为“PMVC”，它不允许将组件分布到不同的服务器上。此外，您应该首先将代码库从意大利面条（全局范围）代码转换为适当的过程结构（这是不同的）。将 SQL 处理从输出和处理逻辑中分离出来，然后再尝试将假设的模式硬塞到它上面。
嗯...可能不是不同的服务器，但我无法理解您的其余信息...我不像您那样是技术大师 :)
优化 PHP 的性能毫无意义。当它真正成为一个问题时，一些简单的缓存将比您在 PHP 级别上所做的任何优化产生无限多的效果。您唯一应该担心的（直到您达到 Facebook 或 Twitter 的规模）是您的代码的可维护性。安全性、稳定性和易于调试都比性能更重要，而所有这些都与代码的可维护性密切相关。

标签： php performance architecture coding-style scalability

【解决方案1】：

不，您不必进行转换，因为在无限预算的情况下，任何应用程序都会无限扩展。只需添加更多服务器。问题是，你有无限的预算吗？如果您没有无限的预算，请找出更便宜的方法：添加更多硬件或优化代码。

所以真正的答案是：也许。

我们无法告诉您应用程序需要什么才能达到您的可扩展性目标。我们不知道它的作用，您也没有为所需的性能提供硬性限制。例如，一个请求需要多长时间才能得到服务？运行ab 或围攻并衡量您的现状。在您的代码上运行分析器并识别瓶颈。找出您是否受 IO、CPU 或 RAM 限制。你在使用操作码缓存吗？把你所有的发现对成本做出有根据的猜测。然后决定如何优化。

总有一天，减少几微秒所需的工作量比简单地添加更好或更多的硬件要高。在实践中，您可能会使用混合策略来找到满足您需求的最具可扩展性且经济实惠的解决方案。

请注意，将一大团泥浆重构为原始的 OOP 应用程序并不一定意味着它之后会运行得更快。事实上，耦合越松散，间接性越多，层数越多，应用程序可能会变得越慢。这是为了更好的可维护性而做出的权衡。可维护性也可以节省成本。这将减少您交付新功能的时间。

【讨论】：

【解决方案2】：

据我了解，您可以将 mvc 的每个组件放在单独的服务器上以分散负载

我自己从来没有听说过——但我来自一个 .Net 世界，在这个世界里，无论如何你都可以在同一台服务器上运行所有托管代码（这不像在 Java 世界中，你经常有一个单独的“应用程序”服务器和“Web”服务器）。

您可能会迁移到 MVC（正如您所提到的）的主要原因是为了管理代码的好处：关注点分离、重用等；不是性能。

理论上，您可以使用 Java 或 .Net 等基于对象/组件的技术来做到这一点，其中组件相互通信 - 但在过程代码中？我不这么认为！

那么，考虑到所有这些因素，您真的认为将一个相对较小的意大利面条式应用程序重构为 mvc 以提高可伸缩性和性能是否有用？

否 - 假设您指的是可扩展性和性能，您指的是系统的运行时质量，我相信这就是您的意思。

如果您将可扩展性和性能纯粹放在开发环境中（人们编码 - 他们在系统上工作的速度和容易程度，您可以轻松地将开发人员添加到项目中），那么答案将是 是的。

2) 像这样的意大利面条式应用程序是否可以扩展并执行每天至少 100 万个请求，其中一半发生在某个高峰时间？

没有什么是不可能的 - 我喜欢 Gordons cmets 沿着这些思路 - 但我相信你会同意，这可能不是你可以站在的最佳位置。

【讨论】：

【解决方案3】：

是的
没有

50+ 个文件并不小。意大利面条式代码不可维护且效率极低，因此与适当的框架相比没有性能优势。最后，一个好的框架会提供经过精心设计、经过良好测试且不断更新的插件来完成最常见的任务，从而减少您必须自己编写和维护的代码量。

早在 1995 年，高流量的网站就运行着乱七八糟的意大利面条代码。今天，您甚至不应该考虑在意大利面条代码上运行一个高流量的网站（或任何类型的网站！）。

【讨论】：