Кеширование страниц сайта

Да, какой-то странный кэш.

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

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

Но всегда можно прикрутить частичное кэширование и в общем решить проблему нагрузки.

Вместо кэширования готовых HTML блоков, можно кэшировать данные для их отображения.

Если есть тяжелые запросы к БД, тоже необходимо их оптимизировать(индексы, графы, мемкеши).

Сжатие страницы на веб-сервере - это грубая ошибка, тупое убивание процессорного времени, высвобожденного за счет кэширования.

Если сильно охота экономить трафик, то это делается специально настроенным внешим акселератором-балансировщиком в кластере серверов.

Где хранить: в памяти, на диске, в бд - зависит только от архитектуры и особенностей системы, а не от чьего-либо личного мнения или предпочтения!

ну а перед тем как делать все это хозяйство, Вы думали как оно будет работать? Если такое творится с кэшированием, страшно представить что творится в остальном коде.

Dash, Само собой сложно навешивать что то глобальное на работающий проект.

По этой причине мы и не стали все страницы кешировать. Часто обновляемые оставили из БД. Или раздел Статьи выставляем жизнь кеша на 72 часа а листинг статей на 12.

Но например в Статьях есть внизу "Похожие статьи"

Они очень неплохо помогают индексации всего сайта и кешировать их навечно неразумно. Именно их планировали в кешированной странице выводить инклудом через один запрос к БД

Или геморрой со счетчиком :(

На счет раздельного кеширования различных блоков страницы идея очень интересная. Почему это не реализовал программист неизвестно :( Либо это шибко сложно либо затратно для сервера. Хотя......... он писал по нашему ТЗ и мы не зная всех нюансов программирование это и не предлагали...

Трафик собственно как и место на сервере пока не лимитировано и на это акцент не делали совсем.

Извините , у Вас есть конструктивные предложения? Или Вы только предлагаете не изобретать велосипед?

Перед тем как писать ТЗ да мы думали. Но не в компетенции заказчика писать в ТЗ нюансы программирования и то что и какими функциями выполнять. Это задача программиста (хорошо оплачиваемого программиста кстати) анализировать алгоритм и отказываться от выполнения если алгоритм противоречит каким либо стандартам или создает недопустимую нагрузку на сервер.

У меня совершенно нет желания обсуждать компетентность исполнителя.

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

Очень частая ошибка при разработке софта: техническое задание пишется неспециалистом(заказчиком). А должно писаться специалистом(далеко не программистом) по согласованию с заказчиком.

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

Кстати, ваше ТЗ яркий пример: вы оперируете сугубо техническими терминами, не до конца осознавая их смысл(инклуды, кеш, описан способ контроля кэширования).

Программист их понял буквально, хотя ему стоило подумать об альтернативных решениях.

я предлагаю не изобретать велосипед и взять вменяемого программиста.

хочу то, не знаю что. вот и написал программист "кэш".

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

Где Вы видели заказчика, пишущего ТЗ? это не ТЗ, а функциональная спецификация (с) в самом лучшем случае. в худшем случае - пол страницы несвязного текста - "хочу яндекс, бюджет 5к" 😂, но это уже небольшой оффтоп пошел :)

Заказчик пишет что он хочет получить в итоге.

А вот пути реализации как раз и должен обдумывать и анализировать исполнитель

Полностью согласен. Но часто разработка начинается прямо по этой спецификации.

Ибо цейт-нот, а разработка ТЗ, архитектуры - это время и деньги.

Bor-ka,

Скажем так........ Данный человек проверен временем и другими достаточно сложными проектами. Но согласитесь что даже очень профессиональный програмист может "плавать" в отдельных вещах. Ну не приходилось например никогда писать кеширование (как пример)

Я описал ошибки с точки зрения ламера (меня)

Согласитесь что более "знающие" товарищи могут считать это не ошибками а правильным алгоритмом.

Например если иначе невозможно в кеш подгрузить инклуды то очевидно надо жертвовать процессорным временем.

PS Интересный для меня все же вопрос. Напомню что первично сжатие было написано через функцию gzinflate

Данную функцию реально используют в системах кеширования или же это ошибка разработчика и его неправильное понимание системы кеширования?

У вас неправильный кеш 🙄

Сжатие вообще не имеет никакого отношения к кешированию.