Производительность мобильной сети. Какой тип данных будет наиболее эффективным для передачи данных с веб-сервера на мобильный телефон? - PullRequest
3 голосов
/ 03 января 2012

Q: Какой тип данных будет наиболее эффективным / быстрым для использования при передаче данных между веб-сервером (/ другим?) И мобильным телефоном, например ios / android / other? 1003 *

  • JSON?
  • XML?
  • HTML?

В: Какие серверные технологии следует использовать?

  • php + mysql?

Q: Какой тип API следует использовать?

  • Restfull
  • RPC?

Есть мысли?

Ответы [ 4 ]

4 голосов
/ 03 января 2012

A1. Двоичные.

Вы смотрели на Google Protobuffers ?это эффективный двоичный форматировщик с кроссплатформенными возможностями (java, c #, python, target c, PhP. Есть даже реализация JScript, но я бы не стал этому доверять!)

Вы смотрели на такие платформы обмена сообщениями?как AMQP?Я успешно внедрил кросс-платформенную систему обмена двоичными сообщениями, используя AMQP в качестве маршрутизатора сообщений, Protobuffers в качестве двоичного сериализатора и Rabbit MQ в качестве C # и клиента Java.Он был чрезвычайно быстрым и мог выполнять запрос / ответ в обе стороны от клиента к серверу и обратно (включая сериализацию / десериализацию, исключая время сети) всего за 0,5 мс.

Стек сообщений становится:

Мобильный> Клиент RabbitMQ> Google Protobuffers> {Интернет}> Сервер RabbitMQ> Google Protobuffers> Веб-сервер

JSON - ваш следующий самый быстрый сериализатор, но ничто не может сравниться с двоичным файлом по скорости и эффективному использованиюbandwidth.

A2. Для производительности Oracle будет обрабатывать большую часть данных, SQL Server и MySql будут давать очень хорошие результаты, хотя и в зависимости от того, что вы собираетесь делать.

Это также зависит от того, как будут храниться ваши данные.Вы храните реляционные данные?Затем используйте реляционную базу данных.Вы храните данные временных рядов?Затем используйте упорядоченную по столбцам базу данных или даже плоский файл.PyTables является отличным примером основанной на Python файловой базы данных, которая отлично подходит для хранения научных наборов данных и временных рядов.

Ответ на этот вопрос действительно «зависит» - от того, что вы хотите сделать.Я также хотел бы рассмотреть вопрос о разработке хорошо знакомой вам серверной технологии, а не выбирать ее на основе чисел, поскольку все они довольно похожи.

A3. Неизвестно, не моя область знаний.

С уважением,

2 голосов
/ 03 января 2012

Прежде всего, что вы подразумеваете под эффективным?Что касается производительности мобильной сети, я бы предположил, что вы говорите о том, какая минимальная задержка от отправки веб-запроса до получения ответа.

Если речь идет о небольших объемах данных (<~ 100 КБайт)формат, вероятно, не будет таким важным, RTT будет гораздо важнее, чем пропускная способность, поэтому вы можете свободно выбирать между JSON, XML и т. д.может стать существенным фактором, так как пропускная способность станет узким местом, и вы можете рассмотреть возможность просто сжать его, например, JSON + gzip.Это приведет к потере обработки. </p>

Вы, вероятно, могли бы провести некоторое тестирование, чтобы увидеть, когда преимущество сжатия данных превышает штраф обработки, требуемой для сжатия.

1 голос
/ 03 января 2012

A1

Дело не только в передаче, а в том, как она будет обрабатываться на стороне клиента, например это получается с помощью клиента HTML?

Задержка является настоящим убийцей на мобильных устройствах, но память также является большой проблемой - я бы выбрал формат, который проще всего обрабатывать клиенту, может быть, JSON (P), но я бы хотел посмотреть на данные / приложение более подробно составить реальную рекомендацию.

Если вы пишете нативное приложение, то, безусловно, стоит рассмотреть бинарный протокол, такой как ProtoBuffers или Thrift, но у меня будет соблазн создать прототип с использованием JSON или одного из других текстовых форматов.

A2

Вероятно, что вы знаете лучше всего (в пределах разумного)

A3

Я бы пошел на REST на том основании, что некоторые запросы будут GET.

RPC предполагает, что запросы будут представлять собой POST, и некоторые браузеры разделяют AJAX POST на два пакета TCP, второй из которых отправляется только после подтверждения первого (плохо в средах с высокой задержкой).

0 голосов
/ 03 января 2012

Dr.Андрей сказал: «Это зависит».Все зависит от того, какое приложение вы разрабатываете.Дайте нам больше объяснений!

...