Еще один вопрос по рекомендациям по конфигурированию серверного ПО (Версия документа 4.0.1 от 27.01.2005).
Поясните, пожалуйста, зачем и почему вы рекомендуете использовать две технологии кэширования одновременно (Squid и mod_explires)? В чем вы видите "плюс" при подобной выстроенной системы кеширования?
Владимир пишет: Поясните, пожалуйста, зачем и почему вы рекомендуете использовать две технологии кэширования одновременно (Squid и mod_explires)? В чем вы видите "плюс" при подобной выстроенной системы кеширования?
Речь идет о разных механизмах.
Используя mod_explires, вы получаете возможность установить для графических файлов определенное время кэширования на клиенте. Это означает, что в заголовке ответа веб-сервера при выдаче графических файлов будет указано, что файл можно не обновлять более чем в течение 3 дней, например. Данная установка в основном используется браузерами клиентов, делает работу пользователей комфортнее и позволяет при работе с сайтом уменьшить число обращений к файлам для редко изменяемых графических изображений.
Основная идея использовать прокси для front-office состоит в том, чтобы исключить зависимость от медленных клиентских коннектов и стабилизировать использование памяти бэк-офисом. Front-office принимает запросы от медленных удаленных браузеров клиентов, транслирует запросы в back-office и принимая результирующую страницу буферизирует ее и освобождает процесс back-office. После этого front-office может сколь угодно долго передавать страницу медленному клиенту, потребляя минимальное количество памяти и ресурсов.
Чаще всего front-office правильно обрабатывает параметры кэширования графических файлов, говорящие о том, что их можно кэшировать и не повторяет запросы к бэк-офису. Но это уже второстепенная функция и которая не на всех прокси включена или существует. Еще раз отмечу, что главное в двухуровневой системе - это исключить зависимость от медленных коннектов и стабилизировать расход памяти.
Двухуровневая схема протестирована на нагруженных проектах и дает замечательные результаты при эксплуатации.
"Рассмотрим процесс обработки запроса пользователя к обычной странице сайта. Запрос принимается прокси-сервером, например, по адресу http://www.bitrixsoft.ru на 80 порту, транслируется веб-серверу Apache по адресу http://127.0.0.2:80/ Запрос исполняется веб-сервером Apache. Ответ принимается прокси-сервером, и соединение между прокси-сервером и Apache сервером закрывается, память высвобождается. Прокси-сервер передает готовую сформированную страницу посетителю по медленному каналу. Получив страницу, браузер посетителя посылает последовательно серию запросов на графические элементы и таблицу стилей. Все запросы принимаются прокси-сервером и обрабатываются без обращений к Back-end."
На мой взгляд, здесь есть одно очень важное обстоятельство: кэширующий сервер (squid) должен быть настроен таким образом, чтобы определять динамический контент. Например, когда вид и содержание страницы сайта меняется от того, что пользователь зашел на сайт под своим логином/паролем.
"В некоторых случаях на Front-end политика кеширования настраивается независимо от настроек Back-end."
Я считаю, что в back-end кэширование должно быть вообще отключено. Администратор системы должен получать ВСЕГДА актуальные данные, присутствующие в системе. Что Вы думаете по этому поводу?
Владимир пишет: Я считаю, что в back-end кэширование должно быть вообще отключено. Администратор системы должен получать ВСЕГДА актуальные данные, присутствующие в системе. Что Вы думаете по этому поводу?
Это верно. Но именно так и работает наш продукт и вдухуровневая конфигурация.
Все страницы выдаются с указанием не кэшировать страницу и персональный контент. Прокси-сервер такие страницы не кэширует и каждый раз обращается за ними к бэкофису. Т.е. вы всегда будете пользоваться актуальным контентом.