ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cache Revalidate


  • To: nginx-ru@xxxxxxxxx
  • Subject: Re: Cache Revalidate
  • From: "S.A.N" <nginx-forum@xxxxxxxx>
  • Date: Wed, 27 Nov 2013 16:21:37 -0500
  • Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=helium.jlkhosting.com; s=x; h=Date:Sender:From:References:In-Reply-To:Message-ID:Content-Transfer-Encoding:Content-Type:Subject:To; bh=JZPehn68Z8ofADzKxiXg1Ki9y511Im/nktAeSMApPMY=; b=0cKBWfq1A8cjaguY3aXwxtyywr+UaNHisbbDYRbhBwFlcd0sBn1+9Uxp2zKeugXwHwHMFexSTHkmwuIjOsP0dV2PU/6LrAjxwcxSD+HCa92cz2YwaX4gPE4bKLkZpuzx6DeLFpUxvTzYURjlVcVpps3sbPiQ0OVvF/8tLqg4RkY=;
  • In-reply-to: <20131127202255.GU93176@mdounin.ru>
  • References: <20131127202255.GU93176@mdounin.ru>

> use case и о происхождении требования о недопустимости кеширования 
> даже на 1 секунду.  Возможно, это позволило бы пересмотреть 
> существующее поведение при max-age=0, благо в Cache-Control есть и 
> другие способы запрета кеширования.

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

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

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

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

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

Нам не интересно делать задержки в кеше, представте если бы Facebook делал
задержки в отображении, даже если бы на этом форуме были задержки в
отображении написанных постов, все бы конечно смерились но это совсем не
круто.

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

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

Почему бы и нет?

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?21,244991,245024#msg-245024

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.