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

Мысль верная :)

Аккуратнее с репой - мне недавно стока влепили - за обсуждение репы что караул 🙅

Когда оптимизировал производительность своих сайтов, то исследовал различные варианты хранения кэшированных страниц. В ходе исследований выяснилось что процент браузеров поддерживающих кэширование более 75%. Во-вторых, известно что распаковка данных - дешевая операция.

Исходя из этого, было принято решение хранить сжатые кэши страниц в памяти и раздавать их, при необходимости распаковывая. С учетом того, что типичная сжатая страница занимает в памяти не более 10 килобайт, то можно без напряга закэшировать более 10000 страниц. Также следует отметить что при отдаче страницы вебсервер не осуществляет доступа к диску, что позволяет ему обрабатывать поистине фантастическое кол-во запросов в секунду.

Возникли определенные сложности с которыми самостоятельно справиться не смогли :(

Программист написал кеширование и сжатие но вот результат получился странный.

Тех задание было следующее.

Кешировать страницы определенного типа.
Создать систему инклудов. Цель - при полном кешировании страницы некоторые динамические части кешируются "навечно" надо либо регулярно сбрасывать кеш либо динамические части подгружать уже в кеш инклудом. Так же это требуется для интеграции в кеш статистики CNStats.
Решение данной проблеМММы - в нужном месте сайта пишем комментарии. При кешировании все что внутри коментов вырезается и туда устанавливается инклуд.
Вроде продумали все что можно..........

Итого.
Система написана и начали тестирование.
Выяснилось следующее.
При первом посещении страницы она архивируется и кладется в папку кеша повторяющего структуру сайта. При этом в коде удаляются пробелы и чужие коменты.
При втором заходе (внимание) архив распаковывается, в него интегрируются инклуды, они обрабатываются, файл повторно жмется и только теперь отдается посетителю.
То есть при каждом обращении происходят паразитные сжатия и распаковка
Программист аргументирует это тем что "инклуды в архиве не исполняются"
Статистика CNStats интегрирована через инклуд. Тоже странности. Заголовки страниц определяются только на 50 %. Причину понять так и не смогли.

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

Полевые испытания показали что страница из кеша отдается медленнее чем страница запрошенная из БД.

Учитывая то что идут непонятки в системе статистики у меня возникло подозрение что кеш вообще может отдаваться не корректно, что чревато трудностями с поисковиками

Еще непонятный момент. Первично программист для обработки (сжатия как я понимаю) использовал функцию gzinflate . На сервере файлы кеша вообще лежали без расширений. Вчера переписали для сжатия в gzip

Вопрос.

• Имеет ли право на жизнь реализованная схема с двойной операцией архивирования в момент отдачи пользователю?
• Существуют ли иные способы корректно вставить и отдать инклуд в кеше?

Deni,

изобретаете какой-то 6 колесный велосипед с двумя дизельными двигателями.

помоему абсолютное непонимание задачи и методов ее решения.

Bor-ka, Изобретаю не я а программист :)

И в компетенции его я уверен и она проверялась многократно......... но тут что то "не то" пошло.......

У Вас есть алгоритм двухколесного велосипеда с педалями (мопЕд не предлагать) для реализации таких задач с инклудами?

Deni,

ну прикиньте, есть ПХП-страничка, которая инклудит что то там и отдает данные в поток.

Вы, вместо того, чтобы PHP дать нормальный код, сжимаете код, пишите в файл. Потом открываете его, распаковываете, видимо еще сохраняете его куда то, потом инклудите. вопрос - ЗАЧЕМ лишние действия, gzip явно использует какую либо модификацию LZ-алгоритма, а это все таки нагрузка на систему.

я конечно могу говорить ламерские вещи...... уж простите далек от программирования.

Дело в том что в кеше страницы хтмл и в них как Вы знаете инклуды не работают.

Насколько я смог осознать написанный алгоритм :

• На сервере хтмл страница в архиве
• При обращении распаковывается, вставляется файл инклуда, обрабатывается инклуд(ну там передаются заголовки или еще что), архивируется.
• архивом отдается пользователю

Насколько я понял если не "обрабатывать" инклуд то он просто не сработает в момент открытия в браузере клиентом

Deni, либо вы либо программист неправильно поняли суть кэширования :)

Все должно быть очень просто. Иначе толку от кэша не будет. Я в свое время когда над этим думал, пытался сделать сложно, да только толку от этого оказалось мало. В итоге пришел к следующим выводам:

1. Страницы надо кэшировать полностью, и желательно в БД, чтобы запрос был только один и никаких открываний файлов и прочего.

2. Самый быстрый и надежный метод определения "тухлости" кэша - датчик изменения содержимого - то есть например при редактировании статьи - при сохранении кэш всего сайта обнуляется. Этот вариант конечно слабо подходит для новостных сайтов с большим количеством постоянных изменений, однако при обширной аудитории думается не будет лишним показать даже 30 посетителям версию из кэша - до следующего обновления. Пытаться отслеживать какие страницы конкретно изменились слишком сложно, хотя тут конечно зависит от внутренней структуры движка сайта.

3. Храните лучше не сжатые версии страниц - думается процедура сжатия съест много меньше ресурсов чем чтение двух файлов или запрос к БД, а экономия места на диске бесполезна. Хотя если места много, запросто можно хранить две версии.

Deni, а зачем Вы изобретаете велосипед? есть же нормальные CMS-системы с кэшированием.

Хм......... вы предлагаете плюнуть на все, закрыт несколько крупных проектов с трафиком около 15 тыс в сутки, перенести сайты на другой , непонятно какой движек, полностью сменить структуру сайта , заставить все поисковики заново пере индексировать более 300 тысяч страниц?

В принципе Вы предложили легкое и главное эффективное решение :)
Только адекватно ли данное решение?

Vimsite,

Само собой система сброса кеша редактированной страницы написана и прекрасно работает - открыл страницу в движке для редактирования, файл кеша этой страницы удалился. Это самый простой момент.

О том где лучше хранить файл кеша в БД иди на диски это все же спорный достаточно вопрос. Тут думаю даже единого мнения нет.