ПРОЕКТЫ 


  АРХИВ 


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]

Изменение процедуры обновления кэша


  • To: nginx-ru@xxxxxxxxx
  • Subject: Изменение процедуры обновления кэша
  • From: "stitrace" <nginx-forum@xxxxxxxx>
  • Date: Sat, 24 Aug 2013 06:29:11 -0400
  • Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=helium.jlkhosting.com; s=x; h=Date:Sender:From:Message-ID:Content-Transfer-Encoding:Content-Type:Subject:To; bh=1Q0HtiL0f7RNpQPqsgvYtFxx5XXwlTl4Wmg0R/UdzNk=; b=PoawSOidu5td6eRMi5kZMCHKtGfLepVDMJTZxlKE3UyzVILE+dM/Fjwn0R+zPSojWxEyR2xvn5QJifRngATgHi0Qi6B8GADaq0Be2UU7nBHsq3WoI/QLzz1pq3WwQHREdTk4+N9r1o5wl347lqmrg0al4Ft77f3KO5Dx+Ye87o0=;

Опишу некоторые, особенности работы модуля PURGE nginx, с которыми я
столкнулся и которые затрудняют его использование в hi-load:

Как известно, механизм purge в nginx призван для управления кэшем,
единственным его предназначением является очистка кэша для необходимого урла
на сайте.

Мы могли бы закэшировать страницу с урлом http:://mysite.ru/main/, к
примеру, на сутки и реализовать в форме отправки сообщения нашего сайта
инициацию запроса http:://mysite.ru/purge/main/, который, при должной
конфигурации, очистит кэш для страницы /main/. На первый взгляд, всё
выглядит идеально и придраться не к чему, но если разобраться, то не так всё
гладко, когда дело касается hi-load. Дело в том, что nginx производит
очистку кэша в таком порядке:

a) После выполнения PURGE запроса он удаляет закэшированную копию страницы
из хранилища.
б) Ждёт сгенерированную, новую страницу от бэкэнда.
в) Отдаёт её пользователю и кладёт в кэш, далее продолжая раздавать её
пользователям.

Всё шикарно, но при выполнении пункта "б" он, если к нему обращается клиент,
не находя страницу у себя в кэше, пропускает все запросы к фронтэнду.

Теперь допустим сценарий, ваша страница /main/ генерируется на бэкэнде 1
секунду и он настроен таким образом, что максимальное количество клиентов на
нём не должно превышать 300. Посещаемость /main/ - 600 запросов в секунду,
каждый новый клиент увеличивает время отработки запроса к фронтэнду на 0.3%.
Мы видим, что, количество клиентов, которые пройдут на бэкэнд, превышает в
два раза разрешённый лимит, а время выполения запроса, в первые полсекунды,
будет расти по экспоненте и скрипт, в лучшем случае, завершит работу через
несколько секунд, а в худшем, бэкэнд вернёт 502 ошибку, из-за ограничений на
время выполнения кода на фронтэнде, то есть, фактически, уронит ваш проект.

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

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

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


 




Copyright © Lexa Software, 1996-2009.