Каковы некоторые рекомендации для взаимодействия клиент-сервер? - PullRequest
9 голосов
/ 02 ноября 2011

Я создаю веб-сайт для работы, и одной из наиболее важных функций является богатая сетка контента, отображающая данные. По умолчанию он отображает только 20 элементов на странице, но у нас есть ~ 200 элементов в базе данных, которые можно фильтровать, сортировать и искать.

Наша команда по продажам и маркетингу также запрашивает функцию «перечислить все», чтобы они могли отображать все данные в одном месте и прокручивать, а не пролистывать данные.

Flexigrid data

Вся эта система построена с использованием ASP.Net MVC на стороне сервера, jQuery и Flexigrid на стороне клиента и использует JSON для обмена данными между ними через AJAX.

Я получил довольно твердую фактическую часть передачи данных. Страница из 20 результатов занимает 800 мс для всего запроса (отправьте запрос на сервер через Flexigrid и получите ответ). Это скорее обработка на стороне клиента, которая занимает некоторое время.

Я мог бы переложить часть обработки на стороне клиента на сервер. Но это приведет к тому, что работа на стороне сервера займет больше времени, а размер возвращаемого документа станет намного больше. Не проблема в ситуациях с высокоскоростным подключением к Интернету ... но это не обязательно так.

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

Поскольку по крайней мере один человек пометил это как "ненастоящий вопрос", позвольте мне уточнить ...

  • Что я могу сделать, чтобы облегчить проблемы со временем обработки на стороне клиента, не перенося столько обработки на сервер, что у меня возникает проблема со временем передачи данных?
  • Каковы некоторые рекомендации, когда речь идет о балансировании обработки на стороне клиента с обработкой на стороне сервера?
  • Лучше ли ошибаться на стороне сервера или клиента?
  • Какими инструментами я могу воспользоваться, чтобы лучше оптимизировать эти обмены, чтобы все не шло не так?

Ответы [ 3 ]

2 голосов
/ 02 ноября 2011

Что вы обрабатываете на стороне клиента, что занимает так много времени? Обработка объекта JSON (даже очень большого) не должна быть слишком интенсивной.

Множество поисков DOM, когда запись на стороне клиента данных может замедлить процесс. Сокращение DOM-поисков может значительно повысить производительность. Я считаю, что хорошей практикой для балансировки обработки на стороне сервера и клиента является ошибка на сервере. Поскольку сервер находится под вашим контролем, вы всегда можете обновить свой сервер. Сохранение большей части обработки на сервере также облегчит работу мобильных устройств и старых компьютеров.

Вы должны использовать возможности AJAX и клиентской части таким образом, чтобы улучшить взаимодействие с пользователем. Загружать и обрабатывать данные в соответствии с требованиями пользователей. Загружая только то, что они запрашивают, вы можете уменьшить нагрузку на ваш сервер и клиент.

Если вы также запрашиваете один и тот же тип данных снова и снова, вы можете посмотреть как на сервер, так и на стороне клиента. Используя кеширование, вы можете сократить время запроса и / или пропускную способность.

1 голос
/ 03 ноября 2011

Как выясняется, проблема скорее в механизмах JavaScript на стороне клиента, чем в данных, с которыми я работаю. Я провел большую часть дня, сравнивая процессы и рассчитывая время выполнения различных операций.

Все быстро работает в Chrome. В Firefox все работает довольно быстро (не так быстро, как Chrome). Реальным отставанием в производительности является Internet Explorer.

Когда я загружаю весь набор данных - все 200 строк - Flexigrid пытается выполнить некоторую постобработку для каждой ячейки в таблице . Как вы можете видеть на скриншоте, каждая строка имеет 29 ячеек ... поэтому мы просматриваем кучу операций форматирования в общей сложности 5800 раз.

Мне удалось вытащить некоторые из более дорогих операций (например, создание объектов jQuery) из низкоуровневого цикла ячеек, чтобы они выполнялись только один раз в строке, но в конечном итоге я все еще сталкиваюсь с производительностью, связанной с IE вопросы.

Чтобы дать вам некоторые реальные тесты, я установил код, показывающий общее время до того, как он достигнет определенных событий:

  • populate срабатывает, когда браузер впервые отправляет запрос XHR
  • addData срабатывает после возврата запроса и до синтаксического анализа объекта JSON
  • addCellProp срабатывает после первоначального анализа данных и выполняет итерацию по каждой ячейке таблицы
  • done срабатывает, когда все закончено

Обработка 20 строк данных (по умолчанию):

------------------------------------------------------
| browser | populate | addData | addCellProp | done  |
------------------------------------------------------
| Chrome  | 0        | 84      | 123         | 286   |
| IE9     | 0        | 151     | 309         | 799   |
| IE8     | 0        | 226     | 481         | 1105  |

Обработка полного набора данных (179 строк на этом аппарате):

------------------------------------------------------
| browser | populate | addData | addCellProp | done  |
------------------------------------------------------
| Chrome  | 0        | 318     | 669         | 1963  |
| IE9     | 0        | 157     | 1813        | 9428  |
| IE8     | 0        | 229     | 2188        | 13335 |

Самая дорогая операция - от addCellProp до done. Я прошел и сделал код максимально эффективным, но вы можете сделать так много всего, когда выполняете столько итераций набора данных, особенно при манипулировании DOM.

Я изменил Flexigrid (несмотря на многие рекомендации, чтобы этого не делать), чтобы как можно меньше касаться DOM, и это на самом деле ускорило процесс. Когда я начал это исследование, IE9 потребовалось от 20 до 30 секунд, чтобы попасть в событие done.

К сожалению, правда в том, что не все платформы созданы равными, и IE, похоже, не лучший механизм для работы с данными на дисплее таким образом.

Лучшим подходом может быть создание и управление таблицей HTML на стороне сервера и отправка всей информации (разметки и всего) в браузер по запросу пользователей IE, а не в зависимости от IE для создания разметки из необработанного JSON объект.

0 голосов
/ 22 декабря 2011

Что я могу сделать, чтобы облегчить проблемы со временем обработки на стороне клиента, не перенося столько обработки на сервер, что у меня возникает проблема со временем передачи данных?

Данные поступают из базы данных? Если это так, ограничьте данные там. Это то, что БД хорош в. Я использую flexigrid и сохраняю всю сортировку и фильтрацию подкачки. БД возвращает только необходимые данные, отсортированные и отфильтрованные по запросу. Все, что сервер должен сделать, это вернуть его, и все, что клиент должен сделать, это отрендерить.

Каковы некоторые рекомендации, когда речь идет о балансировании обработки на стороне клиента с обработкой на стороне сервера?

Держите клиент на свету насколько возможно

Лучше ли ошибаться на стороне сервера или клиента?

Да, сервер обладает большей мощностью

Какими инструментами я могу воспользоваться, чтобы лучше оптимизировать эти обмены, чтобы дела не шли наперекосяк?

Инструменты разработчика IE используют вкладку сети, чтобы увидеть, что происходит по сети

...