У цій невеликій замітці розглянемо процес підключення технології Композитного сайту в проектах на 1С-Бітрікс.
Відразу пару посилань на опис технології, про всяк випадок:
Маркетингова
Технічна
Що маємо перед початком впровадження:
- магазин на БУС 17 з низкою підвантажуваних ajax-ом областей;
- Bitrix VM 7, PHP 7;
- VPS на SSD;
- кеш зберігається в memcached;
- конфігурація оптимальна;
- монітор продуктивності радує;
- клієнт задоволений.
Здавалося б, ну що ще?
І тут лунає голос Внутрішнього Перфекціоніста: «Хочу швидше, зроби швидше, хочу, хочу, зроби».
Якийсь час можна і пожити з цим тихим вкрадливим докором. Композит - не те, що треба кидатися робити в першу чергу, тим більше, якщо проект в цілому працює без збоїв.
Але одного разу розумієш, що можна просто взяти і зробити. Інакше голос не заспокоїться. Печиво грудкою, смузі без смаку, панкейк не торт.
Давайте розглядати відразу правильний варіант - у вас є тестова копія проекту, прикрита зовні. Якщо ні - зробіть. Не можете зробити - працюйте по-живому, бог пробачить, клієнт не побачить. Жарт. Просто зробіть копію. Для початку йдемо в адмінці тестової копії у Параметрах Налаштування продукту. Композитний сайт і недрогнутою рукою рішуче і безповоротно включаємо Автокомпозит. Після чого починаємо методично і уважно тестувати всі інтерфейси сайту, моделюючи видачу під різними користувачами. Насамперед звертаємо увагу на поведінку блоків, які перерисовуються аяксом, без оновлення сторінки. З імовірністю, близькою до 100%, низка блоків працюватиме некоректно. Причина проста, вона криється в самій технології. Композитний кеш - це логічне продовження старої технології html-кешування, без «навчання» кешований контент створюється за першим хітом першого користувача і потім транслюється всім іншим користувачам. Тому цілком можлива, наприклад, ситуація, при якій всім користувачам буде показуватися «перший створений» кимось маленький кошик - один і той же для всіх. Або, наприклад, всі будуть бачити «авторизацію» якогось іншого користувача. Авторизація тут взята в лапки, тому що, звичайно, ніхто реально не авторизується під цим користувачем, а буде відображатися, наприклад, запрошення увійти в особистий кабінет під ним (технічно кажучи, згенерований при авторизації цього користувача html-код блоку, транслюваний потім всім іншим).
Позбутися цього ефекту не дуже складно, хоча і вимагає уважності і розуміння роботи платформи. Спочатку потрібно локалізувати компоненти, що віддають «один і той же html» всім користувачам, тобто визначити, шаблони яких компонентів голосують «проти» Композиту і вимагають ручного втручання. Сторінки, які спочатку є динамічними, в розрахунок не беремо (кошик, сторінка пошуку, особистий кабінет, сторінка оформлення замовлення тощо).
У налагодженні нам допоможуть: константа BX_COMPOSITE_DEBUG зі значенням true у файлі/( bitrix'local )/ php_interface/dbconn.php (не забудьте вимкнути після зневадження!) і розширення для Google Chrome Bitrix Composite Notifier. У режимі зневадження використовується системна функція AddMessage2Log, яка пише в лог запис, якщо якийсь шаблон компонента голосує «проти» (для роботи функції потрібно встановити константу LOG_FILENAME зі значенням у вигляді повного шляху до файлу лога). Прописуємо константу, або в конкретній сторінці, або глобально, встановлюємо розширення і починаємо аналізувати.
Під анонімним користувачем переглядаємо всі сторінки сайту, які повинні бути «композитними». У нормальному випадку іконка розширення в браузері повинна бути активною (кольоровою).
Якщо на якійсь сторінці іконка неактивна (сіра) - технологія на цій сторінці не працює і необхідно розібратися.
Тут нам і допоможе файл лога. Відкриваємо його, дивимося, які ж шаблони голосують «проти», і адаптуємо їх під композитний режим. Продовжуємо до тих пір, поки на всіх цікавих сторінках не буде «горіти» індикатор розширення. Після цього потрібно переконатися, що весь контент, який повинен бути унікальним для кожного користувача, підвантажується у фоновому режимі, а не кешується разом зі статикою. Зазвичай це малий кошик користувача, блок авторизації, кількість товарів в обраному і т. п. На цьому етапі всю динаміку виносимо в динамічну частину, при необхідності робимо заглушки. Навмисно не описуємо тут сам процес адаптації з точки зору програмування, оскільки він детальним чином викладений в букварі, та й мова в даному випадку більше про організацію процесу переходу, ніж про код компонентів.
Якщо все добре і сторінки почали віддаватися з кешу, варто впевнитися, що кеш живе досить довго і не перезаписується на кожному хіті. Таке цілком може бути, якщо в заглушках або «статичному» контенті використовуються динамічні дані. Наприклад, у шаблоні, позначеному як статичний, прописано вивід функції time () у шаблон. Мало, психанув хтось. Виявити такі сторінки досить просто. Якщо увімкнено режим зневаджування (BX_COMPOSITE_DEBUG) у теці кешу/ bitrix/html_pages/{domain}/ файли перед перезаписом копіюються до файлів з суфіксом * .delete. {microtime}. Якщо таких файлів багато, то є сенс пробігтися по них, виявити відмінності і оптимізувати код, який ці відмінності створює. По можливості позбавляємося від таких ділянок в коді або замінюємо їх JS-варіантом.
Після того, як компоненти підготовлені до роботи з Композитом, можна і потрібно перенести код на бойову версію сайту. На бойовому Композит поки що не вмикаємо. Знову тестуємо роботу всіх інтерфейсів, якщо все зробити правильно, код буде однаково працездатним при будь-якому типі кешування. Правильно працює? Переконалися? Точно? Ще раз перевірили? Ну ок, віримо, давайте кнопочку натискати. Скидаємо кеш у налаштуваннях, вмикаємо Автокомпозит і ще раз все перевіряємо. Не забули вказати всі домени сайту в параметрах Композиту? Молодці. Відкриваємо сайт в режимі «інкогніто», тиснемо F12 і пару разів тиснемо F5. Саме пару разів. На перший хіт сторінка буде віддана сервером «як зазвичай», при цьому буде створений композитний кеш, по другому хіту сервер віддасть створений композитний кеш і отримає директиву «ось тепер його показувати». І на третій хіт ми отримаємо сторінку з «повним застосуванням» Композиту. Якщо все працює як треба, у вкладці Network зневадника буде приблизно така картина:
Як бачимо, документ ми отримуємо зі статусом 304, тобто сторінка не змінювалася, а ресурси беруться з кешу. При цьому у нас продовжують функціонувати інтерактивні елементи інтерфейсів. Можна втратити F5 і насолодитися швидкістю.
Ну і наостанок, як водиться, невелика ложка триваючи до всієї цієї краси.
Типовий композитний кеш зберігається у файлах. Якщо використовувати BitirxVM, хостинг на базі цієї віртуальної машини, пакет веб-оточення від Bitrix або у вас достатньо прямі руки, щоб спорудити потрібний конфіг самостійно - кеш буде віддаватися Nginx-ом, без запитів до бекенду.
Відповідно, у заголовках відповіді буде: X-Bitrix-Composite: Nginx (file). Це вже добре і вже швидко. Але якщо намагатися робити зовсім правильно (знову цей голос...), логічно було б «переселити» композитний кеш в memcached, тобто зберігати його в пам'яті, що, звичайно ж, дасть ще приріст швидкості, особливо, якщо сервер на звичайному HDD. І начебто це все має заробити «з коробки», але на жаль. На даний момент (квітень 2017 року) перемикання типу зберігання в налаштуваннях Композиту в адмінці на memcached і потім оновлення конфіга Nginx через панель управління BitrixVM повноцінного результату не дадуть. Якщо memcached з'єднано за звичайною схемою, через порт ви отримаєте заголовок X-Bitrix-Composite: Nginx (memcached), тобто, на перший погляд, правильний, але сторінка все одно буде кожен раз віддаватися сервером зі статусом 200 OK, а не 304 Not modified, тобто вантажитися заново. А ми-то хотіли домогтися 304 статусу, щоб документ без змін збирався з кешу браузера, не витрачаючи час на отримання тіла документа з сервера. Якщо ж спробувати підключити memcached через unix socket, Nginx з ним взагалі працювати не буде, буде пропускати все «наскрізь» і в заголовку буде стандартний X-Bitrix-Composite: Cache (200). Тобто. так, Композит-то включений, кеш є, але «за ним треба ходити до бекенду», що, скажімо ухильно, дещо знецінює суть технології. Техпідтримка Бітрікса про ці нюанси знає і обіцяє виправити, так що поки використовуйте зберігання в файлах у зв'язці з Nginx в BitrixVM.
А цього, Внутрішнього свого, не слухайте, краще печивом його погодуйте.
