уменьшение размера ответа

Question

Я работаю над веб-приложением, и я использую опрос, чтобы проверить, есть ли какое-либо обновление. Эти запросы опроса происходят каждые 1 или 2 секунды. Размер ответа составляет 240 байтов, если нет необходимости в обновлении (в этом случае возвращается пустой ответ) и около 10 КБ, который является размером самого содержимого. Моя проблема заключается в том, что она возвращает не менее 240 B в каждых секундах приблизительно, есть ли способ оптимизировать этот ответ, немного увеличив границы?

Когда я проверил содержимое ответа, я увидел, что для меня важны 50 байтов (идентификатор сеанса и код состояния). Однако в заголовке есть информация, такая как тип подключения, тайм-аут и тип содержимого. Эти параметры будут одинаковыми для каждого запроса этого типа (т. Е. Он всегда требует типа содержимого: «text/html; carset = utf-8»). Итак, могу ли я просто принять эти параметры на стороне клиента и не дать серверу отправить эту информацию заголовка?

Я использую django на стороне сервера и jQuery для отправки запросов ajax кстати. Кроме того, на данный момент не существует никаких проблем с технологией push.

Answer 1

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

Я бы рекомендовал добавить тайм-аут в цикл - скажем, 30 или 60 секунд - после чего веб-сервер будет отвечать «без данных», как обычно. Даже 30-секундный цикл сократил бы пустую нагрузку ответа в 15-30 раз.

Предостережение: Я читал об этой реализации, но я не пробовал это сам. Вам нужно будет протестировать совместимость с различными веб-браузерами, чтобы убедиться, что этот довольно нестандартный метод не вызывает проблем на стороне клиента.

Answer 2

Он действительно складывается, но не так сильно, как вы думаете. Если вы проголосуете каждую секунду в течение полного часа, вы использовали бы только 864K, меньше, чем требуется для типичной веб-страницы с непечатанным кешем. Даже если вы сделали это на целый день, вы говорите о ~ 20M. Может быть, если вы кто-то, как Twitter, вам может быть нужно позаботиться об этом, но я сомневаюсь, что вы будете приближаться к трафику, который будет для этого действительно проблематичным.

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