Какой способ передачи данных по http быстрее?

Question

[kidar2]

Есть некоторый массив данных в json.
Весит к примеру 1mb.
Его надо передать на клиент с сервера по ajax запросу клиента.

Как будет оптимальней и от чего это может зависеть?
1. Один ajax запрос - полный ответ в 1mb
2. 4 параллельных ajax запроса и ответы от сервера по частям

p.s. gzip сжатие уже включёно.

Answer 1

[Дмитрий Сонько]

Мне кажется можно вполне разбить задачу на куски. Как пример, не так давно, мы делали выбор страны и города. Первая ошибка была отдавать на фронтенд весь контент прегенеренный, получилась страница весом несколько мегабайт. Заменили на аякс запросы получение списка стран и городов, получилось лучше, но не идеально. Так как несколько десятков тысяч городов без фильтрации вешали фронт. И итоге решили очень просто. Пока человек не выбрал страны, не показывать города. Выбрал страну, на сервер ушел аякс с запросом городов по этой стране, запрос получили, показали на фронте. Город изменили - все снова. Кэш на стороне сервера результатов запроса решает многие проблемы на ура. Думаю вам стоит найти зависимости и нет необходимости провалить в браузер такое количество информации

Comments

[kidar2]

У меня данные не статичные как в вашем случае.
Не хотелось бы уходить в обсуждение общей задачи подходов к разработки (как это часто бывает в русскоязычных форумах разработки), меня интересует только заданный выше вопрос.

[Дмитрий Сонько]

kidar2: данные представляют один набор или их можно все таки разбить? Если это некое дерево, то мне кажется лучше делать несколько запросов, если это один пул, например посещаемость по проекту за 123 дня, то лучше одним запросом все таки.

[kidar2]

Разбить можно. Мне хочется понять что в итоге будет лучше, по кускам грузить или одним запросом? Факторов тут много, другие запросы могут быть (картинки, google analytics тот же). И если других активных запросов будет много, то загрузка по частям будет, наверно, менее эффективней.

Может в http2 что-то есть по этой теме?

[Дмитрий Сонько]

kidar2: если идет много запросов, то учитывайте что браузер, в одну еденицу времени открывает конкретное кол-во соединений с одним хостов (зависит от браузера, обычно 4-8). Поэтому, чатсо делают такой финт как прилинковывают на сервер несколько поддоменов вида static1.domain.com, static2.domain.com и разбивают адреса картинок и тд по этим поддоменам. За счет чего, чуть ускоряют загрузку статики

Answer 2

[Дмитрий Беляев]

1мб для сегодняшнего интернета - копейки
при одном запросе по факту будет меньше трафика (заголовки ходят 1 раз)
при 4х запросах придется резать ответ на сервере и склеивать на клиенте

Comments

[kidar2]

1mb - это пример. Может быть до 15mb.
По склеиванию и разбиению понятно.
Затраты на заголовки - спасибо. не учёл.

[65536]

kidar2: да при мегабайте заголовки можно не учитывать

[Владимир Сергеев]

>1мб для сегодняшнего интернета - копейки
Ужасно порочная мысль для веб-девелопера. Представим три простых сценария:
1) пользователь подключается не из домашней/рабочей сети, а с улицы по 2G/3G, где скорость в зависимости от кучи условий может проваливаться до 64 КБ/с и ниже;
2) прямо сейчас пользователь в роуминге и вынужден платить помегабайтно, а времени/возможности найти ближайший вайфай у него нет;
3) условный тёма лебедев написал о вашем сайте, и туда в первый же полчаса ринулись десятки тысяч людей, а пропускная способность вашего веб-кеша или CDN ограничена так, что вы не можете всем скармливать данные без задержек, и тут кто-то начинает писать в комментах: «а чо он такой медленный» — «да, да, у меня тоже медленно открывает, зажрались совсем».

[АртемЪ]

Дмитрий Беляев Нифига не копейки.
У меня в городской квартире 200мегабит в интернет и гигабит в локальную сеть провайдера.
И для меня не проблема за пару минут скачать 10-15Гб.
А в доме - 512килобит если стабильно держится это шикарно.
Поэтому выкачивать 1мб это реально долго, и если сайт неожиданно передает такой объем информации, за это расстреливать надо.

[Дмитрий Беляев]

Владимир Сергеев: АртемЪ: если вернуться к вопросу топикстартера, то вопрос был не в передавать/не передавать, а паралелить/не паралелить и в таком ключе 1 или даже 10 мб - это копейки, а на медленном инете паралельность только забьет канал

[АртемЪ]

Дмитрий Беляев: согласен.

[Владимир Сергеев]

Дмитрий Беляев: Если просто разбить объект на четыре куска и передавать их одновременно, то в этом действительно смысла нет. А если осмысленно разнести их передачу во времени, как упоминал в своём примере Дмитрий Сонько, то можно не только разгрузить канал, но и оптимизировать нагрузку на кеш. Даже если по факту будет передаваться, например, на 10-15% больше данных, для пользователя это можно сделать прозрачным, потому что их можно подгружать в те моменты, когда пользователю нужно принять какое-то решение или ввести текст — а это не моментально происходит. К тому моменту, как он закончит, следующий кусок уже подгружен. Соответственно, если пользователь по пути передумает, отвалится или отложит процесс на потом, то последующие куски передавать не надо, и объём переданной информации сократится.

[Владимир Сергеев]

Подобная практика, кстати, и в дизайне интерфейсов успешно используется; у нас, если не ошибаюсь, первым её освоил Anywayanyday (про который в своё время тоже написал Тёма): не вываливать на экран одновременно все поля для заполнения, а выводить их по мере заполнения предыдущих.

[Дмитрий Беляев]

Владимир Сергеев: Согласен, хорошая практика, только я при ее реализации предпочитаю использовать не json, а форматы данных позволяющие делать потоковую обработку, а какой формат - зависит от структуры данных, для самых простых типа массив из объектов без вложений например подойдет csv

p.s. есть у меня в разработке велосипед в виде формата данных + парсера/сериализатора для него, который позволяет потоково передовать и обрабатывать объекты любой вложенности, но в опенсорс выложу только когда до ума доведу, но если интересно, могу поделиться идеей

[Владимир Сергеев]

Дмитрий Беляев: Ну, лично я разработкой сайтов [пока] не занимаюсь, поэтому в ближайшее время мне это знание не пригодится. Однако с интересом почитаю, когда решение будет готово, конечно. Всегда рад изучить эффективную технологию. :)

Answer 3

[Владимир]

Что ж вы такое собираетесь передавать?! Имхо, парсинг такого массива будет бОльшей проблемой, чем его получение.

Comments

[kidar2]

Почему же проблема? Нативный JSON.parse в браузере быстро работает.

[Дмитрий Беляев]

kidar2: нативный JSON.parse работает синхронно и на большом объеме данных может заморозить страницу на ощутимое время

[kidar2]

С этим методом никогда проблем не было, даже на объёмах 10 mb. Это нативный метод, он быстро всё делает.

[Дмитрий Беляев]

kidar2: скачайте исходники v8 найдите в них описание json объекта и удивитесь, парсинг и сериализация json в v8 написана на js