TightBack361
Club
Ладно. Пойду спать. Перед этим напишу то что в голову взбредёт:
Спокойной ночи.
Текст:
Организация логики простого сайта и веб сервера управляемых кэшем.
Для сборки компьютерных программ часто пользуются make - инструментом который вызывает компиляцию и сборку файлов только если изменились файлы-зависимости. В некотором смысле не файлы которые не были изменены от одной сборки к другой можно считать своего рода "кэшем", хотя "закеширован" был сам результат вычислений. У результатов вычислений есть зависимости и они будут изменены при изменении этих зависимостей. Этот способ организации подходит для создания логики веб сайта или даже http сервера:
Обычно веб-сайты состоят из контента который не очень часто меняется с каждым запросом. Даже в случае форумов страницы меняются не очень сильно. Страницы большей частью могут быть заменены даже статичными html файлами, где каждый тред был сгенерирован один раз, а новые обсуждения добавляли бы новые файлы. Реальные форумы обычно не соответствуют неизменности статических страниц, но относительно близки. Меняться могут скорее некоторые окружающие текст сообщений блоки. Реальная генерация этих страниц может не учитывать их неизменность и страницы собираются "снизу вверх", запрос за запросом, снова и снова, я же предлагаю собирать страницы "сверху вниз".
Cгенерированный документ имеет части, которые могут быть сгенерированы повторно в зависимости от каких-то условий, в свою очередь части могут зависеть от других частей и при изменении этих частей будут перегенерированы зависящие от них части. При запросе учитывается то, изменились ли эти части и условия и если да - эти части генерируются заново и выдаётся страница.
Пример:
При запросе главной страницы пользователя выдаётся сгенерированная страница, пока не встречается блок "аватарка пользователя", которая зависит от имени пользователя, эта условная часть выдаётся конкретному пользователю и её генерация не производилась. Она была соотнесена с аватаркой пользователя в месте, где она была сохранена. После окончания блока выдача снова перешла на ранее сгенерированный вариант, включая старые темы, дойдя до новых тем генерация оказалась устаревшей из-за изменения текста новых тем, что вызывало новую генерацию этого блока.
Возможности:
Страницей которая была сгенерирована может считаться не только страница как таковая, сжатая версия и конкретный ответ веб сервера. Единожды сжатая страница может не пересжиматься, а сохраняться, если её зависимости не были изменены или (в случае оптимизации) управляемо изменены. (Оптимизация может зависеть от блоков которыми манипулирует алгоритм сжатия и возможности частичного сжатия). Конкретный ответ сервера может быть сохранён вместе с управляющими командами и другими атрибутами и выдан без дополнительных условий.
Преимущества:
Меньше запросов к базе, отчасти статическая генерация.
Можно распараллелить более явно, наверное.
Не преимущества:
Не делает ли текущие движки и текущее кеширование что-то подобное?
Не тяжело ли это хранить и выдавать?
Быстро ли это само по себе, если не оптимизировать выдачу отдельно?
Спокойной ночи.
Текст:
Организация логики простого сайта и веб сервера управляемых кэшем.
Для сборки компьютерных программ часто пользуются make - инструментом который вызывает компиляцию и сборку файлов только если изменились файлы-зависимости. В некотором смысле не файлы которые не были изменены от одной сборки к другой можно считать своего рода "кэшем", хотя "закеширован" был сам результат вычислений. У результатов вычислений есть зависимости и они будут изменены при изменении этих зависимостей. Этот способ организации подходит для создания логики веб сайта или даже http сервера:
Обычно веб-сайты состоят из контента который не очень часто меняется с каждым запросом. Даже в случае форумов страницы меняются не очень сильно. Страницы большей частью могут быть заменены даже статичными html файлами, где каждый тред был сгенерирован один раз, а новые обсуждения добавляли бы новые файлы. Реальные форумы обычно не соответствуют неизменности статических страниц, но относительно близки. Меняться могут скорее некоторые окружающие текст сообщений блоки. Реальная генерация этих страниц может не учитывать их неизменность и страницы собираются "снизу вверх", запрос за запросом, снова и снова, я же предлагаю собирать страницы "сверху вниз".
Cгенерированный документ имеет части, которые могут быть сгенерированы повторно в зависимости от каких-то условий, в свою очередь части могут зависеть от других частей и при изменении этих частей будут перегенерированы зависящие от них части. При запросе учитывается то, изменились ли эти части и условия и если да - эти части генерируются заново и выдаётся страница.
Пример:
При запросе главной страницы пользователя выдаётся сгенерированная страница, пока не встречается блок "аватарка пользователя", которая зависит от имени пользователя, эта условная часть выдаётся конкретному пользователю и её генерация не производилась. Она была соотнесена с аватаркой пользователя в месте, где она была сохранена. После окончания блока выдача снова перешла на ранее сгенерированный вариант, включая старые темы, дойдя до новых тем генерация оказалась устаревшей из-за изменения текста новых тем, что вызывало новую генерацию этого блока.
Возможности:
Страницей которая была сгенерирована может считаться не только страница как таковая, сжатая версия и конкретный ответ веб сервера. Единожды сжатая страница может не пересжиматься, а сохраняться, если её зависимости не были изменены или (в случае оптимизации) управляемо изменены. (Оптимизация может зависеть от блоков которыми манипулирует алгоритм сжатия и возможности частичного сжатия). Конкретный ответ сервера может быть сохранён вместе с управляющими командами и другими атрибутами и выдан без дополнительных условий.
Преимущества:
Меньше запросов к базе, отчасти статическая генерация.
Можно распараллелить более явно, наверное.
Не преимущества:
Не делает ли текущие движки и текущее кеширование что-то подобное?
Не тяжело ли это хранить и выдавать?
Быстро ли это само по себе, если не оптимизировать выдачу отдельно?
