О кешировании и статических страницах

Начну пока рассуждать в конкретных направлениях.

Итак, мысли сейчас такие.

• Каждый объект системы, будь то страница сайта или топик форума может быть (задаётся или разработчиком, в случае страницы, или администратором, в случае форума) разного формата. Например, статику проще всего класть в HTML, динамику - в PHP и т.д.
• По умолчанию для большинства нужд предполагается статический HTML. Всё же, разница в быстродействии, даже при использовании всевозможных акселераторов, порой, идёт на порядки. Особенно, если сервером стоит не Апач, а что-то более скоростное.

Встаёт вопрос адресации этих страниц. Их где-то нужно хранить. Если для форума это не проблема, каждый топик выделяется номером, по этому номеру его и хранить можно, для скорости, ещё и порезав, скажем, на подкаталоги - site.ex/forum/0/1/2/5/012507/ то для сайта всё становится несколько сложнее. Во-первых, я сторонник "человекопонятных URL" ("ЧПУ"). Т.е. чтобы не ничего не значащие цифры в идентификаторе, а нормальное название, пусть и латиницей (хотя было бы хорошо, если бы к моменту завершения системы, большинство серверов по умолчанию поддерживало бы UTF-8, тогда и с национальными символами в URI никаких проблем бы не было - сами URI давно уже в UTF-8 по стандарту). Особенно этот вопрос актуален для меня, т.к. имеется уже развитая структура сайта со множеством ссылок. А потеря имеющихся URL для меня одна из самых больших неприятностей

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

Выход я вижу пока такой: новые страницы располагаются в отведённом им месте, но не в деревьях, а плоско, с нарезкой по MD5 от их "виртуального пути". Т.е. бывшая страница вида "/hangar/russia/soukhoi/su-27" превратится во что-то типа "/cache/a/4/2/c/hangar-russia-soukhoi-su-27/"

(Да, лучше использовать формат с документами по умолчанию, чтобы всегда можно было быстро и безболезненно поменять формат документов, скажем, .shtml на .htm)

При перекомпиляции же будет произведён репарсинг ссылок с их исправлением в новый формат. Для внешних ссылок - ну, тут придётся использовать переадресацию уже скриптом.

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

В общем, решение не столь очевидное.

Ещё одна промежуточная альтернатива - основными ссылками является, всё же, древовидная классическая структура, но обработка ссылок идёт общим скриптом. В общем, как сейчас, за той лишь поправкой, что скрипт не будет заниматься никакими извлечениями из БД и т.п., а будет тупо хешить запрашиваемый URI, получать из него новый URI в кеш и или переадресовывать запрос туда или загружать получившуюся страницу. Во втором случае, кстати, можно ещё кешировать и готовый gzip-пожаты вариант, несколько разгрузив сервер.

Но это всё равно будет медленнее, чем чистая статика.

Ну и, конечно, ещё возможен вариант отброшенный изначально, когда страницы лежат по своим физическим адресам, а вся сложность их обработки (вычистка устаревших и т.п.) ложится на отдельный, периодически запускаемый обработчик :-/