Кеш (Cache)
Продуктивність веб-сайтів та програм можна значно підвищити за рахунок повторного використання раніше отриманих ресурсів.
Кешування (або кеш) - це проміжний буфер, в якому зберігаються дані. Завдяки кешування сторінка сайту не відтворюється наново для кожного користувача. Кешування дозволяє здійснювати роботу з великою кількістю даних у максимально стислий термін і при обмежених ресурсах (серверних та користувальницьких).
Необхідно розуміти, що роботу з даними можна виконувати як на стороні клієнта, так і на сервері. До того ж, серверна обробка даних централізована і має низку безперечних переваг (особливо для служби підтримки).
Категорії кешів :
Приватний кеш браузера: призначений для окремого користувача. Ви, можливо, вже бачили параметри кешування у налаштуваннях свого браузера. Кеш браузера містить усі документи, завантажені користувачем HTTP. Він використовується для доступу до раніше завантажених сторінок під час навігації назад/вперед, дозволяє зберігати сторінки або переглядати їх код, не звертаючись зайвий раз до сервера. Крім того, кеш корисний при відключенні від мережі.
Загальний проксі-кеш: це кеш, який зберігає відповіді, щоб їх потім могли використовувати різні користувачі. Наприклад, у локальній мережі вашого провайдера або компанії може бути встановлений проксі, який обслуговує безліч користувачів, щоб можна було повторно використовувати популярні ресурси, скорочуючи тим самим мережевий трафік і час очікування.
Види кешування :
1. Браузерне кешування або клієнтське кешування
Є складанням для браузера команди використовувати наявну кешовану копію. Робота такого кешування заснована на тому, що при повторному відвідуванні, браузеру віддається заголовок 304 Not Modified, а сама сторінка або картинка завантажуються з локального кешу. Виходить, що ви заощаджуєте на трафіку між браузером відвідувача та хостингом сайту. Відповідно, сторінка вашого сайту починає завантажуватись швидше.
1.1 Кешування файлів та картинок
Браузерне кешування якнайкраще підходить для сайтів, що містять велику кількість зображень: картинка не завантажується щоразу при відкритті сайту, а просто завантажується через кеш браузера. Це перший рівень кешування, який полягає у віддачі заголовка expired і заголовка 304 Not Modified. Найбільш ефективним вважається кешування на 2 тижні. Проте в даному випадку є важливий нюанс: якщо зображення на сайті змінюється, то браузер дізнається про це не відразу, а лише якщо почекати expiry або скинути кеш у самому браузері. Це не дуже ефективно, якщо файл постійно змінюється і необхідно віддавати його актуальну версію.
1.2 Кешування https
Спеціальні заголовки виду strict-security. Дозволяє браузеру завжди звертатися по https до вибраного домену. Зберігає цей стан досить жорстко і, у разі скасування цього виду кешу, браузер ще досить довго намагатиметься завантажити сторінку https, при цьому ігноруючи поточні заголовки.
1.3 Кешування центру сертифікації
Так званий, stamp центр сертифікації.
Даний вид кешування вважається обов'язковим для застосування, якщо ви не хочете, щоб користувачі вашого сайту чекали, коли центр сертифікації (а це сервер, який відповідає за достовірність вашого сертифіката) опрацює запит від браузера користувача і підтвердить, що ваш сайт дійсно підтверджений ним.
1.4 Кешування сторінок
Коли сторінку вже згенеровано, потрібно постійно відстежувати її актуальність. Для цього ви повинні використовувати серверний кеш з відстеженням часу зміни окремих частин сторінки (якщо сторінка будується з безлічі блоків, що динамічно генеруються). При такому підході в кожній відповіді від сервера встановлені спеціальні заголовки, що позначають час зміни сторінки, які потім надсилаються браузером користувача при повторному зверненні до сторінки сайту. Сервер при отриманні таких заголовків можемо проаналізувати поточний стан сторінки (можливо, навіть відмалювати її), але замість вмісту сторінки віддати заголовок «304 Not Modified», що для браузера користувача означатиме, що можна показати сторінку зі свого (браузера користувача) кешу.
Звичайно, можна надсилати відповідні заголовки без використання серверного відстеження кешу, але в такому випадку більшість користувачів отримають оновлення контенту сторінки досить пізно. При такому підході браузер іноді опитує сервер для отримання оновлень, але періодичність та правила для кожного браузера налаштовуються його розробником, тому сподіватися, що ваші користувачі отримають оновлення вчасно, не доводиться.
Як правило, кеш підрозділяється за типом користувачів:
для авторизованих;
для неавторизованих.
Цей поділ зумовлений унікальністю контенту, для кожного авторизованого користувача та спільністю контенту для гостьових користувачів. У більшості сайтів неавторизований користувач не може змінювати вміст сайту, а отже, і впливати на його вміст.
Браузерний кеш дозволяє заощаджувати трафік та час, що витрачається на завантаження сторінок. Але для досягнення ефекту економії користувач повинен хоча б один раз відвідати нашу сторінку, а це означає, що навантаження на серверні ресурси зменшиться, але не значно.
2. Серверне кешування
Під серверним кешуванням розуміються всі види кешування, коли дані зберігаються на серверній стороні. Ці дані не доступні клієнтським браузерам. Кеш створюється і зберігається за принципом "один до багатьох" (багато, у даному випадку, - це клієнтські пристрої).
2.1 Кешування сторінки повністю
Найефективніший кеш. Чим він цікавий? Найбільша його перевага в тому, що віддача сторінки відбувається практично в момент звернення, як наслідок - це можливість обробки мільйонів запитів навіть на найслабшому сервері зі швидкістю роботи пам'яті та з незначним задіянням процесора.
Мабуть, будь-хто колись мріяв про сайт, що працює зі швидкістю «ping» або швидше.
Але й цей тип кешу має свої мінуси: наприклад, неможливість кешувати сторінки для авторизованого користувача, або користувача, вміст сторінки якого залежить від поточних змінних користувача.
Використовуйте цей кеш, якщо серверу відомі всі статичні стани зовнішніх даних, такі як: uri, get (без додаткових параметрів), користувач не авторизований, тобто, фактично, це ідеальний стан сторінки для відвідувачів. Враховуйте той факт, що при такому кешуванні архітектура сайту або програми завжди повинна однотипно обробляти запити, що входять, і віддавати однотипні відповіді. Такий стан є в будь-якому додатку чи сайті, його потрібно лише відстежити та застосувати до нього кеш.
Кешування сторінок цілком, найчастіше, застосовують у якихось екстрених випадках, при цьому кеш сторінок зберігається на заздалегідь вказаний час (від 2 хвилин), протягом якого відповіді від сервера однотипні (не дозволяйте браузеру це кешувати).
2.2 Кешування результатів компіляції php-файлів
Розрізняють як чисту компіляцію коду, і його оптимізацію під час компілювання (підміна скриптів).
2.3 Кешування окремих блоків сторінки
Це, мабуть, найцікавіший, але й найскладніший вид кешування. Тим не менш, він також може бути ефективним, і на його прикладі найлегше пояснити принципи кешування в цілому.
Необхідно відстежувати стан таблиць, стан сесії користувача, чи вимикати кешування при POST або GET запитах (http query), залежність від поточної адреси, сталість кешування (при зміні попередніх умов) або його динамічне підстроювання.
Кешування окремих блоків сторінок краще за інші типи кешування підійде, якщо вам потрібно, наприклад, зменшити кількість запитів до бази даних від реальних (авторизованих) користувачів. До речі, при правильно заданих залежностях він працюватиме навіть ефективніше, ніж усі наступні види кешування.
Чому цей вид кешування настільки важливий? Справа в тому, що розширення пулу серверів баз даних набагато складніше завдання, ніж розширення пулу серверів php-частини сайту. Понад те, php конфлікти стану кешування вирішуються набагато легше, ніж конфлікти під час роботи з безліччю баз даних.
2.4 Кешування php на основі ресурсів, що не поділяються.
Найкраще підходить при стандартизації запитів, отриманні даних із загальних ресурсів, наявності внутрішніх змінних, яких php-ресурси звертаються кілька разів при генерації сторінки.
2.5 Кешування php на основі загальних ресурсів
Таке кешування застосовуйте для зберігання серіалізованих даних. Наприклад: конфігураційний файл, стан таблиць, списки файлової системи.
2.6 Кешування mysql на основі query cache
Це досить відома та найбільш освітлена тема. Тим не менш, хотілося б розглянути специфіку роботи з timestamp і як можна уникнути постійного скидання query cache.
Напевно, ви регулярно стикалися з ситуацією, коли необхідно віддати нові матеріали, дата публікації яких вже дозволена поточним часом? Простіше кажучи, WHERE show_ts<=UNIX_TIMESTAMP()
Якщо використовувати timestamp, що постійно змінюється, в таких запитах, то sql кеш буде не тільки марний, але навіть шкідливий, тому що буде накопичуватися кількість кешованих запитів, дані яких застаріли в момент створення кешу. Ми пропонуємо наступний вихід із ситуації:
Як правило, будь-який матеріал публікується у певні моменти часу. Наприклад, 00:00. Все що потрібно зробити - створити запит, який оцінюватиме таблицю за максимальною датою, при цьому меншою за поточну.
Щось на зразок: SELECT SQL_NO_CACHE MAX(show_ts) … WHERE show_ts<=UNIX_TIMESTAMP();
Так, цей запит кешуватися не буде, але кешуватимуться всі запити до цієї таблиці, якщо їх кількість більше одного. Ця проста операція суттєво покращить життя sql-кешування.
Кешувати ці запити має сенс, якщо читання з таблиці трохи більше ніж записи.
2.7 Кешування mysql результатів роботи, що агрегують таблиці
Існує правило: оновлень даних має бути значно менше, ніж читання для їхньої віддачі. Тобто не має сенсу агрегувати те, що зміниться в той же момент, при цьому важлива актуальність агрегованих даних. Що вибирати для агрегування? Зазвичай це якась статистична інформація про кількість записів, дату останнього оновлення, автора останнього оновлення тощо.
Існують також кеші шлюзів, CDN , реверсні проксі кеші та балансувальники навантаження, що розгортаються на серверах для підвищення надійності, продуктивності та масштабованості веб-сайтів та веб-додатків.
3. Кешування та проксі-сервери
У комп'ютерних мережах проксі-сервери можуть бути представлені спеціальним апаратним забезпеченням або відповідними програмами. Вони відіграють роль посередників між клієнтами та серверами, які зберігають дані, які цим клієнтам потрібні. Кешування - це одне із завдань, яке вони вирішують. Розглянемо різноманітні види проксі-серверів.
3.1 Шлюзи
Шлюз (gateway) - це проксі-сервер, який перенаправляє запити або вихідні відповіді, не модифікуючи їх. Такі проксі-сервери ще називають тунелюючими проксі (tunneling proxy), веб-проксі (web proxy), проксі (proxy), або проксі рівня програми (application level proxy). Ці проксі-сервери зазвичай спільно використовуються, наприклад, усіма клієнтами, що знаходяться за тим самим файрволом, що робить їх добре підходящими для кешування запитів.
3.2 Прямі проксі-сервери
Прямий проксі-сервер (forward proxy, часто такі сервери називають просто proxy server) зазвичай встановлюється за клієнта. Веб-браузер, який налаштований на використання прямого проксі-сервера, надсилатиме вихідні запити цьому серверу. Потім ці запити буде перенаправлено на цільовий сервер, розташований в інтернеті. Одна з переваг прямих проксі полягає в тому, що вони захищають дані клієнта (проте якщо говорити про забезпечення анонімності в інтернеті, безпечніше буде користуватися VPN).
3.3 Веб-прискорювачі
Веб-прискорювач (web accelerator) – це проксі-сервер, який зменшує час доступу до сайту. Він робить це, наперед запитуючи у сервера документи, які, найімовірніше, знадобляться клієнтам у найближчому майбутньому. Подібні сервери, крім того, можуть стискати документи, прискорювати виконання операцій шифрування, зменшувати якість та розмір зображень тощо.
3.4 Зворотні проксі-сервери
Зворотний проксі-сервер (reverse proxy) - це зазвичай сервер, розташований там, де і веб-сервер, з яким він взаємодіє. Зворотні проксі-сервери призначені для запобігання прямому доступу до серверів у приватних мережах. Зворотні проксі використовуються для балансування навантаження між кількома внутрішніми серверами, надають можливості автентифікації SSL або кешування запитів. Такі проксі виконують кешування за сервера, вони допомагають основним серверам у обробці великої кількості запитів.
3.5 Прикордонне кешування
Зворотні проксі-сервери розташовані близько до серверів. Існує і технологія, при використанні якої сервери, що кеширують, розташовуються якомога ближче до споживачів даних. Це так зване прикордонне кешування (edge caching), представлене мережами доставки контенту (CDN, Content Delivery Network). Наприклад, якщо ви відвідуєте популярний веб-сайт і завантажуєте якісь статичні дані, вони потрапляють у кеш. Кожен наступний користувач, який запросив ті ж дані, отримає їх, до закінчення терміну їх кешування, з сервера, що кешує. Ці сервери, визначаючи актуальність інформації, орієнтуються на сервери, які зберігають вихідні дані.
Примітка. У тестуванні практично у всіх випадках правило - очищати кеш після кожного проходу тесту (якщо тільки це не цілеспрямоване тестування самого кешу або потрібна наявність кешу з будь-яких причин). Справа в тому, що кеш очевидно спотворює показники performance testing, а також може бути причиною помилкового дефект-репорту через старіння та/або неузгодженість актуальних та збережених даних. У деяких ситуаціях без очищення кешу не обійтися навіть просто через величезну кількість даних, що кешуються.
Джерела:
Дод. матеріал:
Last updated