Я намагаюся знайти хороші робочі приклади того, які зміни потрібні, щоб дозволити Varnish кешувати сайт Magento.

В ідеалі мені хотілося б переліку завдань, таких як відключити / включити речі та де їх шукати. Також було б добре мати конфігурацію Varnish, з якою ці зміни створені для роботи.

Посібник з продуктивності Magento багато говорить про Varnish, тому я знаю, що це робилося раніше, проте насправді він не пояснює, як його працювати.

Вони мають офіційний модуль прямо тут . Він включає все необхідне (конфігурація лаку, модуль, ...)

Чи підходить вам лак?

Лак - це не все-і все кінцеве виконання Magento. Це чудово, щоб компенсувати навантаження від ботів і покупців вікон - але це не повинен бути вашим першим портом дзвінка, щоб фактично зробити ваш магазин швидшим.

Фактично, впровадження Varnish має бути останньою модифікацією продуктивності вашого магазину. Залиште його лише після того, як ви побачите час завантаження сторінки, яке Magento здатний доставити без нього (напр., <600 мс завантаження сторінки).

Ваш магазин все ще повинен бути швидким

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

a) Ваші TTL-адреси настільки високі, що пошуковий запит від 4-х днів тому діє і сьогодні.
b) кількість відвідувачів сайту настільки велика, що URL-адреси заповнюються за дуже короткий час

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

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

Свіжий вміст або вищий показник звернення

^{Зображення надано magestack.com}

Ефективне використання лаку - це досягнення балансу між усталеним вмістом та кількістю відвідувачів на вашому сайті.

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

Якщо у вас сайт з низьким рівнем руху, то вам доведеться піти на компроміс. Або збільште свої TTL, щоб забезпечити більш високий показник звернень - або мати сучасний вміст. Ви не можете мати обох. Так, ви можете безперервно запускати інструмент для сканування / павука - але ресурси, які це би витрачали, а чистий обсяг або URL-адреси, які можна сканувати (як правило, в десятках тисяч для невеликих магазинів), означає, що його просто не ефективно. Тому зазвичай менші магазини отримують більше користі від хорошого розширення FPC та мають високо оптимізовану конфігурацію сервера.

Але, звичайно, я можу використовувати Varnish навіть тоді, коли користувачі ввійшли в систему, що робити з кешем на користувача або ESI?

ESI

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

Кожен раз, коли завантажується завантажувальний механізм Magento, він отримує штрафний показник близько 200 мс - до того, як він навіть завантажить колекцію / зробить блок тощо. Отже, якщо у вас більше 3-х ESI, шанси на те, що ви закінчили повільніші завантаження сторінки, використовуючи Varnish + ESI для динамічного контенту, ніж просто обхід Varnish і передача запиту безпосередньо самому Magento.

Щоб дійсно ефективно використовувати ESI, ви повинні мати можливість поєднувати кілька запитів в одному запиті.

Наприклад, сторінка перегляду категорій із 20 продуктами повинна відображати точні запаси. Таким чином, ви використовуєте ESI для кожного блоку на сторінці. Це було б 20-разові запити на акції ESI. Хоча запити на акції дуже легкі, запуск 20x їх одночасно знизить продуктивність. Тож замість цього ви можете обслуговувати весь блок / колекцію з 20 продуктів і просто отримати такий 1x запит. Але завантаження та надання колекції - це, мабуть, найповільніший елемент на сторінці в будь-якому випадку - тому ви не дуже заробили.

Використання ESI ефективно потребує належного планування та виконання, або у вас буде більш повільний сайт, ніж взагалі не використовувати Varnish.

Кеш на користувача

Тоді є альтернатива використання певного користувача кешу. Це погана ідея, якщо ви не маєте дуже низький веб-сайт. Ваш показник відвідувань буде жахливо низьким - оскільки шанси на відвідувача, що потрапляє на ту саму сторінку, на якій вони вже були, дуже низькі. І для кожного клієнта ця сторінка 6 Кбіт буде займати більше місця у вашій скриньці для зберігання лаку.

Наприклад, якщо ви виділили 1 Гб для лаку. З типовим сайтом, де користувачі переглядають 8 сторінок за відвідування, в середньому 6 із цих сторінок будуть унікальними. Отже, це 28 відвідувачів на 1 МБ пам’яті. Тоді враховуйте ваші зображення, CSS та JS - вони (на щастя) будуть загальними, але все одно, ймовірно, займуть хороших 7-800 МБ наявного вашої пам’яті. Це залишає вам 200 МБ пам’яті, достатньо кешу для 5600 унікальних відвідувачів.

Ну, мені байдуже, я просто хочу лаку

Гаразд, тоді вам потрібно буде зробити наступне:

1. Встановіть SSL-термінатор, щоб сісти перед лаком (наприклад, stud / pound / nginx)
2. Встановити Varnish на сервер
3. Переконайтесь, що ви налаштували X-Forwarded-Forправильно
4. Встановіть модуль лаку у свій магазин
5. Налаштуйте свої лаки VCL, щоб виключити сторонні розширення

Оскільки перші 3 пункти виходять за рамки цієї відповіді, я залишаю це для себе. Точка 4 - гра дитини, а з пунктом 5 - продовження читання.

Найважливіше у впровадженні лаку - це те, щоб ви ніколи не кешували вміст, який ніколи не повинен кешуватися.

Напр.

• Відкликання платежів на шлюзі
• Огляд кошика
• Огляд мій рахунок клієнта
• Оформити замовлення (та відповідні дзвінки Ajax)

тощо.

Для основних URL-адрес Magento існує досить стандартний перелік URI-адрес, до яких можна вийти з лаку:

admin|checkout|customer|catalog/product_compare|wishlist|paypal

Але вам також потрібно врахувати будь-які спеціальні розширення / сторонні розширення, які ви також працюєте, які мають власні маршрути, маршрутизатори та простори імен. На жаль, не існує простого способу дізнатися, які URL-адреси з цих розширень можуть бути, а не можна кешовані. Тому потрібно оцінювати кожного окремо.

Як правило, кожного разу, коли ми налаштовуємо Varnish, ми почнемо з визначення відповідних маршрутів, маршрутизаторів та просторів імен, які вони можуть займати, і підемо звідти. Ми робимо це через SSH:

grep -Eiroh "<frontName>.*</frontName>" community | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" community | grep "<from>"
grep -A5 -ir "<routers>" community 
grep -Eiroh "<frontName>.*</frontName>" local | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" local | grep "<from>"
grep -A5 -ir "<routers>" local 

Це не дасть вам остаточного списку URL-адрес - але майже напевно дасть вам початковий текст.

Ми не можемо підкреслити, як важливо ніколи не кешувати вміст, який не повинен кешуватися. Результати можуть бути катастрофічними.

Підводячи підсумок

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