Каталог статей
Поиск по базе статей  
Статья на тему Интернет » Интересное в сети » Кешируем свой сайт

 

Кешируем свой сайт

 

 

Наверняка, гуляя по Интернету, вы замечали, что одни сайты работают быстрее других. В некоторых случаях это не очень критично, в других — весьма заметно: мне как-то попался сайт, на котором каждая страница грузилась минуты по три, причем он вовсе не был гигантским... С другой стороны браузера — у веб-мастеров — тоже возникает куча проблем: серверу постоянно не хватает ресурсов, посетители жалуются на недогруженные страницы, трафик тратится непонятно на что... Разумеется, не существует единого универсального рецепта, позволяющего решить все эти проблемы, но есть некие механизмы, позволяющие снять хотя бы часть подобных им. И одним из таких механизмов является кеширование.

загрузка...

 

 

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

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

Когда посетитель запрашивает какой-то документ, то сначала опрашивается кеш, и если прокси-сервер находит у себя копию запрошенного документа, то он решает, отдавать ли ее или запросить новую версию у вашего сервера. Если документ не обнаружен, то прокси-сервер забирает документ с вашего сервера, передает посетителю, а копию помещает в свое хранилище. И при следующем запросе отдаст посетителю (возможно, другому) уже локальную копию.

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

Для того чтобы указать, что именно можно или нельзя кешировать, используются заголовки HTTP-протокола и META-теги в заголовке документа (не надо их путать!). META-теги, в основном, проверяются браузером и помогают ему решить, можно ли кешировать полученный документ. HTTP-заголовки, в основном, служат для управления прокси-серверами. Я не зря написал «в основном» — дело в том, что, как и в большинстве других компьютерных областей, в кешировании, во-первых, нет жестких правил (недаром, все документы, регламентирующие работу Интернета, называются RFC: Request For Comment), а есть только рекомендации; во-вторых, очень многое зависит от администратора прокси-сервера, который может либо сознательно, для каких-то своих целей, либо по ошибке настроить свой прокси каким-то «хитрым» способом; в-третьих, не исключены ошибки реализации самих прокси-серверов и т.п. Так что, настраивая свой сервер на оптимальную работу с различными кешами, вам придется задействовать сразу несколько механизмов управления, но при этом нужный результат не будет гарантирован. Хотя, пожалуй, в 95% случаев все будет работать именно так, как вы задумали.

Первое правило. На любом, даже самом динамическом сайте всегда есть статичные файлы. Это, например, таблицы стилей, картинки навигации, логотип, страница «о компании» и т.д. и т.п. Есть смысл постараться загнать все это дело в кеш — от этого все только выиграют. Поэтому стоит, во-первых, на всех страницах использовать одну и ту же копию картинки и указывать один и тот же адрес. В частности, если ваш сайт имеет несколько адресов (например, /redir.php?url=mycompany.ru и /redir.php?url=www.mycompany.ru%29%2C то есть смысл на страницах прописывать, скажем, <img src="/redir.php?url=mycompany.ru%2Fimg%2Flogo.gif"> На первый взгляд, экономия не очень значительная, но для популярных сайтов она оказывается вполне заметной.

META-теги оказывают влияние на кеширование ваших страниц в браузере посетителя. В большинстве браузеров пользователь может указать, как часто должна проверяться «свежесть» страниц: один раз для сессии (пока браузер не будет закрыт) или пока не истечет «время жизни» документа, или еще как-то. Браузеры особенно активно работают с кешированием (что не удивительно и правильно), поэтому чаще всего здесь возникает задача запретить (или ограничить) кеширование каких-то отдельных документов. Наиболее полезными здесь оказываются теги Expires и Pragma no cache. Например, для регулярно обновляемой страницы новостей можно указать, скажем, <meta http-equiv="Expires" content="Thu, 08 May 2003 08:37:25 GMT">, установив дату минут на 5-10 вперед от времени запроса. Если же требуется совсем запретить кеширование, то стоит прописать:
<meta http-equiv="Expires" content="0">
<meta http-equiv="Pragma" content="no-cache">
Это, по идее, должно сработать. Также можно Expires установить на какую-то дату в прошлом, но ноль является более правильным решением.

HTTP-заголовки являются наиболее мощным, но и несколько более сложным в использовании инструментом.

В отношении кеширования наиболее важным является, пожалуй, Expires, который, как и в META-теге, указывает, когда кешированная копия устареет. Если значение заголовка Expires отличается от требуемого формата (дата по Гринвичу), то большинство прокси будут считать, что документ устарел, и кешировать его не станут. Часто для этих же целей Expires устанавливается на дату в прошлом. Это не противоречит RFC2616, но некоторые прокси-сервера считают такой ответ неправильным, отбрасывают заголовок и применяют к документу правила кеширования по умолчанию. Поэтому, если вы не хотите, чтобы документ кешировался, то лучше установить Expires в ноль, или, скажем, на одну секунду вперед.

В HTTP 1.1 появились специальные заголовки Cache-Control, которые позволяют более тщательно работать к кешированием. Там есть довольно много вариантов, из которых я бы посоветовал обратить внимание на тэги: 
max-age, который позволяет указать количество секунд, в течение которого результат считается «свежим» (очень полезно для динамических сайтов, на которых информация меняется не все время, а, скажем, раз в несколько минут);
no-cache, который приказывает прокси-серверу перед тем, как отдать клиенту скешированный документ, запросить подтверждение его «свежести» у вашего сервера (это позволяет одновременно гарантировать, что результаты актуальны, и пользоваться преимуществами кеширования);
must-revalidate, который приказывает прокси-серверу слушаться ваших указаний насчет «свежести» документа, а не использовать свои предположения и алгоритмы.

Одним из наиболее популярных заголовков является Last-Modified, указывающий на время последнего изменения документа. Если этот заголовок был указан, когда документ кешировался, то прокси, обращаясь к вашему серверу, может указать в запросе "If-Modified-Since", и в том случае, если документ не изменился, вашему серверу достаточно отправить код 304, не пересылая сам документ.

В HTTP 1.1 появился еще один полезный заголовок — ETag. Он представляет собой уникальный идентификатор документа, который генерируется вашим сервером и автоматически меняется при изменении документа. Таким образом значительно облегчается проверка документа на «свежесть» — достаточно просто сравнить ETag'и на сервере и на прокси.

За выдачу HTTP-заголовков для статичных файлов отвечает сервер, поэтому стоит почитать его документацию и посмотреть, что именно он будет говорить о разных типах файлов. В частности, для «Русского Апача» я бы посоветовал обратить внимание на директиву препроцессора EPOCH_EXPIRES (используется при компиляции сервера), а также на директивы CharsetOverrideExpires, CharsetDisableForcedExpires и CacheNegotiatedDocs в файле конфигурации. А заодно и на mod_expires и mod_headers.

Для того чтобы проверить, насколько хорошо ваш сайт может кешироваться, попробуйте воспользоваться, например, он-лайновым сервисом Cacheability.

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

Ссылки по теме




Статья получена: hostinfo.ru
загрузка...

 

 

Наверх


Постоянная ссылка на статью "Кешируем свой сайт":


Рассказать другу

Оценка: 4.0 (голосов: 16)

Ваша оценка:

Ваш комментарий

Имя:
Сообщение:
Защитный код: включите графику
 
 



Поиск по базе статей:





Темы статей






Новые статьи

Противовирусные препараты: за и против Добро пожаловать в Армению. Знакомство с Арменией Крыша из сэндвич панелей для индивидуального строительства Возможно ли отменить договор купли-продажи квартиры, если он был уже подписан Как выбрать блеск для губ Чего боятся мужчины Как побороть страх перед неизвестностью Газон на участке своими руками Как правильно стирать шторы Как просто бросить курить

Вместе с этой статьей обычно читают:

Как выбрать хостинг для своего сайта

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

» Интересное в сети - 2457 - читать


«Динамим» свой сайт

Необходимое вступление: ни в коей мере не хочу сказать, что являюсь (или считаю себя) «гуру» в области администрирования сервера, настройки баз данных и т.п. Просто, возясь со своим сайтом вот уже более семи лет и пройдя практически все этапы от сделанной на коленке и вручную обновляемой домашней странички до собственного сервера с динамическим сайтом, накопилось много заметок о всевозможных «граблях» по которым я уже прошел (а также некое видение тех ...

» Интересное в сети - 1343 - читать


Размещаем RSS-новости на&nb p;своем сайте

Мы с вами разобрали, что такое RSS, как создаются такие рассылки, как к ним можно подключиться и читать их. Осталось разобрать два момента — автоматизацию формирования фидов (в предыдущей статье мы говорили о ручном способе их формирования) и размещение чьих-либо новостей, полученных по рассылкам RSS на своем сайте. Вот об этих вопросах мы с вами и поговорим в сегодняшней статье.

» Интересное в сети - 3574 - читать


Как привлечь посетителей на свой сайт

© ИА Клерк. Ру, аналитический отдел / Недавно ИА «Клерк.

» Безопасность бизнеса - 10524 - читать


В ногу со временем: открываем свой сайт

Материал предоставлен журналом "Практическая бухгалтерия" / Т. Аверина, эксперт ПБ Любая фирма заинтересована в росте объема продаж. Поэтому желание руководства, чтобы о товарах, работах или услугах компании узнало как можно больше людей, вполне понятно.

» Бухгалтерия и аудит - 1288 - читать



Статья на тему Интернет » Интересное в сети » Кешируем свой сайт

Все статьи | Разделы | Поиск | Добавить статью | Контакты

© Art.Thelib.Ru, 2006-2024, при копировании материалов, прямая индексируемая ссылка на сайт обязательна.

Энциклопедия Art.Thelib.Ru