複数のデータベースアクセスまたは1つの大規模なアクセス？

それは、パフォーマンスと最適なリソース使用率に来るときよりよいアプローチは何である：それだけが必要なときに必要な正確な情報を入手するために複数回のAJAXを介してデータベースにアクセスする、またはすべての情報保持するオブジェクト取得するために、一回のアクセスを実行する可能性が必要となることを、すべてが実際に必要なわけではないという高い確率で？

実際のクエリをベンチマークする方法は知っていますが、何千人ものユーザーがデータベースに同時にアクセスしているときのデータベースパフォーマンスに関して、接続プーリングがどのように作用するかをテストする方法はわかりません。

これに対する正しい答えはありません。他の最適化と同様に、コンテキスト/使用法に大きく依存します。

ただし、次のことを経験則として考慮してください。

x
+: Data is stable / static
-: Data is dynamic / volatile

y
+: Data is frequently used
-: Data is infrequently used

++: fetch large chunks in the fewest number of fetches 
    and persist the data as long as possible within tolerances for staleness.

+-: do what is expedient to the logic & usage; if it is convenient to 
    fetch / calc as needed do so, if it is convenient to pre-fetch and 
    persist then do so. Seek to optimize only if absolutely necessary.

-+: fetch / calc as needed; but if optimization is required consider 
    pre-fetching or pre-calculating if possible, or negotiate a tolerance 
    for less than real time accuracy to reduce volatility.

--: fetch / calc as needed and don't worry about it further unless a 
    specific case is unacceptably expensive; if so see -+.

最適化の最初のルールを覚えておいてください：測定、推測しないでください。両方を試して、ある種のストップウォッチコードでそれらをインスツルメントし、時間がかかるものを確認してください。

また、「コンピューターサイエンスには、キャッシュの無効化と適切な命名という2つの困難な問題しかない」という古いジョークも念頭に置いてください。DBからすべてを一度に引き出してメモリに保持すると、キャッシュができます。そして今、あなたは新しい問題を抱えています：システム内のどこかで何かが変更されるたびに、データベースとキャッシュの2つの場所で同じ変更を行う必要があります。DBと通信する複数のサーバー、またはサーバーにデータを変更させるための複数のAPIがある場合、これは非常に迅速に困難になる可能性があります。

この質問に対する特効薬の解決策はありません。サーバーを最大限に活用するには、可能なトレードオフを試し、サーバーを調整する必要があると思います。

最初のポイント：改善を開始する前に、現在のパフォーマンスベンチマークを設定し、それを測定し、それを改善するための可能なソリューションと比較するためのベースラインを取る必要があります。

次に、アプリケーションの使用状況を追跡する必要があります。エンドユーザーによるアプリケーションの利用方法。エンドユーザーが必要としない、返されたデータの生の数を削減することで、貴重なサーバーリソースを大幅に節約できます。たとえば、ユーザーが最初の50件に関心がある間に5000件のレコードを返すことは意味がありません。

3番目のポイント：呼び出しの頻度と考えられる影響を理解する必要があります。たとえば、ほとんどの呼び出しがルックアップ値テーブルクエリである場合、これらの呼び出しをキャッシュするインフラストラクチャを作成する可能性があります。つまり、データが頻繁に変更されない場合は、キャッシュオプションを検討してください。そしてもちろん、呼び出し回数を最小限に抑えることは、常にパフォーマンスの向上に役立つはずです。

「すべて」にBLOBや同様の大きなデータオブジェクトなどが含まれていない限り、すべてを一度に取得するとパフォーマンスが向上します。すべてをシリアル化し、回線上で移動し、反対側で逆シリアル化するためのパフォーマンスオーバーヘッドは非常に大きく、ネットワークレイテンシが大きな部分を占めています。メモリはネットワークの帯域幅よりも安価であり、おそらくしばらくの間はそうなるでしょう。あなたの唯一の本当の答えはベンチマークから得られますが、もしあなたがただ一方をもう一方に対して評価しようとしているなら、それは私が無駄にしない方法です。

アーキテクチャを決定する場合、RESTは1つのオプションです。RESTでは、常にリソースを複数回要求します。つまり、各オブジェクトには独自のURLがあるため、2つのオブジェクトを取得する要求を送信しません。HTTP / 2.0がリリースされると、このスタイルを実行する際のパフォーマンスの問題はおそらく解決されるでしょう。それ以外の場合は、できるだけ速くするために最適化するだけです。多くの企業がこのようにしています。