Многие ответы HTTP 304 приводят к меньшему количеству запросов GET - PullRequest
Новая
       6

Многие ответы HTTP 304 приводят к меньшему количеству запросов GET

0 голосов
/ 12 ноября 2018

У меня есть сервер разработки Django, на котором размещена веб-страница, на которой в реальном времени (ish) отображается информация, собранная с многочисленных серверов, за которыми я слежу.Эта веб-страница все еще находится в разработке, поэтому в настоящее время я использую встроенный веб-хост, поставляемый с Django, запущенный на хосте Ubuntu с:

python3 manage.py runserver IP:Port

В той же самой UbuntuНа хосте есть сценарий Python, который непрерывно обращается к отслеживаемым серверам и форматирует ответы в файл .html, который клиент перезагружает в течение <div> каждую минуту.Основные функциональные возможности страницы, к которой клиент обращается, следующие: 

<div id="status" style="width:100%; height: 1000"></div>
<script>
    $('#status').load("{% static 'alerts/status.html' %}");
    setInterval(function() {
        $('#status').load("{% static 'alerts/status.html' %}");
    }, 60000);
</script>

... поэтому страница загружает файл status.html в пределах подразделения при загрузке страницы, а затем перезагружает его каждую минуту.Это прекрасно работает, однако, я заметил, просматривая журнал Django, что если status.html не изменился после десяти ответов о состоянии 304 (не изменено), время ожидания между запросами начинает сокращаться.То есть вместо того, чтобы ждать 1 минуту, он ждет 2 минуты, затем 5 минут и т. Д. (Грубо, я забыл фактическую скорость спада).

Теперь проблема, с которой я сталкиваюсьто, что мой сервер вышел из строя в выходные дни (не связано), но экран дисплея, на котором я держал веб-страницу, остался активным, поэтому он так сильно упал, что кажется полностью сломанным, отказываясь загружать последнюю версию status.html.Даже когда я заставляю Chrome перезагружать все и не использовать кеш (ctrl + R или shift + F5).

Я пытался исследовать этот спад, но не смог найти никакой информации о нем.Я предполагаю, что это что-то встроенное в Google Chrome (браузер, который я использую), чтобы сохранить пропускную способность, когда страница не меняется, но моя страница состояния занимает не более пары килобайт, а 304 ответа уже экономят небольшую пропускную способность, что, еслиесть способ полностью отключить этот спад для производства, который был бы идеальным.

В любом случае, любая информация о том, почему я вижу это поведение / откуда оно исходит, будет высоко ценится, поскольку я не могу найти какую-либо документацию по нему.Самая близкая вещь, которую я нашел, была из документации разработчика Google по кэшированию здесь .В нем упоминается возможность определять максимальный возраст и поведение без кэширования, поэтому я мог заставить клиента перезагружать файл status.html каждую минуту, но это кажется грязным.Хотя в моем конкретном сценарии это сработало бы, учитывая, что status.html составляет не более пары килобайт, простое отключение этого режима свертывания сделало бы уловку , а снизило бы ненужную пропускную способность.

Ответы [ 2 ]

0 голосов
/ 13 ноября 2018

Проблема здесь в том, что ответ для status.html не имеет явного заголовка срока действия кэша.В отсутствие такого заголовка браузер может использовать свой собственный алгоритм (например, наблюдаемый вами спад), чтобы выбрать время истечения.Начиная с RFC 7234 :

Поскольку исходные серверы не всегда предоставляют явное время истечения, кеш МОЖЕТ назначать эвристическое время истечения, если явное время не указано .... Этоспецификация не предоставляет конкретные алгоритмы.

Таким образом, решение является простым: назначить явное время истечения срока действия кэша.

Реализация этого решения, к сожалению, не тривиальна с использованием приложения staticfiles от Django.Лучшее значение по умолчанию для этого приложения - вообще не кэшировать результаты, но это решение было отложено в ожидании слияния с whitenoise .

Решения включают использование другогосервер (например, nginx);используя другое приложение (например, whitenoise);или используя статические представления напрямую, а не приложение staticfiles (см. этот вопрос для нескольких подходов).

0 голосов
/ 12 ноября 2018

Попробуйте это: 

// Page reload every 60 seconds
setInterval(function(){
    location.reload();
}, 60000);
...