ヘッダー、ナビゲーション、レイアウト、サイドバー、フッターを別々のページに分割し、php include 関数を使用してそれらを管理するだけで作業時間を短縮できるのは悪いアプローチではないかと思っていました。パフォーマンスへの悪影響?
5 に答える
これが全体的なページ読み込みパフォーマンスに及ぼす影響は (あるとしても) 非常に最小限であるため、おそらく 1 分あたり数百万のリクエストを処理するようになるまで検討する価値はありません。
コードをロードする必要のある何千ものインクルード可能なファイルに分割するなどのばかげたことをしていない限り、これは PHP の決定的な設計要素になることはありません。
コードをより保守しやすくすることを行います。
いいえ、常に追加のファイルを開く操作ですが、ヘッダー/フッター/サイドバーが分離されているだけであれば、心配する必要はありません;)
ページを含めるためのプロセッサの負荷/時間は非常に小さいため、気付かないほどです。それは私のマシンにも登録されません - そしてそれは単一のコアを持つ単一の CPU であり、派手な Web サーバーではありません。
ファイルを含めることは間違いなくパフォーマンス ヒット*ですが、適切にモジュール化されたコードを開発および維持するために節約される時間と比較すると、信じられないほど小さくてごくわずかです。
* 何千ものファイルを含めると、パフォーマンスの低下が顕著になります。いくつかのファイルを含める場合、必要な余分な CPU/IO サイクルは目立ちません。
もちろん、この種のインクルードではヒット パフォーマンスはそれほど重要ではありませんが、I/O の作成には常にコストがかかるため、あまり多くのスクリプトを含めないように注意してください。
APCのようなキャッシュを使用して、コードが多くの I/O を行わないようにすることができます。
この場合、心配する必要はありませんが、より複雑なコードを書くときは、きっと心配するでしょう :) 良いアドバイスが見つかると思います。
Apacheサーバーのこのベンチを見てください。
シンプルに呼び出すとecho "hello world";
Total transferred: 3470000 bytes
HTML transferred: 120000 bytes
Requests per second: 2395.73 [#/sec] (mean)
Time per request: 4.174 [ms] (mean)
Time per request: 0.417 [ms] (mean, across all concurrent requests)
Transfer rate: 811.67 [Kbytes/sec] received
PHPはデータを出力するために多くのことを行うため、クエリが単純であってもパフォーマンスへの影響を常に考えてください。