Рубрика «cache-control»

День добрый, пятница ясная, бравый молодец иль девица красная!

Можешь мне верить, можешь мне не верить, но начался сей сказ с пары весточек на мою почту электронную и вот такой вот картины, красоты неписанной:

Сказ о том, как я сервер с WP лечил, или 700 юзеров онлайн на 2х ядрах - 1

Это 500 бравых молодцев онлайн (по депеше от гугла) на движке заморском, wordpress именуемом, на сервере Intel Xeon E3 1245v2 (soyoustart, E3-SSD-3). К полотну была приложена рукописъ, помочь в оптимизации сего хозяйства.
Читать полностью »

image
В этой заметке речь пойдет о HTTP-кэшировании (перевод) и его использовании совместно с фреймворком Django. Мало кто будет спорить с утверждением о том, что применение HTTP-кэширования — очень правильная и разумная практика разработки веб-приложений. Однако именно в этом функционале Django содержит ряд ошибок и неточностей, которые очень сильно ограничивают практическую пользу от такого подхода. Например, до сих пор актуален баг #15855, заведенный в апреле 2011 года, который может приводить к очень неприятным ошибкам в работе веб-приложения.

Middleware vs. explicit decorator

В Django есть два стандартных способа включения HTTP-кэширования: через активацию UpdateCacheMiddleware/FetchFromCacheMiddleware, либо через декорирование функции представления при помощи декоратора cache_page. У первого способа имеется один существенный недостаток — он включает HTTP-кэширование для всех без исключения представлений (view) проекта, зато второй содержит тот самый баг #15855. Если бы не этот баг, то вариант с использованием cache_page являлся бы более предпочтительным. Плюс, такой вариант хорошо согласуется с важнейшим из постулатов The Zen of Python, что «явное лучше неявного».Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js