1

我正在调试一个在显示博客文章列表时间歇性崩溃（500 错误）的 codeigniter 应用程序。

崩溃发生在 20-30% 的页面重新加载 - 并且似乎与服务器配置错误的内存问题有关。

首先print_r($array); exit;，我通过在发送到视图页面的每个数组下方执行控制器如果您只是输出数组（不通过视图）就没有问题——永远不会超时。

所以我不认为查询逻辑有问题。当页面正确加载时，CI 的分析器也会显示查询时间 <.001（当它崩溃时，我会收到 500 错误并且无法读取分析器的信息）。

接下来我转到print_r视图的 HTML，其中包含控制器发送的数组的循环。这就是偶尔会导致 500 错误的瓶颈所在。

该应用程序的设计方式是，单个视图处理控制器发送的所有数组，并构建一个带有最终输出的 HTML 页面。

正因为如此，视图有很多 PHP 逻辑。在运行 foreach 循环、对 post 参数的条件测试、嵌套的 foreach 循环等之前进行若干数组拆分以插入广告单元。

它非常复杂但完全可读。但是我想知道是不是逻辑太多，这个逻辑的负载是否应该分成更小的片段（多个视图），然后合并成一个最终的 HTML 字符串。

视图有

  • 30-50 if / elseif, 部分嵌套
  • 6-7 foreach，一些嵌套
  • 5array_splice众多empty且isset

你对这个问题怎么看？您通常会避免逻辑重的视图吗？有什么建议吗？

请注意，我不是为了网页设计师等而在其他 SO 讨论中询问“清理”视图。我的观点是这种结构是否会导致我的超时以及潜在的解决方案是什么。

4

3 回答 3

1

你对这个问题怎么看？

这是您指出的瓶颈。现在，如果它是 500（超时），则视图性能是不可接受的。如果要变得可用，则需要对其进行修复。

你通常会避免逻辑繁重的视图吗

总是。这就是 MVC 模式的设计目的。尽可能多地为您的控制器保留逻辑，视图应该只是演示。

似乎太多的东西试图放在一种观点中。如果您想发布一些代码，则更容易就需要查看的内容提出建议。对我来说最大的罪魁祸首是conditionals testing for post parameters。我认为这几乎肯定属于您的控制器。这些帖子参数是做什么用的？

如果 post 参数规定了输出类型，那么将其分成不同的视图会更干净，而不是在一个超级视图中处理多种不同的输出类型。

于 2012-05-21T14:31:55.123 回答
1

首先，这不是模板代码可读性的问题——复杂性和错误的存在之间有很强的相关性。圈复杂度是衡量复杂度的一种方法；根据您发布的内容，此模板的圈复杂度至少为 60。在我们所有的项目中，我的目标是圈复杂度 < 8，当我们达到 12 时会感到恐慌。

如果您的视图代码包含错误，我不会感到惊讶 - 不仅仅是超时的事情，而是通过逻辑树的一些奇怪的路线，您无法通过查看代码来完全描绘。

Williams 模板库为您提供了几种工具来执行此操作 - 例如，您可以定义备用视图来处理“如果问题，像这样渲染，如果像那样渲染”逻辑。您还可以在此处使用区域为您带来好处。

有一个假设是因为视图处理用户界面，所以它们不那么重要——但这根本不是真的。

因此，让我们假设您将视图重构为更简单的结构。这会影响处理器负载吗？嗯 - 呃 - 取决于。

通常，“可维护性”和“性能”必须相互权衡。典型的例子是汇编代码与解释语言——对大多数人来说，汇编很难维护，而解释脚本语言更容易处理；另一方面，毫无疑问哪个更快。

在您的情况下，我认为代码总量会增加——例如，作为重构的“提取方法”会将代码量增加几行——但它应该更容易缓存。也应该更容易准确地确定错误发生的位置。

于 2012-05-21T15:14:09.463 回答
1

首先，我首先检查 php 设置中的执行时间限制。您描述的情况看起来很像那个问题：有时脚本设法及时到达那里，有时却没有。) 更多关于这里。

其次，是的，你应该避免逻辑重的观点。老实说，我不知道如何在 CodeIgniter 中做到这一点，但在 Zend Framework 中有所谓的视图助手，可用于将视图相关（但很重）的逻辑与模板分开。

最后，您是否已经使用XDebug或其他类似工具分析了您的脚本？

更新：当“后参数的条件测试”舒适地坐在视图中（并且只是抵制所有试图移入控制器的尝试）的情况下......至少可以说很有趣。对不起，那么使用 MVC 框架有什么意义呢？

于 2012-05-21T14:33:41.973 回答