Повний кеш сторінки на CE 1.8 - модуль FPC Magento? Лак? Обидва?

Тож я трохи розгублений, коли берусь за дослідження повної керування сторінками для Community Edition 1.8. Я вже реалізував дворівневий кеш Redis, CDN, налаштував MySQL на my.cnf для максимальної продуктивності (якщо звичайно, що БД знаходиться на окремому сервері), і у мене є два сервери, що розміщують наш магазин за балансиром навантаження. Я це кажу, щоб зазначити, що я не одразу стрибаю за FPC перед тим, як робити початкові налаштування продуктивності.

Я ніколи раніше не використовував Varnish на будь-якому сайті, не кажучи вже про Magento, і я ніколи не встановлював FPC в Magento. Я розумію, що Varnish є проксі-сервером, який діє як перехрес між CDN і кешем сторінки самостійно, надсилаючи дані в браузер, перш ніж запит навіть потрапить на веб-сервер. Наскільки я розумію, модуль FPC створює локальний кеш, який веб-сервер вимиває. Я знаю, що для обох налаштувань вам потрібно зробити «Пробивання дірок», щоб дістати динамічний контент до браузера (хоча методи відрізняються, між використанням модуля або використанням Varnish). Будь ласка, виправте мене, якщо я щось тут не розумію.

До цього часу я вважав, що вони є двома окремими об'єктами, які ви могли б реалізувати, щоб допомогти на вашому веб-сайті, але зараз я читав, що я читаю, мабуть, навпаки. Мій початковий план полягав у тому, щоб придбати модуль " Warp Advanced Full Cache " для Magento (раніше я вважаю, що "Tiny Brick Lightspeed FPC"), як здається, є найпопулярнішим, якщо торкатися доцільної сторони (але, чесно кажучи) , 350 доларів для нашої компанії не дуже, особливо для того, що вона може зробити). Я та 2 мої колеги-розробники планували навчитися правильно її та повною мірою реалізовувати в рамках нашої власної власної, домашньої теми, щоб максимізувати те, що ми можемо отримати з неї. Після того, як це було зроблено, я в якийсь момент по дорозі зрозумів, що буду також шукати втілення Варнінгу, але, як я вже говорив раніше, я зрозумів, що вони є окремими.

Однак тепер я починаю зустрічати такі розширення, як цей PageCache Powered від лаку, який є безкоштовним, або цей кеш Vortex, керований кешем лаку, який становить майже 800 доларів США, - це модулі Magento Full Page Cache, які працюють безпосередньо з Varnish.

Моє запитання до вас, обмін стеками, як я повинен бачити FPC і Varnish? Як окремі утворення? Якщо так, то вони взаємовиключні? Це дві сторони однієї і тієї ж монети, яку я повинен реалізовувати разом? Або вони схожі, але не є винятковими та не включають один одного?

Чи можу я використовувати Varp Advanced FPC, про який я згадував вище, для лаку? Чи варто використовувати його з лаком? Або було б краще використовувати інший FPC, якщо я планую використовувати лак? А ще далі, чи є FPC настільки гарний, що мені не потрібен лак? Або навпаки, я повинен просто використовувати Varnish і викопати ідею FPC?

Вибачте за стіну тексту, але я переглянув багато статей, блогів та дописів на форумі, і не зміг зрозуміти остаточну відповідь на ці питання. Я щиро вдячний за вашу допомогу та внесок у цю справу =)

Ну і нарешті, швидке запитання про Varnish та веб-сервери. В даний час я використовую звичайну настройку стека LAMP Apache, але вже деякий час я бачу, як люди захоплюються використанням Nginx з Magento. Я сам зробив кілька тестів, тести на стрес і навантаження, і, здається, це може спрацювати трохи краще в правильних умовах. Як такий, я розглядав можливість переключення в якийсь момент найближчим часом. Чи все-таки це вплине на моє бажання і рішення використовувати FPC та / або лак?

Дякую!!!

РЕДАКТ: О! І ще одне швидке запитання - Оскільки у мене два сервери, що розміщують мій сайт, за балансиром навантаження (що також є настройкою, яку можна збільшити по горизонталі в разі виникнення необхідності), я повністю використовую Redis і Memcached, розміщені на окремому сервері від Веб та БД для моїх сеансів і кожного рівня кеша Magento (ну, Зенда) дворівневого кеша. Я припускаю, що FPC зберігатиме свої дані в одній із цих систем? Чи потрібно мені мати певне розширення, щоб зберігати його там чи вони все роблять? І хоча я припускаю, що це ні, чи не вплине це на лак в будь-якому випадку? Знову дякую!!

У інформатиці є дві важкі речі:

1. Назви речі
2. Недійсне кешування

Пробивання отворів підпадає під категорію №2 :)

Загальні

Найкращий підхід - почати в нижній точці стеку і оптимізувати до фронту Magento.

База даних та файлова система

Завжди має бути першою сферою, на яку слід зосередити увагу. Оскільки. I / O.

MyTop - це зручний Perl-скрипт на основі Linux, який імітуватиме верхню команду Linux та надасть вам уявлення про стан ваших екземплярів MySQL.

• https://github.com/jzawodn/mytop

Htop є більш надійним зверху , The Трасування функція може допомогти визначити входи / виходи процесу, щоб знайти потенційні вузькі місця.

• https://github.com/hishamhm/htop

Іотоп - це ще один інструмент для моніторингу вводу-виводу.

• http://guichaz.free.fr/iotop/

Інші зручні скрипти для утиліти, такі як mysqltuner.pl та праймер для налаштування mysql можуть запропонувати зрозуміти ваші змінні виконання MySQL та запропонувати поради. Майте на увазі, що вони мають бути орієнтирами, оскільки найкращим підходом завжди є оцінка потреб та налаштування на основі відомих зібраних даних. Якщо сліпо це зробити, це може завдати більше шкоди часом, ніж користі. І передчасне їх використання без принаймні 24 годин змінних часу виконання mysql може запропонувати погані поради.

• http://mysqltuner.pl
• https://launchpad.net/mysql-tuning-primer

Пам’ятайте, що Percona , MariaDB та стандартний MySQL повинні працювати з усім вищезазначеним. Віддаючи перевагу Percona як вилку MySQL, оскільки Magento настільки важкий для InnoDB, а XtraDB пропонує безліч інструментів та удосконалень для двигуна db.

• http://www.percona.com/software
• https://mariadb.org/en/about/

Apache або Nginx

Я все ще використовую Apache, оскільки він добре служив багатьом іншим. Я також використовував і налаштовував Nginx. Хоча це і пропонує деякі переваги, є крива навчання. Незважаючи на те, що обидва є популярними варіантами, він пропонує деякі переваги перед Apache, але це буде менший слід пам’яті. Однак тонкий збитий Apache під управлінням PHP-FPM матиме схожий слід пам’яті.

• http://arstechnica.com/business/2011/11/a-faster-web-server-ripping-out-apache-for-nginx

Справа в точці:

Оскільки ця стаття стосувалася продуктивності, я мушу зазначити, що один із найпростіших способів допомогти апачу вийти з себе, це не використовувати файли .htaccess. Помістіть те, що ви розмістили там у своїх каталогах, встановіть для AllowOverride значення "None", і ви, нарешті, не будете просити apache пройти весь шлях документа, щоб зрозуміти, чи потрібно йому звертати увагу на .htaccess чи ні. Це основний, простий натяк на налаштування, який, здається, багатьом не вистачає.

Щоб полегшити цю перевірку:

• https://github.com/preinheimer/htaccessConverter

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

PHP

PHP-FPM та APC. Використовуйте їх, зніміть непотрібні або непотрібні модулі PHP, не потрібні Magento.

Кодова база Magento

AOE_TemplateHints чудово визначає, чи правильно кешуються ваші блоки:

• https://github.com/fbrnc/Aoe_TemplateHints
• http://www.fabrizio-branca.de/magento-advanced-template-hints-20.html

AOE_Profiler хороший для профілювання, будьте впевнені та ввімкніть його профілювання рівня БД (очевидно, в локальному / розробницькому середовищі). Це разом із згаданим раніше інструментом mytop полегшує пошук погано поводжуваного SQL.

• https://github.com/fbrnc/Aoe_Profiler

Модулі сторонніх компаній та спеціальний код

Деякі дуже хороші найкращі практики оптимізації від Magento самих є корисним читанням, і це слід пам’ятати, переглядаючи сторонні модулі перед їх використанням. (Є багато ІМО погано поводиться).

• http://info.magento.com/rs/magentocommerce/images/Conquer_the_5_Most_Common_Magento_Coding_Issues_to_Optimize_Your_Site_for_Performance.pdf

Екранна лупа від Magento ECG допоможе легко визначити недоброзичливий код на основі PDF-файлу, наданого вище. Це на основі симфоні / php-парсера, але встановлено через композитор.

• https://github.com/magento-ecg/magniffer

Лак

Оскільки прихильником того, що Varnish є автором ядра FreeBSD, він пропонує декілька божевільних часів завантаження нижче другого. Однак якщо у вас є навіть найменші відмінності у ваших шаблонах, які не виходять із коробки, ви витратите час на налаштування лаку / магенто, щоб вибити необхідний вміст. Більшість, що я бачив, просто AJAX'фіксують потрібні предмети, не збережені з лаку.

Існує ряд модулів Magento, які сприяють пробиванню та кешування отворів:

• AOE_Static: https://github.com/AOEmedia/Aoe_Static
• Скипидар Nexcess: https://github.com/nexcess/magento-turpentine

Зрештою, це має бути в останньому кінці шляху оптимізації, і МОЖЕТЕ зажадати певних налаштувань, щоб все вийшло правильно.

Magento CE FPC

Поки що найкращий я знайшов FPC CE: Lesti :: FPC

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

• http://gordonlesti.com/lestifpc/
• https://github.com/GordonLesti/Lesti_Fpc (github у випадку мертвого майбутнього посилання)

В кінці дня використовуйте власне тестування та судження.

Деякі подальші читання:

• http://www.kingletas.com/2012/08/caching-performance-optimization.html
• https://www.sonassi.com/knowledge-base/magento-with-varnish/
• http://info.magento.com/rs/magentocommerce/images/HostandBoastBestPracticesForMagentoHosting.pdf

Трохи запізнюючись на цю тему, я знаю, але якщо ви все ще шукаєте рішення, то, можливо, ви захочете розглянути, еволюціонований кешування . Це та сама ціна, що і Warp, але це:

• Встановлюється та конфігурується дуже швидко та просто - усі штампування та конфігурація отворів проводиться в межах адміністратора
• Інтегрується безпосередньо з лаком і дозволяє очистити і зігріти кеш лаку з Magento
• Працює з frontend form_key, введений в 1,8 CE в обох лаках і власний кеш.
• Дуже активно розвивається з чуйною підтримкою. Регулярні нові версії з метою випустити виправлення помилок протягом декількох днів звітності
• Має велику документацію, яка оновлюється з кожним випуском

Налаштування за допомогою лаку прямо вперед, вам просто потрібно включити налаштування адміністратора та використовувати .vcl, знайдений тут . Ви також не обмежені лише кеш-сервером, який обслуговує Varnish, коли нормально не міститься файлів cookie - ви отримуєте дуже високий показник звернення кешу.

Ми написали FPC, сумісний з новим форматом Magento 1.8. Повний кеш сторінки сторінки Brim: http://ecommerce.brimllc.com/full-page-cache-magento.html

BOOMER має велике значення щодо того, щоб почати низько на стеці та працювати на шляху. FPC або лак повинен бути приблизно останнім, що ви робите. Ми проводимо аудит ефективності і часто знаходимо проблеми з конфігураціями MySQL та APC, які просто вимкнені. Як і розміри буфера Innodb, встановлені за замовчуванням, і база даних зросла далеко позаду.

Ми рекомендуємо не використовувати будь-якого FPC з лаком, якщо спеціально не розроблено для спільної роботи. Як правило, ми не рекомендуємо Varnish, якщо у вас є кілька приємних серверів, які були налаштовані разом з вашою кодовою базою і все ще намагаються нести трафік. Оновлення динамічного вмісту може спричинити складність за допомогою Varnish, зокрема, намагаючись обмежити ваші запити до Makendo Bakend і, у свою чергу, зменшити навантаження. Якщо у вас є одна або дві веб-голови, виграш може бути не вартим часу і ускладнень.

У більшості ситуацій хороший FPC забезпечить вам необхідну продуктивність, звичайно після налаштування вашого сервера та кодової бази. За допомогою нашого FPC ви можете отримати нижчу кількість генерувань півмісяця на кеші рівня 1 та на півмісяці у стандартному кеші. Наш кеш рівня 1 використовується для випадків, коли користувач не зареєстрований і не має нічого в кошику, оскільки він не робить пробивання отворів. Якщо будь-яке з цих умов помилкове, стандартний кеш використовується з підтримкою пробивання повного отвору.

У нашому FPC вбудований легкий пробивальний отвір і працює з коробки зі всіма стандартними блоками Magento, а також з будь-якими спеціальними блоками. Це все налаштовується через панель адміністратора.

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

Я можу говорити за всі FPC, але з нашим ви можете налаштувати через адміністратора, де його зберігати. Ви можете скористатися типом Magento кеш-пам'яті за замовчуванням або задати власні налаштування для використання файлу, бази даних, APC, Redis, Memcache та оптимізованого файлу.

Правильної відповіді немає. У магазині має бути динамічне завантаження сторінок на рівні 3-х, а в ідеалі - динамічне завантаження сторінок на 1-2 секунди, субсекунда не є необхідною і в першу чергу є маркетинговою статистикою. Apache легко вивчити і складно виконати, Nginx важко вивчити і легко виконати, багато сайтів переходять на Nginx, однак мати високоякісну архітектуру на основі Nginx, а Magento - це не просто.

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

Лак може бути FPC, CDN серед інших, однак у вашому випадку краще вважати це FPC. FPC дозволяє більшій кількості відвідувачів на сервері і забезпечує швидшу статичну доставку, яка є одним з таких інструментів, як Varnish, проте з ним виникають різні проблеми, включаючи динамічний контент, контроль запасів, ціноутворення. Відповідь зводиться до того, як структурований ваш бізнес, як завантажуються ваші дані, як часто, ваш тип хостингу та багато іншого, просто на ваш бізнес впливає надання статичного вмісту відвідувачам. Ви можете технічно пом'якшити більшу частину цього за допомогою конфігурації FPC, однак це ускладнює ділове середовище, з точки зору власника бізнесу воно може не давати збалансованої віддачі від інвестицій.

FPC є останньою частиною, якщо у вас є суб-3 або краща динамічна завантаженість, ваша архітектура може обробляти бусини в запитах відвідувачів, оскільки це впливає на ранжирування, поглинання маркетингових та святкових шипів, а бюджет має надати складність в архітектурі сервера - хостинг повинен бути 0,5 -1% доходу для малого бізнесу, більшість з яких здійснюється в основному за рахунок цього, спричиняючи багато непрямих бізнес-проблем.

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

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

1. Як і Varnish, він не використовує з'єднання з базою даних для 90% запитів. Як результат, це надзвичайно швидко
2. Він має можливість автоматичного розгортання сторінок, коли такі речі, як запас продуктів, змінюються, і це дуже добре
3. Це багатошаровий кеш, тому він також підтримує пробивання отворів під час входу користувачів (ці запити вимагають використання бази даних)

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