mvc/oopと比較して、スパゲッティのPHPコードのパフォーマンスとスケーラビリティ？

Question

私は約50-55のコードファイルを持つPHPアプリケーションを持っています。コードの最大量を持つファイルには、約1200行のコード（スペース、タブ、複数の改行が含まれています...）があり、残りのコードファイルはこれよりも比較的小さくなっています。

ほとんどすべてのファイルのアプリケーションコードは、純粋なPHPインクルードファイルであるいくつかのファイルを除いて、html、sql、およびphp（あなたがスパゲッティと呼ぶもの）の組み合わせです....たとえば、他の多くの場所で必要でした。

私は、このアプリケーションをmvcタイプのアーキテクチャにリファクタリングすることをお勧めします。

mvcアプリケーションでは、メンテナンスの容易性、再利用性、開発の容易さなどの利点がありますが、スケーラビリティとパフォーマンスについては特にこの場合はどうでしょうか？

私の仮定は、これは小さなアプリケーション（私はそう信じて、あなたはそれが十分に小さいだと思いますか？）であることから、私はメンテナンスに苦労したり（最大で）いくつかのより多くの機能を追加すること想像していないということですこれは既存のファイルにいくつかの追加を意味するかもしれないし、おそらく最大5-10個の新しいファイルの追加を意味するかもしれない。

私はメンテナンスのためだけにmvcに変換するべきではないと思っています。

mvcの各コンポーネントを別々のサーバーに置いて、別のサーバーにhtml、データベース、ロジックを提供するように負荷を分散させ、その他の最適化やキャッシングを追加してhichを作成することができます。 mvcアプリケーション規模で実行します。

私はそれが来ると仮定すると（小さなスパゲッティアプリケーションで、我々はなど、HTML、我々は簡単にWebサーバーの前にロードバランサを持つことにより、性能を低下させることなく拡張することができ、データベースなど、databaeサーバの異なるサーバーを持つことができないにもかかわらず、だと思います

これ以上のことで、スパゲッティコードはmvcよりも優れた性能を発揮します。インクルードやファイルの要求やフォルダの下に置かれたファイルからの関数呼び出しなどのオーバーヘッドはありません。 mvcの別のコンポーネントに属しています。

これらのことすべてを考慮すると、スケーラビリティとパフォーマンスのためにmvcに比較的小さなスパゲッティアプリケーションをリファクタリングすると便利だと思いますか？

リファクタリングが将来的には有用であるとは言わないでください（既存のコードベースにもっと多くのコードを追加する必要があるかどうかを判断するのに役立ちます）。

1）スケーラビリティとパフォーマンスのために、このアプリケーションをmvcアーキテクチャに変換する必要がありますか？

2）このようなスパゲッティアプリケーションは、1日に最低100万回のリクエストを実行し、ピーク時にはその半数を実行できますか？

Answer 1

限り私はあなたがロード

を広めるために別のサーバー上で、MVCの各コンポーネントを置くことを理解して、私はそれを自分自身を聞いたことがない - が、私はから来ます。とにかく同じサーバー上ですべてのマネージドコードを実行する純粋な世界（別の「App」サーバーと「Web」サーバーを持つことが多いJavaの世界とは異なります）。

おそらくあなたがMVCに移動した主な理由は（言及したように）、コード管理のメリットである：懸念の分離、再利用など。パフォーマンスではありません。

理論的には、Javaや.NETなどのオブジェクト/コンポーネントベースのテクノロジを使用して、コンポーネント間で通信することは理論上可能ですが、手順コード内では可能ですか？私はそうは思わない！

だから、すべてこれらの事を考えると、あなたは本当にそれがスケーラビリティとパフォーマンスのためにMVCに比較的小さなスパゲッティのアプリケーションをリファクタリングするのに便利だと思いますか？

ません - あなたは私はあなたが何を意味するのかであると考えているシステムの品質を、ランタイムために参照のうえいるスケーラビリティとパフォーマンスによって仮定。

あなたは（人々がコーディング - 彼らは、システムに動作することができますどのように迅速かつ簡単に、あなたがプロジェクトに開発者を追加することができますどのように簡単に）純粋に開発のコンテキストにスケーラビリティとパフォーマンスを置くならば、答えははいだろう。

2）このスケールのようなスパゲッティ・アプリケーションとは、いくつかのピーク時に発生その日半100万のリクエストの少なくとも最低を実行することはできますか？不可能

ナッシング - 私はそれらの線に沿ってゴードンズコメントを愛する - しかし、私はあなたが同意するだろうと確信しているとして、それはおそらくあなたが上にあることができる最高の立場ではありません。

Answer 2

無制限の予算では、アプリケーションが無限に拡大するため、変換する必要はありません。サーバーを追加するだけです。問題は、あなたは無限の予算を持っていますか？予算が無限にある場合は、ハードウェアを追加したり、コードを最適化すれば安いものを見つけることができます。

実際の答えは多分：多分。

アプリケーションがスケーラビリティの目標を達成するために必要なことはわかりません。私たちはそれが何をしているのかわからないし、あなたが望むパフォーマンスに厳しい制限を設けていない。たとえば、リクエストが配信されるまでにどれくらいの時間がかかりますか？ abまたはSiegeを実行して、ステータスクオを測定します。コードでプロファイラを実行し、ボトルネックを特定します。あなたがIO、CPU、RAMのいずれであるかを調べる。 Opcodeキャッシュを使用していますか？すべての調査結果を踏襲し、コストについての知識を熟知してください。次に最適化する方法を決めます。

いくつかのマイクロ秒を流すのに必要な労力は、単により良いハードウェアを追加するよりも高いでしょう。実際には、混合戦略を使用して、ニーズに応じて最も拡張性と手頃な価格のソリューションを見つけることができます。

大きな泥のボールを元のOOPアプリケーションにリファクタリングしても、それ以降は高速に実行されるわけではありません。実際には、より疎結合されていれば、より間接的に、より多くのレイヤーは、アプリケーションが遅くなる可能性が高くなります。より良い保守性のためにはトレードオフです。保守性もコスト削減策です。新しい機能を提供するために時間を節約します。

Answer 3

1. はい
2. ん

50+のファイルは小さくはありません。スパゲッティコードは維持不能で非常に非効率的なので、適切なフレームワークに比べてパフォーマンス上の利点はありません。最後に、優れたフレームワークはよく設計された、よくテストされた、常に更新されるプラグインを提供して、一般的なタスクを達成し、自分で作成して保守しなければならないコードの量を減らします。

1995年にトラフィックの多いサイトでスパゲッティコードが混乱していました。今日、スパゲッティコードでトラフィックの多いサイト（またはあらゆる種類のサイト）を実行することについて考えるべきではありません。