Кешування в PHP: APCu, File Cache чи Redis? Повний гід для високонавантажених веб-додатків

Коли ми говоримо про продуктивність PHP веб-додатків, кешування - це не просто оптимізація. Це фундаментальна частина архітектури.

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

Кеш впливає на:

• швидкість відповіді сервера (TTFB)
• навантаження на базу даних
• масштабованість
• стабільність під піковим навантаженням
• вартість інфраструктури

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

У цій статті ми розглянемо:

• що таке кешування на рівні веб-додатку
• як воно впливає на перформанс
• APCu, File Cache та Redis - архітектурно
• проблеми multi-instance середовища
• коли кешування взагалі шкодить
• мій реальний досвід з Yii2 + Azure + 2 інстанси

Що таке кешування в контексті PHP веб-додатків

Кешування - це збереження результатів дорогих операцій, щоб не виконувати їх повторно.

Дорогими можуть бути:

• складні SQL-запити
• агрегації
• обчислення
• API-запити
• побудова великих HTML-фрагментів

Кожен запит до серверу проходить шлях:

1. Веб-сервер
2. PHP
3. Ініціалізація фреймворку
4. Запити до БД
5. Обробка бізнес-логіки
6. Генерація HTML

Якщо частину цього шляху можна “пропустити” - сторінка стає значно швидшою.

Як кеш впливає на швидкість завантаження сторінки

З погляду браузера важливий показник TTFB (Time To First Byte).
Якщо сервер генерує сторінку 800 мс - користувач відчує затримку.

Якщо сторінка віддається з кешу за 40–60 мс - UX кардинально змінюється.

Кеш дозволяє:

• зменшити latency
• стабілізувати response time
• уникнути “піків” навантаження

Особливо це помітно при:

• синхронізації з API
• масових оновленнях даних
• high-traffic сторінках (списки, каталоги)

APCu – кеш у пам’яті одного інстанса

APCu працює в межах конкретного PHP-процесу або сервера.

Він надзвичайно швидкий, тому що доступ до пам’яті завжди швидший за диск або мережу.

Але в multi-instance середовищі виникає ключова проблема:
APCu не синхронізується між серверами.

Якщо у вас:

• 2 інстанси в Azure
• Load Balancer
• запити розподіляються випадково

то кожен інстанс матиме власний кеш.

Це призводить до:

• розбіжностей даних
• неконсистентного стану
• складної інвалідації

File Cache – компромісне, але ефективне рішення

Файловий кеш повільніший за APCu, але має одну критичну перевагу:
його можна винести в спільний storage.

У хмарі це може бути:

• shared disk
• mounted storage
• NFS
• Azure shared filesystem

У такому випадку всі інстанси читають один і той самий кеш.

Це дає:

• консистентність
• просту інвалідацію через TagDependency
• мінімальні витрати

Redis – професійний стандарт

Redis - це окремий сервер кешу в пам’яті.

Він вирішує всі проблеми multi-instance:

• спільне сховище
• висока швидкість
• TTL
• pub/sub
• атомарні операції

Але в хмарі Redis - це:

• додатковий сервіс
• додаткові витрати
• складніша архітектура

Порівняльна таблиця

Коли кешування НЕ доречне

Кеш не завжди правильне рішення.

1. Персоналізований контент

Якщо:

• кожен користувач бачить унікальні дані
• персональні пропозиції
• власні транзакції
• dashboard з персональними метриками

то кеш може:

• сильно розростись
• зайняти багато пам’яті
• створити складну логіку інвалідації

Іноді простіше зробити добре оптимізований SQL, ніж кешувати мільйон варіацій.

2. Дані, що часто змінюються

Якщо дані змінюються щосекунди - кеш дасть мало користі.

3. Безпека

Кеш може містити:

• персональні дані
• токени
• конфіденційну інформацію

У такому випадку важливо:

• не кешувати PII
• не зберігати сесії в APCu на multi-instance
• контролювати TTL

Мій досвід: Yii2 + Azure + 2 інстанси

Спочатку я використав APCu.

Локально все працювало ідеально.

Після переходу на Azure з двома інстансами почались проблеми:

• стан синхронізації “стрибає”
• кеш не інвалідується на іншому інстансі
• користувач бачить різні дані

Redis був логічним рішенням.

Але:

• бюджет обмежений
• Redis підвищував вартість інфраструктури
• потрібен був простіший варіант

Я перейшов на FileCache зі спільним storage:

/home/runtime/frontend/cache
/home/runtime/backend/cache

Інстанси читали один і той самий кеш.

Результат:

• консистентність
• стабільна інвалідація
• мінімальні витрати
• прогнозований перформанс

Висновок

Кешування - це архітектурне рішення, а не просто “прискорення”.

APCu підходить для одного сервера.
FileCache - чудове бюджетне рішення для multi-instance.
Redis - правильний вибір для масштабованих систем.

Головне - розуміти інфраструктуру, а не просто обирати найшвидший інструмент.