Ко мне за помощью обратились знакомый, ИТ директор крупной компании, для которой сайт - это часть бизнеса. Мол "Серега, у нас сайт укладывает сильный сервер. Не мог бы ты заехать на часок и помочь разобраться, в чем дело, это мы накосячили, или это ваш Битрикс тормозит. "
Типовая ситуация, согласитесь
Святое дело помочь, тем более находятся они от нас в 10 минутах пешком.
Приехал, сели с ИТ директором и двумя разработчиками, смотрим, чем располагаем.
Первым делом проверили конфигурацию системы. Конечно, все оказалось настроено не так, как нужно. Чуток увеличили размер APC руками админа и установили MaxClients, и система стала значительно лучше себя вести.
Но не летает, прямо скажем. А сервер-то мощный. Должен же летать, рассуждаю я.
Проверил параметры монитора производительности по первым двух закладкам. Система теперь более менее. Битрикс настроен правильно. И что важно для этой истории, монитор производительности показывает, что Автокеширование включено! А иначе бы мы показали, что Битрикс настроен не оптимально
Смотрю главную страницу сайта, которая отрабатывает за 1-3 секунды. Страница сложная, содержит два-три десятка компонентов с данными из инфоблоков. Проект-то большой. Открываю страницу в режиме разработки и включаю отладку. О боже, 980 SQL запросов на главной странице!
Как так, работает же Автокеширование, такого быть не может, если только... да, если только у каждого компонента на главной странице не установлено "НЕ КЕШИРОВАТЬ".
Моему гневу нет предела! "Кто делал вам сайт?". QSoft - отвечает веб-разработчик.
Я пять минут еще возмущаюсь и бурно объясняю суть вопроса с автокешированием и квалификацию разработчика, достаю телефон и начинаю набирать телефон Миши Токовинина, объясняя, что сейчас-то я им скажу все, что думаю про их хваленую разработку, и тут.... "ЭТО СДЕЛАЛ Я",- громко говорит второй разработчик.
Немая пауза,тишина, все смотрят на него с вопросом
я отключаю телефонный звонок.
"Да достали меня контент редакторы, мы заносим данные, а они сразу не появляются на сайте. Ну я по всему сайту прошел и отключил кеширование в компонентах" (Это чтобы монитор производительности не жаловался, что Битрикс не оптимально настроен, если бы он просто выключил Автокеширование одной кнопкой
)
Ну хорошо, говорю я, но можно было проблему решить двумя способами:
1. Дать контент редакторам права на кнопку "Обновить" в панели инструментов.
2. Настроить события в инфоблоках, чтобы они чистили кеш при изменении данных.
Но что-то разработчик не знал, что-то поленился делать. И это очень типичная ситуация сегодня.
Проект мы, конечно, вылечили за 30 минут. Стал он летать, железки освободились и стало понятно, что к своим 50 тысячам посетителей они еще спокойно прибавят в два три раза больше трафика и справятся.
Но после этой красноречивой истории я понял, что мы опять имеем дело с проблемой, которую нужно решать на уровне продукта, и никакое обучение разработчиков не даст хорошего результата, и на нас будут валиться шишки. Если мы переложим решение на плечи разработчиков, они или не дочитают документацию, или поленятся делать.
Решение должно удовлетворять 95% сайтов и не должно требовать программирования от разработчика! А 5% сайтов возможно захотят что-то настроить и перепрограммировать штатный механизм, и такую возможность нужно сохранить.
Ну и самое главное.
Контент редактор должен видеть изменения на сайте СРАЗУ после их выполнения!
Есть, правда, еще один важнейший критерий для реализации. Цена реализации механизма в терминах производительности должна быть крайне незначительной, чтобы отслеживание зависимостей или обновление информации не создавало нагрузку на проект.
Первый модуль, с которого мы решили начать - конечно, инфоблоки.
Много вариантов решения мы перепробовали и обсудили. Часть обсуждений прошла на форуме и в нашей соцсети. Большинство решений не подходили в силу высокой цены реализации. Иногда это становилось ясно уже после реализации и тестов.
Решение пришло, когда мы с Максимом Смирновым обедали
Как это реализовал Максим, я точно не знаю
Попробую объяснить, как это задумывалось и в чем принцип.
Концепции нашего продукта предлагает разработчикам для вывода данных использовать наши или создавать свои компоненты. Компоненты можно физически поместить на странице сайта и для каждого настроить параметры, среди которых есть параметр кеширования.
Все компоненты написаны на API функциях. Например, для получения данных из инфоблоков мы обращаемся к классу инфоблока и по API через разные методы Get... получаем данные.
Т.е. мы знаем с вами, что на некоторой странице с определенным уникальным URL-ом размещен компонент с именем, например bitrix:news.line, он вызвал API функции определенных инфоблоков и после этого выполнил кеширование информации на уровне компонента.
Мы решили, что этой информации достаточно, если немного подумать
, чтобы построить зависимость между данными и местом их представления. Мы автоматически сохраняем необходимую информацию о зависимостях в новый механизм главного модуля - Сache Dependencies.
Теперь вернемся к контент редактору.
Мы точно не знаем где и как будут меняться данные. На публичных страницах, в административном интерфейсе или через импорт-экспорт данных из 1С, или любыми другими методами. Но мы знаем, что для этого будут вызваны методы класса инфоблоков которые выполняют модификацию. Это значит, мы можем обратиться к механизму Сache Dependencies и сообщить ему, что изменились такие-то данные. А механизм Сache Dependencies сам отследит, где на сайте представлены данные, которые используют только что изменившийся контент. И если зависимость есть и данные сохранены, то неактуальные данные будут удалены, и сам компонент обеспечит обновление информации.
Для успешного и быстрого функционирования технологии Сache Dependencies пришлось доработать механизм хранения данных в кеше. В результате доработки технология Сache Dependencies удаляет зависимый кеш мгновенно и не создает нагрузку при поиске зависимой информации на сайте.
Технология Сache Dependencies, как и весь продукт, может хранить кеш как в файлах, так и используя Memcached, APC, eAccelerator. Для этого достаточно просто .
Таким образом мы добились поставленной задачи!
Все наши компоненты, все компоненты партнеров и клиентов теперь автоматически, без изменений кода, научились отслеживать зависимости с источниками данных в инфоблоках и обновляться автоматически, независимо от параметров кеширования!
Как давно я хотел такой механизм
Да, пока технология автоматически не включена на всех сайтах.
Если вы хотите попробовать, вам необходимо в файле /bitrix/php_interface/dbconn.php вписать строчку:
define('BX_COMP_MANAGED_CACHE', true);
Да, не забудьте обновиться до версии 9.1.
Думаю, что к сентябрю эта технология будет включена по-умолчанию, а в настройках продукта появится еще одна общая кнопка вроде Автокеширования.
Возможно мы решим объединить технологии и создадим Автокеширование 2.0
Счастье контент редактора теперь не зависит от квалификации разработчика!
Добавляйте новости и сразу обнаруживайте их там, где они должны были появиться
Механизм автоматически включается начиная с версии 9.1 главного модуля. Пока Сache Dependencies работает только для инфоблоков. Но мы планируем расширить ее на все контентные модули продукта. Возможно, Максим создаст отдельный API, чтобы разработчики сами могли регистрировать зависимости и отслеживать их, используя технологию Сache Dependencies. Техническое описание технологии вы можете прочитать у Максима в блоге
На днях мы выпустили новый мастер Интернет-магазина и я уверен, что клиенты по настоящему оценят возможности Сache Dependencies. Оценят - в смысле не заметят ее
Это одна из тех скрытых технологий, которая после своего появления становится просто чем-то саморазумеющимся. Мы просто добавляем товары, и они сразу оказываются на сайте. Мы изменяем товар, и он уже тут. Но при этом все кешируется, никаких лишних запросов. Наилучшая производительность.
Теперь бы еще проблеме каммент-спама чутка внимания уделили... (мечтает
(а за кэш депенденси -- горячий респект все же, у нас девушка, которая запихивает кое-что на сайт, тоже счастлива
А про какой спам? В блогах и форумах?
Выявляются однозначно по наличию ссылки в посте ("новый юзер или аноним, сразу постит ссылки"). Как следствие, идеально было бы иметь в блогах право "постить ссылки", которое получают не все, а у кого нет -- уходит на премодерацию (самое смешное, что в форумах можно запретить ссылки).
Совсем бы идеально -- еще и интегрировать это с проактивной защитой -- "три поста со ссылками ушло на премодерацию -- в стоп-лист". Еще идеальнее -- с байесовским фильтром, чтобы сам учился (причем, в почтовом модуле что-то такое по-моему даже и есть, хотя могу ошибаться).
И еще полезно было бы -- возможность в проактивном фильтре задавать списком запрещенные подсети. Хотели тут залить список открытых прокси, откуда самые ушлые спаммеры ходят -- обматерились.
В принципе, в саппорт писал, могу отдельный документ собрать типа "кой бы хотелось видеть защиту от блого-спама".
Круто!
Немного смутило только вот это:
Как так, работает же Автокеширование, такого быть не может, если только... да, если только у каждого компонента на главной странице не установлено "НЕ КЕШИРОВАТЬ".
То есть 980 запросов — это в общем-то нормально, нужно только закешировать? Это же кошмар — 980 запросов. Кеш же всё равно по умолчанию раз в час очищается, а значит будет сайт время от времени делать по 200 запросов делать, чтоб какой-нибудь компонент обновить?
Думал никто не заметит. Тоже поулыбался
Сделали его на событиях.
Есть возможность отслеживать изменения в
- инфоблоках
- форумах
- блогах
Но, охота это и в соц.сеть. У нас на главную много из нее выводится. Устали с кешем бороться
Планируется сделать для соц.сети и в какие сроки?
Уже частично использовали в Корпоративном портале, в списках, в пользователях.
Частично уже и в Соц.сети использовали. Уверен, что в скором времени это будет составная часть всего продукта.
Если честно, позор, что не сделали раньше.
Если кому нужно будет удалить кэш определенного инфоблока, то:
$GLOBALS['CACHE_MANAGER']->ClearByTag('iblock_id_' . $IBLOCK_ID);$IBLOCK_ID — ID инфоблока.
Как большинство разработчиков считаете, что если есть код и концепция, значит найдется умный разработчик, который воспользуется этим с умом. А если не воспользовался - то нобелевскую ему не давать.
Но в жизни все немного иначе.
Да, теги с кешем - это не новость. Но я не писал вам про теги с кешем, а об этом писал Максим в своем посте.
Как обычно бывает, было два пути.
Путь первый. Сделать технологию и объяснять разработчикам как этим пользоваться и как переписать свои компоненты так, чтобы они умели чистить кеш. (как делаете вы
По этой дороге мы уже ходили. Для 40 тысяч проектов это не просто долгая дорога, а необычайно долгая дорога. Фактически я сегодня знаю, что при активном продвижении новой технологии, через полный год использование технологии на уже работающих проектах не превысит 5%. Почему? Думаю вы сами понимаете, почему разработчики и клиенты не хотят влезать в работающий проект.
Путь два. За счет архитектуры продукта суметь сделать технологическое решение доступным всем клиентам без доработки и программирования.
А мы сделали решение, которое ставится сейчас с обновлением продукта и НА ВСЕХ проектах и на ВСЕХ КОМПОНЕНТАХ и партнеров и наших делает работу удобной и простой. И теперь я знаю, что через год, эта технология будет работать на 95% проектов независимо от квалификации разработчиков сайта и его внимательности к нашим новостям и партнерским конференциям
А вот за это я уже готов претендовать на Нобелевскую премию, ну или хотя бы Битриксовскую премию
У нас используется на сайте в боковой колонке список последних обновлённых тем форума (сквозное размещение). Ранее обработчиком легко обновляли эту информацию на всех страницах единовременно - кеш-то был единый. Теперь этой возможности нет, на каждой странице сайта отдельный кеш компонента. Тысячи кешей одного компонента, можете представить себе "рост" производительности, ведь теперь нужно генерировать кеш на каждой странице. Можете также представить себе объём кеша!
Жаль, что вместе с "лекарством" Битрикс забывает выпускать инструкцию, содержащую информацию о "противопоказания". А противопоказания в этой ситуации для многих сайтов значительно превышают лечебный эффект.
Жесть, одним словом, Сергей, просто жесть!
Проблему увидели на другом проекте несколькими днями ранее вашего поста. Решение уже в разработке, скоро выпустим.
Сможете включить управляемое кеширование и в вашем случае все будет работать без переделки компонент и не будет описанной проблемы.
...
этой информации достаточно, если немного подумать smile:), чтобы построить зависимость
В результате изменения структуры компонент переносится на другую страницу, и система ломается... до истечения времени автокеширования. Так?
Не знаю проблема или нет, у меня есть обсуждения с оценками(своя реализация на основании форума, так как стандартная не подошла по ооочень большому списку несоответствий с обычными требованиями) к инфоблоку. Вобщем в итоге "мой" модуль обновляет свойство соответствующего элемента инфоблока, где хранится средняя оценка, вот так:
CIBlockElement::SetPropertyValues($arParams["ELEMENT_ID"], $PRODUCT_IBLOCK_ID, $vote, "ZVOTE");
В итоге когда я вывожу данный инфоблок списком, он все еще закеширован, и у меня выводятся старые оценки.
Настройка кеширования компонента стоит "Авто" и в настройках сайта все кеширования включены.
Вопрос вот в чем, должен ли ваш код отрабаывать в данном случае? (при обновлении только лишь свойства готового элемента)
PS: Обновился сегодня до последней версии (Эксперт) и вписал эту волшебную строку:
define('BX_COMP_MANAGED_CACHE', true);