Вступ., Стиснення і кешування, PHP, статті

Для оптимізації роботи з мережею використовується механізм збереження один раз
отриманих по HTTP документів у кеші з метою їх повторного використання без
звернення до сервера-джерела. Документ, який було збережено в кеші буде доступний при
наступному звертанні до нього, без вивантаження із сервера-джерела, що покликано
підвищити швидкість доступу клієнта до нього й зменшити витрата трафика мережі.

Самі кеші буваю двох видів – локальні та загальні. Локальний це кеш, що зберігається
безпосередньо на диску у клієнта, створюваний і керований його браузером.
Загальний – кеш проксі-сервера організації або провайдера і може складатися з одного
або декількох проксі-серверів. Локальний кеш присутній, напевно в кожному
браузері, загальними користується значна частина людей використовують Internet. І
якщо малу частину сайтів зараз оцінюють по витраті трафіку, то швидкість
завантаження – важливий критерій, який повинен враховуватися при розробці Вашого
web-проекту.

Для динамічних сторінок, що створюються в результаті роботи PHP-програми,
здавалося б, кешування шкідливо. Зміст сторінки формуються за запитом
користувача на основі будь-якого джерела даних. Однак, кешування може
бути корисним. Керуючи їм Ви можете зробити роботу з Вашим сервером комфортніше
для користувача, дозволяючи завантаження з кеш певних сторінок, запобігаючи
тим самим їх повторну вивантаження з Вашого сервера і заощаджуючи користувачеві час і
трафік.

Кешувати чи ні?


Можливість збереження в кеш сторінки визначається динамічністю інформації в
джерелі даних. Таким чином необхідність використання кешу визначається
Вами, виходячи з планованого часу життя сторінки.

Якщо мова йде про формування вибірки по базі (наприклад, пошук введеного
користувачем слова), то таку сторінка обов'язково слід запитувати з
сервера при кожному виклику без використання кеш, оскільки кількість варіантів
запитуваних слів величезна, а якщо ми до того ж маємо справу з мінливим масивом
даних, то кешування безглуздо. Або мова йде про формування допустимо
графіка приходять відвідувачів (який змінюється з кожним візитом, тобто
практично з кожним викликом), то кешування вже просто шкідливо.

Однак, якщо ми говоримо про те ж графіку але за вчорашній день, то кешування
рекомендується, оскільки дані змінюватися вже не будуть і ми можемо економити собі
і користувачеві ресурси і час на завантаження таких сторінок приміщенням в
локальний чи загальний кеш. Як продовження цієї ситуації формування графіка не в
реальному масштабі часу, а щогодини. Тут Ви можете заздалегідь передбачити дату
закінчення "строку придатності" сформованих даних.

Загальні принципи збереження сторінок у кеш.


PHP-програма може керувати кешуванням результатів її роботи формуючи
додаткові поля в заголовку HTTP відповіді викликом функції Header ().

Кілька загальних тверджень характерних не тільки для PHP-програм:


  • Сторінки надіслані через POST ніколи не зберігаються в кеш.
  • Сторінки запитувані по GET і містять параметри (в URL присутній
    "?") Не зберігаються в кеш, якщо не вказано інше.

Таким чином у більшості ситуацій додаткових інструкцій у програму
додавати не треба. Основні моменти на які слід звернути увагу можна
звести до двох:


  • заборона кешування документів, кешируємой за замовчуванням
  • кешування документів, що не підлягають кешуванню за замовчуванням.

Заборона кешування документів, кешируємой за замовчуванням

Це завдання виникає для PHP-скриптів викликаються без параметрів або
є індексами директорій, однак формують дані персонально під
користувача (наприклад на основі cookies або user agent) або працюють на
основі швидко змінюються даних. По специфікації HTTP/1.1 ми можемо управляти
наступними полями:


  • Expires – Визначає дату закінчення терміну придатності документа. Завдання її
    в минулому визначає заборону кеш для даної сторінки.
  • Cache-control: no-cache – Управління кеш. Значення no-cache
    визначає заборону кеш цієї сторінки. Для версії протоколу HTTP/1.0 діє
    “Pragma: no-cache”.
  • Last-Modified – Дата послднего зміни вмісту. Поле актуально
    тільки для статичних сторінок. Apache замінює це поле значенням поля Date для
    динамічних сторінок, у тому числі для сторінок містять
    SSI.


    На сайті www.php.net дається наступний код для заборони кешування.

    header ("Expires: Mon, 26 Jul 1997 5:00:00 GMT"); / / Date in the past
    header ("Last-Modified:". gmdate ("D, d MYH: i: s"). "GMT"); / / always modified
    header ("Cache-Control: no-cache, must-revalidate"); / / HTTP/1.1
    header("Pragma: no-cache"); // HTTP/1.0

    Однак, я вважаю, що даний заголовок надмірний. У більшості випадків
    достатньо:

    header("Expires: Thu, 01 Jan 1970 00:00:01 GMT");

    Щоб позначити документ як "вже застарілий" слід встановити Expires
    рівним полю Date.

    header ("Expires:". gmdate ("D, d MYH: i: s"). "GMT");

    Ну і не слід забувати, що форми, запитані по POST також не підлягають
    кешуванню.

    Кешування документів, що не підлягають кешуванню по
    замовчуванням


    Зворотній завдання, може здатися на перший погляд абсурдною. Однак і в цьому
    існує потреба. Крім простий мінімізації трафіку при розробці
    web-програми слід враховувати комфортність роботи з нею користувача.
    Наприклад, деякі сторінки Вашого сервера формуються на основі статичних
    даних великого обсягу. Можливість включення їх в кеш істотно поліпшить
    швидкість роботи сервера для користувача і частково звільнить Ваш від
    численних повторних генерацій такої сторінки. Тема дозволяє
    збереження на проксі-серверах:

    header("Cache-control: public");

    Якщо сторінка враховує інформацію збережену в браузері користувача (тип і
    версію браузера, ключі, авторизацію і т.д.) таку сторінку не можна зберегти на
    проксі, однак можливо її збереження в локальному кеш браузера:

    header("Cache-control: private");

    Кешування до закінчення коректності


    Описані вище рішення досить прямолінійні, хоча і підходять для більшості
    задач. Але протокол HTTP/1.1 має кошти для більш тонкого управління кеш
    сторінок, і існують завдання вимагають застосування цих механізмів. Як приклад –
    web-додатки працюють з даними великого об'єму і прогнозованою
    динамічністю. Коректність даних може встановлюватися як за датами
    прогнозованого оновлення, так і по зміні змісту. Для цих випадків
    використовуються різні заголовки управління кеш.

    Кешування з прогнозованим оновленням


    Розглянемо приклад – прайс лист оновлюваний по понеділках. Ви заздалегідь
    знаєте, що зміст сторінки можна зберігати в кеш до настання нового тижня,
    що і слід вказати в заголовку відповіді забезпечуючи потрібне поведінку сторінки в
    кеш.

    Основне завдання – отримати дату наступного понеділка у форматі RFC-1123

    $dt_tmp=getdate(date("U"));
    header ("Expires:". gmdate ("D, d MYH: i: s",
    date ("U") – (86400 * ($ dt_tmp ["wday"] -8))). "GMT");
    header("Cache-control: public");

    Цим методом можна ефективно керувати поведінкою сторінки в кеш і пременно
    але для великого числа сторінок – так чи інакше можна виділити тимчасові інтервали
    протягом яких вміст сторінки залишається постійним. Реальний стан
    речей такий, що сторінки більшості динамічних сайтів мають певний
    час життя виходячи з которго розробник може сераер більш приємним для
    роботи.

    Інший підхід, який застосовується при більш оперативному оновленні інформації і
    одночасної високої відвідуваності сервера (інакше кешування не буде
    ефективним) полягає у використанні заголовка Cache-control: max-age = секунди,
    визначає час після якого документ вважається застарілим і має
    більший пріоритет при обчисленні "свіжості" документа.

    Якщо Ви публікуєте новини з інтервалом в 30 хвилин:

    header("Cache-control: public");

    header("Cache-control: max-age=1800");


    Кешування з утримання


    Ще більш інтелектуальний вид управління надає HTTP/1.1 на основі
    вмісту за допомогою директив Vary. Я дуже рекомендую застосовувати його при
    формуванні зображень або текстів великого об'єму, які як показує
    практика змінюються вкрай рідко. При цьому у користувача в разі повернення не
    буде відбуватися їх повторної вивантаження, якщо зміст залишився колишнім, і
    сторінка буде взята з Вашого сервера, якщо її зміст змінилося.

    Розглянемо приклад видачі зображення з бази даних індентіфіціруемих по ID.
    Виклик сторінки виглядає наступним чином:

    http://www.your.server/viewpic.php3?id=23123

    а значить за правилами сторінка не буде зберігатися в кеш (присутні
    параметри), але через заголовок можна управляти цим.

    mysql_connect ("host", "user", "passwd");
    $ Image = mysql ("db", "select pics, type from pictures where id = $ id");

    Header("Cache-Control: public, must-revalidate");
    Header("Vary: Content-ID");
    Header ("Content-ID:". Md5 (mysql_result ($ image, 0, "pics ")));

    Header ("Content-type:". Mysql_result ($ image, 0, "type"));

    echo mysql_result($image, 0, "pics");
    mysql_freeResult($image);
    mysql_close();


    Для управління використовується MD5 сума вмісту зображення. Поки
    зміст не змінилося, сума буде постояной. У разі зміни вмісту в
    базі на сервері клієнт виконає запит для повторного формування змісту.
    Поки зображення постійно вміст буде відображатися з кеш.

    Примітки для Russian Apache


    І приємне (або неприємне) повідомлення для користувачів Russian Apache. Так
    як сервер видає старовину по користувальницької кодуванні він автоматично
    постачає ВСЕ сторінки (не тільки динамічні) заголовками заборони кешування.

    Expires: Thu, 01 Jan 1970 00:00:01 GMT

    Так що всі сторінки не кешируємой. Формування в скрипті заголовка Expires
    ефекту не має. Навіщо це зроблено і деякі методи боротьби описані на
    apache.lexa.ru і немає необхідності відтворювати ці поради тут. Розглядаючи
    роботу PHP + Russian Apache от як можна вплинути на кешируємой.

    Для скриптів виводять зображення ситуація проста – Russian Apache НЕ
    перекодує (а значить не устанавліваетсрок закінчення придатності) документи
    мають MIME тип image / *. Для використання кеш текстових документів мабуть
    слід використовувати "Cache-control: private, max-age =" для дозволу
    кешування сторінок в браузері. Хоча це теоретичне припущення, не
    перевірене на практиці.

    Що слід прочитати




    Даний документ поки не можна вважати закінченим. Залишилися не розглянутими
    деякі заголовки впливають на правила обчислення "свіжості" документа. Так само
    приймаються будь-які коментарі, доповнення або повідомлення про помічені
    помилках.

    Схожі статті:


    Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

    Коментарів поки що немає.

    Ваш отзыв

    Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

    *

    *