Какова длительность отправки списка из 200 000 целых чисел из браузера клиента на интернет-сервер? - PullRequest
1 голос
/ 18 марта 2010

Каковы приблизительные промежутки времени для отправки списка из 200 000 целых чисел из браузера клиента на сервер Интернета (скажем, механизм приложений Google) по сравнению с соединениями, которые есть у большинства людей в США? Значительно ли это меняется, если данные отправляются с iPhone?

Как увеличивается длительность времени при увеличении размера списка целых чисел (скажем, со списком миллионов целых чисел)?

Контекст: я не был уверен, стоит ли мне писать код для выполнения простых вычислений и сортировки таких списков для браузера в javascript или для сервера в python, поэтому я хотел исследовать этот вопрос о том, сколько времени требуется для отправьте выходные данные из браузера на сервер через Интернет, чтобы помочь мне решить, где (браузер клиента или сервер механизма приложений) является наилучшим местом для обработки таких вычислений.

Больше контекста:

Тип целых чисел: Я имею дело с 2 списками целых чисел. Одним из них является список идентификаторов для 200 000 объектов, чьи целые числа выглядят как {0,1,2,3, ..., 99,999}. Второй список из 100 000 - это просто однозначные числа {..., 4,5,6,7,8,9,0,1, ...}.

Тип вычислений: Из браузера человек создаст свой собственный индекс (или ранжирование) на основе изменения весов, связанных с примерно 10 переменными, на которые ссылается 100 000 объектов. INDEX = w1 * Var1 + w2 * Var2 + ... wNVarN. Таким образом, вычисления относятся к умножению вектора (массива) на скаляр и сложению 2 векторов, а также к сортировке итогового вектора переменной INDEX из 100 000 значений.

Ответы [ 4 ]

2 голосов
/ 18 марта 2010

В двух словах ...

Это, вероятно, плохая идея,

в частности с / для мобильных устройств, где, помимо задержки, связанной с переводом (-ами), лимиты и / или дополнительные сборы, связанные с ежемесячными объемами, превышающими лимиты различных планов, делают этот паршивый экономичный вариант ...

A грубо оценка (более подробная информация ниже) заключается в том, что передача в одну сторону занимает от 0,7 до 5 секунд .
Эта оценка сильно варьируется, в основном из-за двух факторов

  • Сетевые технологии и план
  • Степень сжатия, которую можно получить для целых чисел 200 КБ.

Поскольку характеристики сети более или менее являются заданными, наиболее значительное улучшение будет достигнуто за счет степени сжатия . Это, в свою очередь, сильно зависит от статистического распределения 200 000 целых чисел. Например, если большинство из них меньше, чем, скажем, 65 000, вполне вероятно, что список будет сжат примерно до 25% от его первоначального размера (уменьшение размера на 75%). Представленные временные оценки предполагали только уменьшение размера на 25-50%.

Еще одним соображением, связанным с сетью, является наличие бинарного расширения MIME (8-битного MIME), которое, например, позволило бы избежать накладных расходов B64 на 33%.

Другие соображения / идея :

  • Этот тип использования сети для планов iPhone / мобильных устройств будет работать не очень хорошо!
    ATT будет любить вас (возможно), ваши конечные пользователи будут ненавидеть вас, по крайней мере, тех, у кого есть ограничения по плану, которые есть у многих (у большинства?)
  • Вместо того, чтобы отправлять один большой список, вы можете разделить список на 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.
0 голосов
/ 18 марта 2010

хорошо, что составляет 800000 байт или 781,3 кб, или вы можете сказать размер обычной фотографии JPEG. для широкополосного доступа это будет в течение нескольких секунд, и вы всегда можете рассмотреть сжатие (для этого есть библиотеки)

время линейно увеличивается для данных.

0 голосов
/ 18 марта 2010

Поскольку вы отправляете данные из JavaScript на сервер, вы будете использовать текстовое представление. Размер будет сильно зависеть от количества цифр в каждом целом числе. Речь идет о 200 000 двух-трехзначных целых или шести-восьми целых числах? Это также зависит от того, включено ли сжатие HTTP и поддерживает ли Safari на iPhone (я не уверен).

Количество времени будет линейным в зависимости от размера. Типичная скорость загрузки на iPhone будет сильно различаться в зависимости от того, подключен ли пользователь к рабочему Wi-Fi, общедоступному Wi-Fi, домашнему Wi-Fi, 3G или сети Edge.

Если вы так сильно зависите от производительности, возможно, это больше подходит для нативного приложения, чем для HTML-приложения. Даже если вы не выполняете вычисления на клиенте, вы можете отправлять / получать двоичные данные и сжимать их, что сократит время.

0 голосов
/ 18 марта 2010

По умолчанию, как правило, целые числа хранятся в 32-разрядном значении или в 4 байтах. Тогда 200 000 целых чисел будут 800 000 байт или 781,25 килобайт. Это будет зависеть от скорости загрузки клиента, но при загрузке 640 Кбит / с это примерно 10 секунд.

...