Чорна п’ятниця - ТЕХНІЧНИЙ посібник з виживання - частина 1 - Лак

Ця стаття є частиною серії із 3 статей, розроблених для того, щоб допомогти інтернет-магазинам подолати Чорну п’ятницю.

це перша частина
У другій частині ми говорили про CDN
У наступній статті ми поговоримо про "паралелізацію" - тобто використання декількох серверів одночасно.

Чорна п’ятниця - це вже велика подія в Румунії. Це говоримо не лише ми в галузі, це бачимо у всій пресі. Якщо у тих, хто займається маркетингом та продажами, є привід радіти, люди в технічних відділах це точно stresaІ> i події. Ми були.

Цього року сервери Avanticart працювали майже ідеально 1, без простою та дуже хорошим часом відгуку (зазвичай менше 500 мілісекунд). НЕ Я не вигадав нічого нового. Я просто багато читав, експериментував та поєднував різні технології.

Подібно до того, як те, що написали інші, допомогло нам, ми хочемо щось повернути. Ми віримо, що лише поділившись вивченим, ми всі можемо рухатися вперед. Завдяки цій статті ми хочемо допомогти розробникам та спільноті електронної комерції в Румунії подолати майбутні Чорні п’ятниці.

Гаразд, залиш історію і розкажи мені, що ти зробив

Коротше кажучи, було три речі, які призвели до безперебійної роботи:

Лак - потужний кеш
CDN для зображень та css/javascript
Спільний доступ до запитів на декількох серверах

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

Гаразд, візьмемо кожного окремо. Почнемо з Varnish, бо, мабуть, саме він "врятував" ситуацію в Avanticart. Щодо CDN та використання більшої кількості серверів ми незабаром повернемося зі статтями.

Лак

На відміну від "звичайного" блогу чи сайту, набагато складніше кешувати інтернет-магазин. Чому? Дві основні причини:

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

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

Чому Лак такий гучний?

Лак функціонує як веб-сервер, будучи першою точкою взаємодії з відвідувачем. В основному лакуйте «першим» перед Apache/Nginx або будь-яким веб-сервером, який ви використовуєте, і кешує все, що зловить. Таким чином, дуже мало додатків в кінцевому підсумку споживають ресурси (підключення до бази даних тощо).

Після встановлення Varnish він працює на порту 6081. За замовчуванням вам потрібно змінити його на порт 80, інакше ви втратите все задоволення. Для цього потрібно змінити файл/etc/default/varnish. Ми використовуємо Debian для CentOS або інших дистрибутивів, конфігурація може відрізнятися.

У файлі вище ви знайдете такий рядок:

Тут вам потрібно змінити значення з -a: 6081 на -a: 80. Також було б корисно встановити TTL за допомогою параметра -t. Тому цей рядок стає приблизно таким:

Гаразд, тепер, коли ми змінили порт у Varnish, нам доведеться змінити порт і на веб-сервері. Ми використовуємо Apache, тому ми модифікуємо файл /etc/apache2/ports.conf. Ми міняємо лінію Listen 80 на Listen 8080. Теоретично цього достатньо, але це залежить від того, як ви налаштували віртуальні хости. Давайте перезапустимо Apache, а потім Vanish.

Поки це було просто, але ще не готово. Лак працює, але, швидше за все, нічого не кешує. Як ви знаєте, кешувати чи ні? Оновіть сторінку 2-3 рази. Потім перегляньте інструменти Firebug/Developer.

Швидше за все, в заголовку Вік показано нуль. Ознака того, що немає кешу.

Проблеми з дієтою?

Щось важливе знати: у лаку проблема з тортами. Він не буде кешувати сторінку, якщо вона надсилає файли cookie. Крім того, він не буде кешувати, якщо сервер надсилає заголовок Cache-Control із значенням no-cache. Давайте подивимося, як ми вирішуємо ці проблеми.

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

За замовчуванням PHP надсилає заголовок Cache-Control під час запуску сеансу. У інструментах Firebug/Developer ви можете побачити щось на зразок:

Щоб позбутися, просто зателефонуйте session_cache_limiter (''); Перед session_start (); . Будьте обережні, як ви додаєте цей код. Якщо ви використовуєте платформу з відкритим кодом, у вас виникнуть проблеми з майбутнім оновленням, якщо ви безпосередньо зміните вихідний код. Ви можете написати плагін або знайти налаштування.

Тепер, коли ця проблема вирішена, давайте подивимося, як ми її вирішуємо за допомогою файлів cookie. Цікаві подробиці я знайшов на сторінці Швидко. В основному робиться серія хитрощів, щоб видалити файли cookie та повернути їх назад у вигляді заголовка. Файл /etc/varnish/default.vcl потрібно змінити, щоб показати щось на зразок:

Ми вважаємо, що коментарів у коді достатньо, але зазначимо, що ми шукаємо сеансовий файл cookie з іменем APP_SESSID_ (щось). Тут вам доведеться змінити назву файлу cookie на вашій платформі.

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

Порівняно з версією, запропонованою Fastly, ми додали цю частину додатково:

Тобто, ми не хочемо кешуватися, якщо відвідувач знаходиться на сторінці оформлення замовлення, на сторінці облікового запису або якщо запит стосується файлів .php (зазвичай це запити Ajax, оскільки більшість URL-адрес є SEO-зручний, тому це не закінчується .php). Напевно, у вас є сторінки, які не слід кешувати. Вам потрібно їх ідентифікувати та відповідно змінити файл.

Після перезапуску Varnish та внесення 2-3 запитів ви повинні побачити ненульовий заголовок Age в Firebug/Developer tools.

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

Хто їв тістечка?

Гаразд, зараз створюється кеш, але файли cookie все одно не потрапляють назад у додаток магазину. Для цього нам потрібно згенерувати змінну $ _COOKIE із заголовка, встановленого Varnish.

І я створив цю функцію:

Знову ж, будьте обережні, де ви пишете/дзвоните цій функції, щоб уникнути проблем із вашим майбутнім оновленням.

Кошик, як з кошиком?

Супер У нас є кеш, у нас є файли cookie. Залишилася лише одна проблема: вся сторінка кешована, включаючи частину коду, яка показує, скільки товарів у вас у кошику для покупок.

Для тестування ви можете відкрити нове вікно браузера приватно/анонімно. Під час другого оновлення (перше ніколи не кешується, пам’ятаєте?) Ви побачите кошик у першому браузері.

Лак дає нам спеціальний тег, який ми можемо вставити на сторінку. Отже, де ми маємо кошик для покупок, ми можемо ввести такий код:

Коли Varnish побачить цей код на сторінці, він зробить фоновий запит до файлу /esi_shopping_cart.php, візьме результат і перекомпонує сторінку, все без того, щоб відвідувач знав.

Ми не розміщуємо тут код з /esi_shopping_cart.php, оскільки реалізація відрізняється від платформи до платформи, але це може бути простим відлунням для деяких змінних сеансу.

Щоб ESI працював, потрібно зауважити, що нижче vcl_fetch я ставлю рядок beresp.do_esi = true; .

Гаразд, все іде ідеально, тож пора витягнути пиво з холоду, так? Не поспішайте, це наразі було легкою частиною.

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

Щоб очистити кеш, потрібно зробити деякі спеціальні запити (PURGE/BAN замість GET/POST) до Varnish. Ці запити можна подати кількома способами, а додаткову інформацію можна знайти в документації. Ми вважаємо за краще використовувати BAN.

Оскільки в Avanticart у нас кілька магазинів на одному сервері, нам потрібно знати, з якого магазину ми хочемо очистити кеш. Тому ми використовуємо деякі додаткові заголовки (X-Ban-Host та X-Ban-Url). Нам потрібно змінити /etc/varnish/default.vcl, щоб додати підтримку видалення + налаштування заголовка.

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

Потім ми модифікуємо функцію vcl_recv наступним чином:

Ми модифікуємо функцію vcl_fetch, щоб додати спеціальні заголовки:

І зараз ми перезапускаємо Vanish, щоб скористатися перевагами.

Ось у вас є функція PHP, яка обробляє видалення:

Звичайно, коли і де ви використовуєте цю функцію, це дуже важливо і може вплинути на продуктивність. Регулярні вирази можна вказати для $ url. Таким чином, щоб очистити весь кеш, ми можемо викликати clearVarnishCache ($ host, '. *');

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

на одного клієнта вплинуло неправильне налаштування, що призвело до дивної поведінки кошика для покупок (Еміліан, ми ще раз просимо вибачення).