1

バックグラウンドで堅実なドキュメント処理作業を行う Web アプリケーションがあります。ユーザーが処理のためにドキュメントをアップロードすると、処理が完了するまでに最大 20 秒かかります。現在、毎秒更新される進行状況バーを使用して、ユーザーを引き付けようとしています。

  1. Web アプリケーションが深刻なバックエンド処理を行うのに 20 秒かかる場合、それは悪いアプリケーションでしょうか?
  2. 処理に 10 ～ 15 秒以上かかる Web アプリケーションに遭遇したことがありますか? インターネット上で同じことを行う人気のある Web サイトはありますか?
  3. この種の時間のかかるアプリケーションを再設計して、バッチ駆動型のアプリケーションにすることは理にかなっていますか? 処理が完了した後にユーザーに非同期メッセージを送信するアプリケーション (たとえば、電子メール/SMS)。
  4. 現在、1 分あたり最大 30 ユーザーまでサービスを提供できます。インフラストラクチャの観点から、5000 人を超えるユーザーにサービスを提供するためにこれを拡張する必要がある場合、スケールアウト (マシンを追加購入) することは理にかなっていますか? はいの場合、必要なマシンの数をどのように計算しますか? たとえば、勤務時間中 (9-5) に 500 人のユーザーがアプリケーションを使用しているとします。
4

3 に答える 3

2

時間がかかり、技術的な理由 (制御できない外部システムへの依存、リソースの不足) で高速化できないリクエストについては、facebook と youtube が行うことを行います: バックグラウンドでジョブを実行し、通知システムを提供して、ユーザーはジョブがいつ終了したかを知っています。そうすれば、ユーザーは要求が完了するのを待つ必要はありません (また、誤ってページに戻ったり更新したりした場合に何が起こるか心配することもありません) が、要求が完了するとすぐにフィードバックを受け取ることができます。

適切に実行されたフィードバック システムは、「通知」の一部としてプログレス バーを提供することさえできます。Android 上のアプリケーションは、通知を使用してこれを行います。

于 2013-09-21T21:53:20.377 に答える
1

私の意見では ：

  1. 深刻なバックエンド処理を考えると、私はそれを悪いアプリケーションとはマークしません。

  2. 確かに、ドキュメント、画像、オーディオ、ビデオなど、バックエンド処理が激しいサイトもあるでしょう。

  3. 可能であれば、私の意見では、このようなプロセッサー集中型のタスクは、バッチ処理モードで処理する必要があります。このようなタスクは、おそらくセカンダリ マシンに委任できます。ジョブが設定された期間を超えた場合に、ユーザーがジョブの完了通知を選択するオプションが存在する可能性があります。また、ジョブがまだ処理されている間にサインアウトしたユーザーに、ジョブの完了通知を送信することもできます。

  4. ユーザーのスケーリングを考慮すると、リソースをスケーリングすることはおそらく理にかなっています。リソース規模の要件を計算するのは、おそらく簡単な作業ではありません。処理されたドキュメントの数と、平均およびピーク使用時間にかかった期間を調べるためのログを作成できます。これらの数値を現在の平均同時ユーザー数と組み合わせると、リソースのスケーリングの大まかな見積もりを出すのに役立ちます。

于 2013-09-28T17:17:56.887 に答える
1

質問は意見に少し依存しすぎていますが、とにかく。

1) ユーザーの期待に依存します。大量のジョブ リクエストを送信していることがわかっている場合は、遅すぎるとは思わないかもしれません。静的コンテンツを閲覧している場合は、そうです。同様に、映画のダウンロードと写真のダウンロードに同じ時間を費やすことはないと思います。

2) 私が知っていることではありません。繰り返しになりますが、あなたの Web サイトはユーザーに何を提供しているのでしょうか?

3) 15 ～ 20 秒間、バッチ ジョブをサポートするために再設計が必要だとは言いません。多分分になると。

4) 詳細な調査なしに知ることは不可能です。より多くの CPU/メモリが必要なだけですか? それとも、同期の問題があり、ユーザーが増えると問題が指数関数的に大きくなる可能性がありますか? また、ボトルネックを解決するのは、他の何かがボトルネックになっているからにすぎないことを忘れないでください。

于 2013-09-21T21:28:57.753 に答える