Последствия для производительности нескольких вызовов GET по сравнению с более сложным запросом POST/GET к AJAX в формате JSON с сервера

Я работаю над веб-сайтом, на котором внешний интерфейс работает на AJAX, взаимодействуя с сервером обычным способом RESTful и получая ответы в виде JSON.

Достаточно просто управлять запросами POST, DELETE и PUT, поскольку они ничем не отличаются от традиционного подхода. Проблема заключается в ПОЛУЧЕНИИ контента. Иногда клиенту необходимо ПОЛУЧИТЬ один ресурс с сервера. Иногда больше.

Есть ли проблема с производительностью при асинхронном запуске каждого отдельного запроса GET и заполнении элементов DOM по мере поступления ответов?

Я так думаю (но поправьте меня, если я ошибаюсь), и что прирост производительности возможен, скажем, за счет предоставления массива запросов API в одном запросе, а сервер отвечает соответствующим массивом ответов JSON.

POST, DELETE и PUT семантически неверны для такого рода задач. Кроме того, запрос GET кажется некорректным. В конце концов, отправка запроса GET на /ajax_handler?q=get_users,get_pages,get_current_user кажется странной, поскольку я привык видеть запрос GET как запрос одного ресурса.

Еще одна альтернатива состоит в том, чтобы просто подготовить все соответствующие данные для каждого запроса GET (как вы это делаете на обычной странице без AJAX) и собрать все вместе, оставив выяснение того, что является важным/новым для клиента, возможно, с помощью последней проверки. измененный элемент в каждом массиве JSON.

Из-за боязни быть закрытым как субъективный мой конкретный вопрос заключается в том, существует ли семантически идеальный способ использования одного запроса GET для получения нескольких, только отдаленно связанных фрагментов данных с сервера, или стоит ли прирост производительности?


person Steven    schedule 05.07.2010    source источник


Ответы (1)


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

Кроме того, многократное подключение к пользовательскому интерфейсу приведет к принудительным проверкам аутентификации, а также может увеличить нагрузку на вашу БД как для состояния ASP.NET, если вы используете БД для этого, так и для извлечения отдельных ресурсов, если вы не кэшируете где-то результаты. Кэширование только для поддержки болтливого интерфейса увеличит нагрузку на память на ваших серверах и может привести к зависанию в периоды высокой нагрузки.

Мало того, вы можете платить за дополнительную пропускную способность, которая не имеет отношения к самому запросу (например, заголовки пакетов TCP/IP), которая будет увеличиваться пропорционально тому, насколько болтлива ваша система.

person Andrew Matthews    schedule 05.07.2010
comment
Откуда, черт возьми, взялся ASP.NET? - person Dagg Nabbit; 06.07.2010
comment
ой. Сила привычки. Извиняюсь. пожалуйста, замените /любые средства управления состоянием и сеансами на основе РСУБД/ - person Andrew Matthews; 06.07.2010