LAMP セットアップで共有ホスティングを使用しています。明らかに、ページごとの Db への呼び出しが少ないほど良いです。しかし、いくつが多すぎますか?二?十?100人?人々がどう思うか興味があります。
10 に答える
これは、(db)servers の設定に大きく依存します。可能な限りほとんどの情報をキャッシュし、db 呼び出しを最小限に抑えるようにしてください。データベースは (ほとんどの場合) サービスのボトルネックになります。サイトの使用率が高くなります。したがって、実際には必要ではないかのようにクエリを起動しないようにします。
ページごとに 10 個を超える db 呼び出しを使用しないようにしていますが、それはインフラストラクチャと提供する情報によって異なります。
それはサーバーの負荷に依存すると思います。1 分間に 1 人の訪問者がいる場合、1 ページあたり 1 ~ 10 db の呼び出しで十分です。サーバーの負荷がそれよりも高い場合、たとえば 1 秒あたり 10 ページ リクエストの場合は、キャッシュを使用して db サーバーの負荷を最小限に抑えることを検討する必要があります。
私が.comブームでwww.boxman.comプロジェクトに取り組んだとき、彼らは異なるドメインの下で9つの異なる言語/国のサイトとして表示された1つのWebサイトを持っていました。すべてのテキストは、製品などの通常のものと同様にDBから取得されました。各ページには、通常、200の奇数のDB要求が含まれますが、主に単一のID、文字列の組み合わせが返されます。システムには一度に100人のユーザーがいました。
DBは、16ウェイRS6000UNIXボックスでDB2SQLを実行しました。これはおそらく、現代の3ghzQUADコアインテルボックスと同等です。
システムは機能しました...ボリュームが取得されると、キャッシュを実装しました。これには、毎日静的なデータをWebサーバーのドライブに移動してDBにヒットしないようにする同期プロセスの記述が含まれていました。
基本的に、パフォーマンスが大丈夫なら、それは大丈夫だと思います!しかし、需要の拡大を考慮し、それが発生したときに備えておく必要があります。
ひもの長さはどれくらいですか? 男性の足の長さはどのくらいですか?ページの読み込みで何回の DB クエリを作成する必要がありますか?
単一の答えはありません。明らかに、不必要なクエリを作成することは悪い考えです。過剰な DB 接続を開始すると、さらに悪化します。不変の値をキャッシュするのは良いことです。それを超えて、ページで「$Nクエリのみを使用する必要があります」と恣意的に言うことはできません-それは、何をしようとしているのか、およびパフォーマンスの目標が何であるかによって異なります.
理論的には、単一の DB クエリを使用するように任意のアプリケーションを作成できます。そのクエリが、インデックスのない全テーブル スキャンを含む大規模な 20 方向の結合であり、ほとんどが null である何千もの行を返す場合でも、途方もない量のメモリと時間がかかります。アプリケーションに到達したら処理します。明らかに、これは非常に悪いことです。一般に、明らかに無駄なこと (ループ内で一連の単一行クエリを実行するなど) を実行することは避け、後でパフォーマンスについて心配します。
ドナルド・クヌースの言葉を借りれば、「私たちは小さな効率性を忘れるべきです。たとえば、約 97% の確率で: 時期尚早の最適化はすべての悪の根源です」. 誰もが次の Twitter になるかのように「スケーラビリティ」について話しますが、実際には、Twitter が現在のように大きくなることに重点を置いていたら、最初から製品を世に出すことはなかったでしょう。場所。
サーバー (Web とデータベース) がすべての要求を処理し、許容時間内にページを返すことができる限り、現在のクエリ数は問題ないと思います。サーバーに大きく依存します。それでも、できるだけ少ないクエリを使用することは、とにかく良いルールです。
最終的には、ユーザーがどのようなエクスペリエンスを期待しているかによって異なります。包括的なデータがページに表示されることを期待している場合は、1.) データベースから取得されるデータの量に関係なく、サイトが負荷の下で機能できること、および 2.) が期待されている必要があります。ページをロードする時間コストは、サーバー全体の負荷ではなく、その特定のページのデータ負荷に依存します。
許容される db 呼び出し数の大きな支持者は、基礎となる db 設計でもあります。基礎となるデータベース構造の複雑さのために、(キャッシュされていない) ページの読み込みごとに定期的に数百回以上の呼び出しを行うエンタープライズ グレードの e コマース サイトがあります。
全体として、db 呼び出しを確認する良い方法は、特定のページが許容できる時間内に読み込まれるかどうかを判断し、そこから、読み込み時間と CPU およびメモリの使用を最適化するための戦略を検討することです。
100,000ページのリクエストは、24時間で1秒強に過ぎないことを忘れないでください。彼ら全員が一度に要求しない限り。
キャッシュ以外のもう 1 つの重要な事項は、準備済みステートメントを使用することです。クエリを実行すると、データベースは 1) クエリを分析し、2) 実行する必要があります。準備済みステートメントを使用すると、データベースは前回使用したクエリ プランをキャッシュできるため、各クエリは dbms の負担が少なくなります。実行するクエリの数で負荷を数えるのではなく、dbms にどれだけのストレスをかけるかを考えてください。100 個の準備済みクエリを実行すると、コード内でアドホックに生成された 50 個のクエリを実行するよりも高速になる可能性があります。
忘れないで
- ストアドプロシージャを使用します-実行速度が速くなります。
- それらを新鮮な状態で実行します-週に1回。(データベースは、現在の状態を使用してストアドプロシージャを最適化します。これが変更されると、ストアドプロセスは最適化されなくなります)。
- 「showplan」などのコマンドを使用して、SPが何をしているかを実際に理解します。
- ストアドプロシージャは、ネットワークトラフィックを削減する複数のデータセット(データテーブル)を返すことができます。1つのストアドプロシージャで複数のことを実行できます。
トニー
1つ以下が常に最適です。通常、2つは1つ多すぎます。
1つのクエリで複数の結果セットを返すことができる場合は、それを実行します。情報がかなり静的である場合は、それをキャッシュしてキャッシュからプルします。
10回の個別のデータベース呼び出しは適切ではありませんが、使用率の低いサイトを強制終了することはありません。