HTTP-заголовки: измененный в последний раз - как это может минимизировать загрузку сервера?
Вообразите следующий вариант использования:
Я использую запрос Ajax на получение некоторой информации о Item и использование этот URL: http://domain/items/show/1
В моей базе данных всем объектам назвали поле modified_at где мы храним момент, когда этот объект был ранее изменен.
Как может Last-Modified HTTP-заголовок сервера в ответ может минимизировать, загружают/уменьшают скорость отклика запросов/увеличения, если мы должны обработать этот запрос каждый раз на стороне сервера? Похоже, что мы не сокращаем количество Запросов HTTP с тем ответом, и мы не уменьшаем нагрузку на сервер.
Кому нужно это так или иначе?
Действительно ли я прав, что это используется главным образом в целях сохранения пропускной способности?
2 ответа
Цель состоит в том, чтобы сэкономить полосу пропускания не на вашем сервере, а на клиенте. Некэшируемые запросы AJAX, вероятно, сделают пользовательский интерфейс невероятно медленным для ваших посетителей, поскольку отсутствие необходимости передавать данные снова и снова резко повышает производительность в браузере клиента.
Если вы хотите уменьшить количество запросов, вы должны установить явный заголовок Expires в ответе. Клиент не будет запрашивать ресурс, пока не истечет время, установленное параметром Expires .
Если ваша реализация всегда будет требовать запросов к базе данных, есть шанс, что внедрение 304 не принесет много пользы. Возможно, вы сэкономите только ресурсы, необходимые для рендеринга ответа. Если рендеринг потребует много обработки, это может быть целесообразно, даже если вам потребуется запрос к базе данных.
Однако, если у вас есть механизм сопоставления uri запроса с датой истечения срока действия без использования базы данных, вы можете заметить большее улучшение времени ответа и экономию ресурсов сервера.
Я реализовал подобный сценарий, кэшируя каждый запрос на диск. Первая строка в файле (названная так, чтобы не требовалось сканирования) содержит метаданные, такие как etag и ttl. Основываясь на времени изменения файла и ttl, хранящихся в нем, я могу, прочитав только одну строку с диска, решить, следует ли мне послать ответ 304 (вернувшемуся клиенту), содержимое файла кэша (новому клиенту или вернувшемуся клиенту, который не видел недавнего рендеринга), или обработать запрос, нормально кэшируя обновленный результат в то же время.
См. этот вопрос для получения дополнительной информации о реализации ответов 304. Является ли моя реализация HTTP Conditional Get ответов в PHP нормальной?