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の議論のように、Webデザイナーなどのためにビューを「クリーニング」することについては質問していないことに注意してください。ここでの私のポイントは、この構造が私のタイムアウトを引き起こしている可能性があるかどうか、そして潜在的な解決策は何であるかということです。

4

3 に答える 3

1

まず、テンプレートコードがどれだけ読みやすいかという問題ではありません。複雑さとバグの存在の間には強い相関関係があります。循環的複雑度は、複雑度を測定する1つの方法です。あなたが投稿したものから、このテンプレートは少なくとも60の循環的複雑度を持っています。私たちのすべてのプロジェクトで、私は<8の循環​​的複雑度を目指しており、12に達するとパニックになります。

ビューコードにバグが含まれていても驚かないでしょう。タイムアウトだけでなく、コードを見ても完全には理解できない、ロジックツリーを通る奇妙なルートです。

Williamsテンプレートライブラリには、これを行うためのいくつかのツールが用意されています。たとえば、「質問の場合はこのようにレンダリングし、ポストレンダリングの場合はこのようにレンダリングする」ロジックを処理する代替ビューを定義できます。ここでは、地域を利用して利益を得ることができます。

ビューはユーザーインターフェイスを処理するため、重要性は低いと想定されていますが、それは単に真実ではありません。

したがって、ビューをより単純な構造にリファクタリングするとします。これはプロセッサの負荷に影響しますか？まあ-ええと-依存します。

通常、「保守性」と「パフォーマンス」は互いにトレードオフする必要があります。古典的な例は、アセンブラーコードとインタープリター言語です。ほとんどの人にとって、アセンブラーは保守が困難ですが、インタープリタースクリプト言語ははるかに扱いやすいです。一方、どちらが速いかは間違いありません。

あなたの場合、コードの総量は増えると思います。たとえば、リファクタリングとしての「extract method」は、コードの量を数行増やすことになりますが、キャッシュする方が簡単なはずです。また、バグが発生した場所を正確に特定するのも簡単です。

于 2012-05-21T15:14:09.463 に答える
1

この問題についてどう思いますか？

これは、あなたがそれを特定したボトルネックです。現在、500（タイムアウト）の場合、ビューのパフォーマンスは許容できません。使用可能にするためには修正が必要です。

通常、ロジックの重いビューは避けますか

いつも。これは、MVCパターンが実行するように設計されていることです。可能な限り多くのロジックをコントローラーに保持します。ビューはプレゼンテーションのみにする必要があります。

1つのビューに入れようとしているのは多すぎるようです。いくつかのコードを投稿したい場合は、何を調べる必要があるかについて提案を行う方が簡単です。私にとって最大の犯罪者はconditionals testing for post parametersです。これはほぼ間違いなくあなたのコントローラーに属していると思います。これらの投稿パラメータは何に使用されていますか？

postパラメータが出力タ​​イプを指定する場合、1つのスーパービューで複数の異なる出力タイプを処理するのではなく、異なるビューに分割する方がクリーンです。

于 2012-05-21T14:31:55.123 に答える
1

まず、php設定で実行時間制限を確認します。あなたが説明した状況は、その問題に非常によく似ています。スクリプトが時間内に到達できる場合と、そうでない場合があります。）詳細はこちら。

第二に、はい、あなたは論理的な重い見方を避けるべきです。正直なところ、CodeIgniterでそれを行う方法はわかりませんが、Zend Frameworkには、ビュー関連の（ただし重い）ロジックをテンプレートから分離するために使用できる、いわゆるビューヘルパーがあります。

最後に、 XDebugまたは他の同様のツールを使用して、スクリプトのプロファイルを作成しましたか？

更新：「投稿パラメーターの条件付きテスト」がビュー内に心地よく座っている（そしてコントローラーに移動しようとするすべての試みに抵抗する）場合は、控えめに言っても興味深いです。申し訳ありませんが、MVCフレームワークを使用する意味は何ですか？

于 2012-05-21T14:33:41.973 に答える