2017-06-25 19 views
1

ユーザーが記事を見たときに情報を収集する必要があります。ユーザーは1〜30分の記事を閲覧します(ユーザーが特定のものを探すすべてをスクロールするだけであればさらに多分でしょう)。私は、私は最低で私のサーバーのコストを抑えることができた方法と思いまして:多くの小さなPOST要求または1つの大きなPOST要求?

  1. 30-60 IDの存在するとき、私は配列に記事IDをプッシュし、それをサーバーに送るJavaScriptクライアント側では。サーバーでは、すべてのIDをループしてデータベースに挿入します。

  2. ユーザーが記事を見るたびに、1つの記事IDをサーバーに送信します。これによって、1分に60件を超えるリクエストが発生することがあります。サーバーiでは、IDをデータベースに挿入します。

+1

http要求は、サーバー間のハンドシェイクに小さなオーバーヘッドがあります。リクエストするたびに、このオーバーヘッドが発生します。多数のリクエストがある場合、遅延が目立つようになる可能性があります。したがって、(a)あなたのアプリケーションをどのようにモジュラー化する必要がありますか(1つのIDだけを送信する柔軟性が必要か、現在および将来の要件を満たすには十分なバルク更新が必要ですか?b)パフォーマンスと帯域幅もう1つのコンセプトは正確さです - IDが30になるまで延期すると、ユーザーが2つの記事をスクロールして終了すると記録されません。 – ADyson

答えて

3

ほとんどの場合、常にトレードオフがあります。そして、何度も、最適な解決策は途中にあります。私はあなたが両方をサポートし、状況に応じてそれらを交換可能に使うべきだと感じます。次のシナリオを実行してください:

  • エンドユーザーに帯域幅の問題がありますか?はいの場合は、オプション2を使用するか、記事の数を数に減らしてより低い帯域幅で簡単に取得できるようにすることもできます。
  • ユーザーに30〜60件の記事の読み込みに時間がかからないなどの帯域幅の問題がないと仮定すると、オプション1を使用して以降のフェッチにこのオプションを使用することができます。
  • 多くの場合、初期フェッチにはオプション1を使用し、それ以降は少ない数の記事を取得することは意味があります。
  • サーバーコストについては、30〜60件の記事をまとめて送信することが理にかなっています。彼がそれらをすべて読まないと思ったら、あなたのアプリの分析を使って最適な数を見つけ出し、それらの記事の数を一度に送ってください。帯域幅はユーザーには問題にならないでしょう。

tl; dr;あなたが信頼すべきデータです。あなたの直感、既存のアプリの使用パターン、およびユーザーの帯域幅の可用性を利用して、情報に基づいた決定を下します。また、サーバーコストだけではありません。経験はもっと重要だと思います。

+0

http2はパフォーマンスを向上させるでしょうHTTPリクエストの束 –