HTTPパフォーマンス-多くの小さなリクエストまたは1つの大きなリクエスト
シナリオ：
- 私のサイトでは本を表示しています。
- ユーザーはすべての本を「後で読む」リストに追加できます。
動作：
ユーザーがサイトにアクセスすると、書籍のリストが表示されます。 「後で読む」リストにすでに含まれているものもあれば、含まれていないものもあります。
ユーザーは各書籍の横に、その書籍がリストに追加されているかどうかを示す表示があります。
私の問題
私はどのオプションが私の状況にとって理想的であるかについて議論しています。
オプション1：
- すべての本について、ユーザーのリストにすでに存在するかどうかをサーバーに問い合わせます。
- 各本のインジケーターを更新します。
Pro：サーバーへの要求は非常に小さく、応答は非常に簡単です（trueまたはfalse）。
Con： 30本のページで、ソケットをブロックできる30の個別のhttpリクエストを送信します。ブラウザとサーバーが各トランザクションでハンドシェイク全体を実行する必要があることを考えると、かなり遅くなります。
オプション2：
- サーバーに1回クエリを実行し、「後で読む」リストにある書籍の完全なリストを配列として応答を取得します。
- ブラウザーで配列を確認し、配列内に存在するかどうかに基づいて各書籍の表示を更新します。
Pro： 1つのリクエストのみを行い、すべての書籍のインジケーターを一度に更新します。
Con：「後で読む」リストには数百冊の本が含まれている可能性があり、大きな配列を渡すと時間がかかり、過剰になる場合があります。特に画面に30冊の本が表示されないシナリオでは、2-3冊しか表示されません。 （つまり、特定の本がリストに含まれているかどうかを確認したいと思います。このために、サーバーにリストから本のリスト全体をクライアントに送信させます）。
だから、
パフォーマンスを最大にするためにどちらの方法を使いますか：1または2？
私が見逃している代替品はありますか？
オプション1は良さそうですが、スケーラビリティの点で大きな問題があります。
オプション2はこのスケーラビリティの問題を軽減し、その設計を改善できます。
クライアント側では、JavaScriptを使用して、表示された本のIDのみを収集し、ajaxを介して、30冊の本についてのみ、後の情報の配列をクエリします。このようにして、1回のhttpリクエストでページを高速で提供し、追加の情報の小さなセットをリクエストします。
サーバー側では、各ユーザーの読み取りIDのメモリ内配列のキャッシュをさらに改善できます。
2017年の解決策は、全体的なパフォーマンスではなく、ユーザーエクスペリエンスとユーザーの期待に関するものだと思います。
そして今日、ユーザーは遅延を容認しません。その意味で、洗練されたユーザーインターフェイスは、可能な限り迅速に応答するようにしています。したがって、これらの小さなリクエストを使用してユーザーが何かを実行できるようにする場合（その1つの大きなリクエストが返されるのを2秒待つ代わりに）、そのソリューションを選択する必要があります。
私の知る限りでは、1つのページが50、100のリクエストを送信する可能性のある「高忠実度」のサイトは数多くあります。そのため、私はその一般的な方法を検討します。
そして、多分ここで役に立ちます：se-radio.netポッドキャスト episode 277 は、テールレイテンシのコンテキストでこのトピックについて集中的に説明しています。
私の見解では、データがどのように格納されているかによって異なります。リレーショナルデータベースが使用されている場合、対応するテーブルで結合を行うだけで、ブールフラグを書籍のリストに簡単に取り込むことができます。これにより、最良の結果が得られる可能性が高く、フロントエンドでアルゴリズムを記述する必要はありません。