Вступ., Стиснення і кешування, 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. Так
як сервер видає старовину по користувальницької кодуванні він автоматично
постачає ВСЕ сторінки (не тільки динамічні) заголовками заборони кешування.

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 =" для дозволу
кешування сторінок в браузері. Хоча це теоретичне припущення, не
перевірене на практиці.

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