PHP のパフォーマンスに関する考慮事項?

https://stackoverflow.com/questions/112786

02-07-2019
|

質問

を構築しています PHP サイトですが、今のところ唯一の PHP 私は特定のページに 6 個ほどのインクルードを使用しています。(最終的にはデータベースクエリをいくつか使用することになるでしょう。)

シンプルです include() ステートメントは静的ステートメントとは対照的に、速度やスケーリングを考慮します。 HTML?サイトが行き詰まる原因にはどのようなことが考えられますか?

解決

厳密に言えば、サーバーがコードを解釈する必要がないため、ストレート HTML は常にサーバー側のアプローチよりも高速に機能します。

もっと大きな質問に答えるには、はサイトが行き詰まる原因となるさまざまな要因。コードが問題の原因となっている場合とそうでない場合について、具体的なしきい値はありません。PHP。(Yahoo のサイトの多くは PHP 駆動であるため、PHP が拡張できないとは考えないでください)。

私が気づいたことの 1 つは、最も遅い PHP 駆動のサイトには、特定のページを表示するのに必要以上のものが含まれているということです。OSCommerce (oscommerce.com) は、最も人気のある PHP ベースのショッピングカートの 1 つです。ただし、すべてのコア機能 (必要な場合に備えて) をすべてのページに含めるという悪い癖があります。したがって、「情報ボックス」を表示する必要がない場合でも、この関数はロードされます。一方で、「必要に応じてロードする」アプローチをとる PHP フレームワーク (CakePHP、Symfony、CodeIgniter など) が多数存在します。

私は次のようにアドバイスします。

特定のページに必要以上の機能を含めないでください。
基本関数を分離しておきます (可能な場合は MVC アプローチを使用します)
インクルードが入れ子になると思われる場合は、 include の代わりに require_once を使用してください (例:ページ A にはファイル C が含まれるファイル B が含まれます)。これにより、同じファイルを複数回インクルードすることが回避されます。ファイルが見つからない場合にもプロセスは停止します。したがって、トラブルシューティングのプロセスに役立ちます ;)
可能であれば、静的ページを HTML としてキャッシュします - 状況が変わらない場合に再解析する必要を避けるため

他のヒント

確かに include() は静的ページよりも遅いです。ただし、最新のシステムでは、これがボトルネックになることは、たとえあったとしても、長期間にわたってボトルネックになる可能性はほとんどありません。私の意見では、インクルードを使用してサイトの共通部分を最新の状態に保つことの利点は、わずかなパフォーマンスの低下よりも重要です (更新を忘れたために 1 つのページに異なるナビゲーションが表示されると、ユーザーエクスペリエンスが低下し、その結果、サイトに対する不快感が生じます)。サイト/会社/その他)。

キャッシュを使用しても実際には役に立ちません。コードのキャッシュは単なる include() よりも遅くなります。キャッシュのメリットが得られるのは、計算量の多い計算 (Web ページでは非常にまれです) を実行する場合、またはデータベースからデータを取得する場合のみです。

少し時期尚早な最適化に参加しているようですね。アプリケーションが構築されていない場合、パフォーマンスに関する懸念は認識しておくべきですが、主な関心事はアプリを作成することです。

インクルードは現実です。数を気にする必要はなく、コードを適切に整理することを心配してください (PEAR フォルダー構造は素晴らしいものです。私が何を言っているのかわからない場合は、Zend Framework クラスファイルの構造を見てください)。

適切な量の抽象化を使用してアプリケーションを作成することに重点を置きます。すべての DB 呼び出しを 1 つのクラスにグループ化すると、コードの重複 (KISS 原則など) が最小限に抑えられ、クエリをリファクタリングして最適化するときにそれらが集中的に配置されます。また、回帰を防ぐためにいくつかの単体テストを開始します。

アプリケーションが起動して実行されたら、何がボトルネックになるかは各アプリケーションによって異なるため、どちらが速いか優れているかを尋ねる必要はありません。多くのインクルードがあるにもかかわらず、ループが時間などを食っていることが判明する場合があります。使用 Xデバッグそしてコードのプロファイリングを行う稼働したら。不釣り合いな時間を費やしているコードのセグメントを探して、リファクタリングします。include と include_once の間のパフォーマンスヒットに注目しすぎると、同期して実行されているカールリクエストが朝食を食べているときにゴーストを追いかけることになります。

それまでの間、最善の提案は、php.net マニュアルに目を通し、やろうとしていることを実行する組み込み関数があるかどうかを確認し、それを使用することです。PHP の C ベースの拡張機能は、ユーザーが作成できるどの PHP コードよりも常に高速であり、やろうとしていることのかなりの部分がすでに完了していることに驚かれるでしょう。

しかし、繰り返しになりますが、これはどれだけ強調しても足りません。 時期尚早な最適化はよくありません!!! 適切なレベルの抽象化を使用してアプリケーションを立ち上げ、プロファイルを作成してから、時間を浪費している可能性があるものを修正するのではなく、実際に時間を浪費しているものを修正するだけです。

いや、インクルードは問題ないので、心配する必要はありません。

ある時点でキャッシュヘッダーを少し調整することを検討することもできますが、重大なヒットが発生しない限り、問題はありません。これがすべて静的データであると仮定すると、サイト全体を静的 HTML に変換することも検討できます (最も簡単な方法:Webサーバー経由ですべてのページを取得し、一致するディレクトリ構造にダンプするスクリプトを作成します)

ほとんどの Web アプリケーションはデータベース (または外部ストレージが何であれ、データベースは 9/10 倍) の速度によって制限されており、アプリケーションコードが懸念されることはほとんどありません。心配する必要があることはまだ何もやっていません。

サイトのコードをどのように構成するかについて長期にわたる決定を下す前に、次の内容を読んでおくことをお勧めします。モデル-ビュー-コントローラーデザインパターン。他のものもありますが、これは Web 開発サークルで大きな地位を獲得しているようで、確かにしばらくの間存在するでしょう。Martin Fowler 氏の著書で提案されている他のデザインパターンをいくつか見てみるとよいでしょう。エンタープライズアプリケーションアーキテクチャのパターンどのような種類のデザインがニーズに最も適しているかについて最終的な決定を下す前に、

プロジェクトの規模と範囲に応じて、Zend Framework や PHP On Trax などの既製の PHP フレームワークを使用することも、独自のソリューションを構築することもできます。

特に HTML コンテンツのレンダリングに関しては、ビジネスロジックを表示ロジックから分離するために、何らかの形式のテンプレートを使用することを強くお勧めします。私の開発では、この 1 つの単純なルールにより、どちらかを変更する必要がある場合に何時間もの作業を節約できることがわかりました。私は http://www.smarty.net/">Smarty を使用したことがありますが、世の中のほとんどのフレームワークには独自のテンプレートシステムがあるか、独自の好みのテンプレートシステムを使用できるプラグインアーキテクチャが提供されていることがわかりました。方法。考えられるソリューションを検討する際には、キャッシュされたバージョンを作成できるソリューションを探すことをお勧めします。

最後に、バックエンドの速度が気になる場合は、バックエンドデータストア (データベースであっても、単なるシステムファイルであっても) の呼び出しを最小限に抑える方法を検討することを強くお勧めします。あまりにも多くのコンテンツ (たとえば、数百のレコードを含むテーブルに保存されている大規模なレポート) を一度にロードしてレンダリングすることは避けてください。可能であれば、ユーザーインターフェイスが一度に読み込むデータの量を減らす方法を探してください。HTML コンテンツとその CSS、JavaScript、またはその他の依存関係の実際の読み込み時間について特に懸念がある場合は、次の内容を確認することをお勧めします。これらの提案 Yahoo!の人たちから。

JayTee が言及したことを追加するには、必要なときに機能をロードします。これを自動的に行うフレームワークを使用していない場合は、PHP5 で導入された __autoload() 機能を検討するとよいでしょう。基本的に、特定のクラスをインスタンス化するときに、まだインスタンス化されていない場合は独自のロジックを呼び出すことができます。ロードされています。これにより、そのクラスを定義するファイルをオンデマンドで include() できるようになります。

アプリケーションを高速化するためにできる最大のことは、次のようなオペコードキャッシュを使用することです。 APC. 。優れたリストと説明が次のサイトにあります。ウィキペディア.

単純なインクルードに関する限り、ディスク I/O によってアプリケーションが適切に拡張できなくなる可能性があるため、各リクエストにあまりにも多くのファイルを含めないように注意してください。数十個のインクルードは問題ありませんが、一般的に、最も頻繁にインクルードされるファイルを 1 つのスクリプトにパッケージ化して、インクルードが 1 つだけになるようにすることをお勧めします。ロードする必要のないいくつかのクラスをあちこちに置くことによるメモリのコストは、何百もの小さなファイルを含めるディスク I/O のコストよりも優れています。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow