TL; DR - У MageStack ми використовуємо Varnish, Redis (кеш), Redis (сеанси) та Eaccelerator / Zend OPCache (залежно від версії PHP)
Ви вже зрозуміли більшість із цього.
Бекенд кешу, сховище сесій, кеш-код коду, кешування повної сторінки та кеш-зворотний проксі - абсолютно різні.
Ви можете використовувати різні технології для всіх, і ви можете використовувати ВСІ одночасно (включаючи лак та FPC)
Кеш-бекенди
- Файли (основні) за замовчуванням
- Memcache (Core)
- APC (Core)
- Редіс (<1.9 модуль люб’язно Колін Молленхур)
- MongoDB (модуль люб’язно наданий Коліну Молленхуру)
- Rubic (модуль люб’язно Даніель Слооф)
Ви можете використовувати лише один бекенд кешу.
Всупереч поширеній думці, використання кешу на основі пам'яті не покращить продуктивність. Але це дозволить подолати деякі фатальні недоліки кешування на основі файлів за замовчуванням Magento.
Щодо написання цього повідомлення, Редіс - моя рекомендація.
Сеансові магазини
- Файли (основні) за замовчуванням
- Memcache (Core)
- Редіс (<1.9 модуль люб’язно Колін Молленхур)
- MongoDB (модуль люб’язно наданий Коліну Молленхуру)
Ви можете використовувати лише один магазин сесій.
Всупереч поширеній думці, використання сеансу зберігання на базі пам'яті не покращить продуктивність.
Щодо написання цього повідомлення, Редіс - моя рекомендація.
Кеш OpCode
- APC
- XCache
- Еакселератор (PHP <5.4)
- Zend OPCache (PHP> 5.4)
Насправді ви можете встановити декілька кеш-кодів коду, але це не рекомендується, і я не очікував би побачити якісь вигоди.
Мої рекомендації наведені в дужках вище.
Для використання цього модуля не потрібно встановлювати модуль.
Зворотний кеш-проксі
- Лак
- Nginx
- Апач
- … і багато іншого
Ви можете використовувати декілька зворотних проксі-серверів, і хоча це є складним і схильним до подовження кешу, воно може мати достоїнства (тобто, щоб запобігти штампуванню під час промивання кешу).
Використовуйте його, коли це необхідно (тобто не для прискорення повільного сайту, а для зменшення використання ресурсів на швидкому сайті).
Щоб використовувати зворотний проксі-сервер, йому потрібно як увімкнути сторону сервера, так і потрібен модуль для Magento.
Причина модуля полягає в тому, щоб допомогти керувати логікою кешування (тобто сказати кешу, що він повинен, а що не повинен кешувати), а також керувати вмістом кешу (тобто, щоб запустити очищення кеша).
Я не рекомендую жодного, якщо ви повністю розумієте, що ви робите. Неправильно налаштовані зворотні проксі-сервери можуть зламати інформацію заголовка, можуть спричинити втрату сеансу, спільний доступ до сеансу, несвіжий вміст, застосувати додаткові обмеження для завантаження часу / буферів, споживання додаткових ресурсів тощо
Повний кеш сторінки
- EE FPC
- … Багато інших (через модулі)
Використовуйте його, коли це необхідно (тобто не для прискорення повільного сайту, а для зменшення використання ресурсів на швидкому сайті).
Всупереч поширеній думці, ви можете (і повинні) використовувати FPC у поєднанні з зворотним кешем проксі. Вони вирішують різні проблеми та мають різні можливості.
FPC можуть використовувати більше інтелекту, оскільки вони мають прямий доступ до сеансу користувачів та ядра Magento, тоді як зворотний проксі не відомий додатку (він досить тупий у тому, як це працює) - тому двоє доповнюють один одного, не конкуруючи один з одним .
Тобто Не думайте, що лак чи FPC, подумайте про Varnish та FPC.