1

米国のほとんどの人が自宅で接続している場合、クライアントのブラウザからインターネットサーバー(Google App Engineなど)に200,000個の整数のリストを送信するのにかかるおおよその時間はどれくらいですか?データがiPhoneから送信された場合、それは大きく変化しますか?

整数リストのサイズが大きくなると(たとえば、100万個の整数のリストの場合)、時間の長さはどのように長くなりますか?

コンテキスト:JavaScriptのブラウザー用またはPythonのサーバー用に、このようなリストの簡単な計算と並べ替えを行うコードを作成する必要があるかどうかわからなかったため、出力の送信にかかる時間の問題を調査したいと思いました。このような計算を処理するのに最適な場所(クライアントのブラウザーまたはアプリエンジンサーバー)を決定するのに役立つ、ブラウザーからWeb経由のサーバーへのデータ。

その他のコンテキスト:

整数のタイプ:私は整数の2つのリストを扱っています。1つは、整数が{0,1,2,3、...、99,999}のように見える200,000個のオブジェクトのIDのリストです。100,000の2番目のリストは、1桁の数字{...、4,5,6,7,8,9,0,1、...}です。

計算の種類:ブラウザから、100,000個のオブジェクトを参照する約10個の変数に関連付けられた重みを変更して、独自のカスタムインデックス(またはランキング)を作成します。INDEX = w1 * Var1 + w2 * Var2 +...wNVarN。したがって、計算では、ベクトル(配列)のスカラーへの乗算と2つのベクトルの加算、および100,000個の値の最終的なINDEX変数ベクトルの並べ替えを参照します。

4

4 に答える 4

2

一言で言えば...

これはおそらく悪い考えです、

特に、転送に関連する遅延を除いて、さまざまなプランの制限を超える月額に関連する制限および/または追加料金がこれをひどい経済的なオプションにするモバイルデバイスで/の場合...

大まかな見積もり(詳細は以下を参照)では、一方向送信には0.7〜5秒かかります。
この見積もりには、主に2つの要因により、多くのばらつきがあります。

  • ネットワーク技術と計画
  • 200kの整数で得られる圧縮率。

ネットワークの特性は多かれ少なかれ与えられているので、最も重要な改善は圧縮率からもたらされます。これは、200,000個の整数の統計分布に大きく依存します。たとえば、それらのほとんどがたとえば65,000よりも小さい場合、リストは元のサイズの約25%に圧縮される可能性が非常に高くなります(75%のサイズ縮小)。提供された時間の見積もりでは、25〜50%のサイズ縮小のみを想定しています。

もう1つのネットワーク上の考慮事項は、バイナリMIME拡張(8ビットMIME)の可用性です。これにより、たとえばB64の33%のオーバーヘッドを回避できます。

その他の考慮事項/アイデア

  • iPhone /モバイルデバイスプランのこのタイプのネットワーク使用は、うまくいきません!!!
    ATTはあなたを愛します(多分)、あなたのエンドユーザーは少なくとも多くの(ほとんど?)が持っている計画制限のあるものをあなたに嫌うでしょう。
  • 1つの大きなリストを送信するのではなく、リストを3つまたは4つのチャンクに分割して、サーバー側の並べ替えを[ほとんど]データ転送と並行して実行できるようにすることができます。
  • 整数が[大まかに]ソートされると、圧縮率が向上します。おそらく、クライアント側で最初のパスのソートを行うことができます。

どうすればわかりますか?..。

1) Amount of data to transfer (one-way)
  200,000  integers 
    = 800,000 bytes  (assumes 4 bytes integers)
    = 400,000 to 600,000 bytes compressed  (you'll want to compress!)
    = 533,000 to 800,000 bytes in B64 format for MIME encoding

2) Time to upload   (varies greatly...)
    Low-end home setup (ADSL)  = 3 to 5 seconds
    broadband (eg DOCSIS)      = 0.7 to 1 second
    iPhone                     = 0.7 to 5 seconds possibly worse;
                                        possibly a bit better with high-end plan

3) Time to download (back from server, once list is sorted)
   Assume same or slightly less than upload time.
   With portable devices, the differential is more notable.
   The question is unclear of what would have to be done with the resulting 
   (sorted) array; so I didn't worry to much about the "return trip".
   ==> Multiply by 2 (or 1.8) for a safe estimate of a round trip, or inquire
       about specific network/technlogy.
于 2010-03-18T04:24:15.663 に答える
0

デフォルトでは、通常、整数は32ビット値または4バイトで格納されます。その場合、200,000の整数は800,000バイト、つまり781.25キロバイトになります。クライアントのアップロード速度にもよりますが、640Kbpsのアップロードでは約10秒です。

于 2010-03-18T02:26:19.270 に答える
0

それは800000バイトまたは781.3kbです。つまり、通常のjpeg写真のサイズと言えます。ブロードバンドの場合、それは数秒以内であり、いつでも圧縮を検討できます(このためのライブラリがあります)

データの時間は直線的に増加します。

于 2010-03-18T02:28:56.993 に答える
0

JavaScriptからサーバーにデータを送信するため、テキスト表現を使用します。サイズは、各整数の桁数に大きく依存します。200,000の2〜3桁の整数、または6〜8の整数について話しているのですか?また、HTTP圧縮が有効になっているかどうか、およびiPhone上のSafariがそれをサポートしているかどうかにも依存します(わかりません)。

時間はサイズに応じて直線的になります。iPhoneでの一般的なアップロード速度は、ユーザーがビジネスWi-Fi、パブリックWi-Fi、ホームWi-Fi、3G、またはエッジネットワークのいずれを使用しているかによって大きく異なります。

パフォーマンスに大きく依存している場合は、HTMLアプリよりもネイティブアプリの方が適している可能性があります。クライアントで計算を行わなくても、バイナリデータを送受信して圧縮できるため、時間を短縮できます。

于 2010-03-18T02:41:29.893 に答える