Алексей Коваленко: Текст вакансии для техдиректора

к сабжу: нужна помощь в подготовке не просто текста, а скорее профиля сей личности
что должен уметь, знать, какими четами обладать

заранее благодарен за любые комментарии

Автор :

Александр Шубин: Делаем собственный sale.order.ajax на d7

Написал новую статью о том как сделать собственный компонент заказа:
https://verstaem.com/lessons/making-sale-order-ajax-d7/
Статья получилась большая, с большим количеством форматирования, поэтому полный текст по ссылке

Штатный bitrix:sale.order.ajax очень сложно кастомизировать. Я думаю никто не будет со мной спорить. Битриксовцы подумали над процедурой заказа, о том как заказ должен выглядеть в идеале, а потом реализовали придуманную процедуру в продукте. Все сделано хорошо, однако если у заказчика представления по процедуре заказа отличаются от штатной реализации, то изменить шаблон компонента bitrix:sale.order.ajax практически нереально. Собственно сами битриксовцы на одной из конференций предложили писать отдельный компонент заказа. В этой статье я покажу один из вариантов по реализации такого компонента. И может быть попутно поясню непонятные моменты по созданию заказа на API. Само API по созданию заказа получилось прям отличное, несмотря на сложности кастомизации sale.order.ajax. Если вдруг разработчики читают эту статью, то спасибо вам, прямо приятно работать

По большей части вся статья только про серверный код.

Содержимое статьи:
1 Компонент
1.1 Создание виртуального заказа
1.2 Добавляем свойства заказа
1.3 Добавляем отгрузку (службу доставки)
1.4 Добавляем платежную систему
1.5 Подключение шаблона и сохранение
2 Шаблон компонента
2.1 Корзина
2.2 Работа со свойствами
2.2.1 Форма
2.2.2 Отображаемое местоположение
2.2.3 Получение свойства по коду
2.3 Прочие возможности
2.3.1 Стоимость доставки и заказа
2.3.2 Выбранная служба доставки
2.3.3 Выбранная система оплаты
2.4 Итого по шаблону
3 Добавляем ООП
3.1 Расширяем корзину
3.2 Расширяем заказ
3.3 Итого по ООП
4 Прикручиваем ajax
4.1 Actions компонента
4.2 Поиск местоположений
4.3 Метод расчета стоимости доставки
5 Общий итог

TL;DR
При каждом вызове компонента, неважно аяксом или на странице создаем объект заказа. По необходимости добавляем новые методы в объекты корзины и заказа. В шаблоне компонента пользуемся объектом заказа напрямую, $arResult скорее всего не пригодится. При ответе аяксом возвращаем json где передаем чистые данные + сразу html нужного куска шаблона.


Автор :

uchkuma: Почтовое уведомление о неудачном бэкапе

Screenshot_2.png
Ситуация
Настроено регулярное резервное копирование с выгрузкой бэкапа в облако Битрикс.
По какой-либо причине создание бэкапа не удается полностью завершить (в моем случае не удалось залить в облако).
В журнале резервного копирования это может выглядеть так:



Если вовремя не обнаружить проблему, то ее обнаружат посетители, т.к. рано или поздно работа сайта будет нарушена из-за нехватки свободного места на диске. Хуже, если в рамках данного дискового пространства работают также и другие сайты. Кроме того, вы рискуете остаться без свежей версии бэкапа.

Правильным решением, в случае неудачного создания бэкапа, будет немедленное сообщение об этом случае администратору.
Как реализовать? В голову сразу приходит использовать обработчик события создания бэкапа. К сожалению, поиски по документации, форумам и блогам результата не дали.
Ну ок, тогда лезем в исходники...

====quote====
/bitrix/modules/main/tools/backup.php
=============
Ага, вот они мои родимые!

Screenshot_4.png

Screenshot_5.png

Итак мы нашли два, интересующих нас, недокументированных события: OnAutoBackupError и OnAutoBackupUnknownError.
Добавляем свой обработчик https://dev.1c-bitrix.ru/api_help/main/functions/module/addeventhandler.php
====code====
//добавляем обработчик на оба события
AddEventHandler("main", "OnAutoBackupError", "OnAutoBackupError");
AddEventHandler("main", "OnAutoBackupUnknownError", "OnAutoBackupError");
//сам обработчик
function OnAutoBackupError($error){
//какую информацию передадим в уведомление
    $arEventFields = array(
        "DATE_CREATE"=> date("d.m.Y H:i:s"),
        "ERROR"=> $error['ERROR'],
        "ERROR_CODE"=> $error['ERROR_CODE'],
        "ITEM_ID"=> $error['ITEM_ID'],
    );
    //создаем почтовое событие
    CEvent::Send("BACKUP_UNKNOWN_ERROR", SITE_ID, $arEventFields);
}
============= Добавляем тип почтового события:

Screenshot_6.png

Добавляем для него почтовый шаблон:

Screenshot_7.png

А вот и пример результата наших стараний:

Screenshot_8.png
Теперь при каждом неудачном резервном копировании вы получите уведомление на указанный почтовый адрес.
Аналогичным образом можно настроить уведомления при каждом удачном резервировании - все зависит от степени вашей параноидальности :D
За это, кстати, отвечает событие OnAutoBackupSuccess.

Автор :

Леонид Тропин: Удалить модуль, если он поломал админку.

2017-11-09_12-02-20.png
Памятка на будущее.

Если установил модуль, а он выдаёт тысячи ошибок и страница удаления выглядит как-то вот так:

Удалить можно перейдя по ссылке: ====code====
/bitrix/admin/partner_modules.php?id=#MODULE_ID#&lang=ru&uninstall=Y&sessid=#SESSID#
=============
Где #MODULE_ID# - id модуля, который надо удалить (например "bitrix.liveapi"), а #SESSID# можно получить вот этой функцией в консоли браузера: BX.bitrix_sessid().

Или, если всё равно использовать консоль, можно сделать редирект оттуда:
====code====
BX.adminPanel.Redirect([], '/bitrix/admin/partner_modules.php?id=#MODULE_ID#&lang=ru&uninstall=Y&sessid=#SESSID#', event)
=============

Автор :

User 2000: Кто верит, что программисты работают 8 часов в день? Нужно ли заставлять их работать? На самом деле программисты не только работают, но еще и «пилят» для себя сайты, например вот такие (http://gdrw.ru).

Кто верит, что программисты работают 8 часов в день? Нужно ли заставлять их работать?

На самом деле программисты не только работают, но еще и "пилят" для себя сайты, например вот такие.

Автор :

User 2000: Какие паттерны проектирования использует битрикс

:)
Мы все живем в современном, быстро растущем и меняющемся мире. Новые современные технологии и методики разработки появляются с ужасающей скоростью. Не успеешь закончить какой то проект, как смотришь, уже появились решения, с помощью которых можно было все сделать проще и быстрее.

Сложность больших проектов в их неспособности быстро адаптироваться под все новое и современное. А надо ли? Этот вопрос всегда вызывает много споров и разногласий. В конечном итоге все сводится к тому, что особо не надо, но все равно приходится. Программист который отлично писал на PHP4, но забил на изучение PHP5, может сегодня остаться без работы. Хотя в проектах, которые он делал, фичи PHP5 по большому счету не нужны. Проект и так хорошо работал (и возможно работает) на PHP4.

Сейчас паттерны проектирования(design patterns) считаются хорошей практикой разработки. Это практика стала настолько хороша, что иногда программисты вставляют паттерны везде где только можно, не задумываясь, а нужны ли они тут вообще. Современный разработчик как правило знает несколько распространенных в практике паттернов (обычно это singleton, factory method, observer, decorator, возможно MVC).

На практике не всегда можно сходу "узнать" паттерн в коде приложения, т.к сам паттерн описывает некую архитектурную конструкцию приложения, но не ее реализацию в коде. Итак, хочу познакомить вас с несколькими паттернами проектирования, реализованными в битрикс

Небольшое отступление: вообще тема про паттерны в битрикс возникла случайно в моем разговоре с Александром Сербулом. Он хотел написать про это, но похоже я его немного опередил. Возможно ему будет что добавить от себя.

Observer(наблюдатель)

Мы все очень часто пользуемся обработчиками событий в битрикс, вещаем их на инфоблоки и другие объекты, так вот это очень похоже на observer. Классический observer немного более ограничен, т.к не имеет информации о том, какое событие произошло. Другой кандидат на эту должность это event dispatcher.

Singleton(одиночка)

В точности singleton в битрикс не реализован, но можно предположить, что глобальные переменные $APPLICATION и $DB это как раз прямые кандидаты в singleton.

MVC (Модель - представление - контроллер)

Мы все про него много знаем . Всем нам вдалбливали в голову, что при разработке web-приложений нужно обязательно следовать MVC. Да, я согласен . MVC в битрикс - это компоненты 2.0. Компонент - это контроллер, шаблон - представление, а модули - это модель.

Front controller (единая точка входа в приложение)

Это мой любимый паттерн . В битрикс его нет, но если предположить, что есть некий глобальный комплексный компонент для всего сайта, то его можно будет назвать Front controller.

Adapter

$DB это практически и есть адаптер. Мы подключаем конкретную реализацию для конкретной базы данных, при это все реализации имеют единый интерфейс для работы с базой.

Decorator

Компоненты 2.0 кроме MVC это еще и немножко декораторы. Мы можем изменить поведение компонента вне самого компонента, например в эпилоге компонента. Правда decorator предусматривает наличие двух объектов, а у нас компонент и эпилог объектами не является, но общее с decorator все равно есть.

Стоит добавить, что в битрикс не совсем очевидная реализация вышеперечисленных паттернов. Возможно некоторые другие паттерны я упустил из виду. Кстати компоненты 2.0, если верить мануалу битрикс, реализуют другой паттерн - Carrier Rider Mapper. Я сути этого паттерна не уловил, поэтому для меня это просто MVC.

Примеры всех перечисленных паттернов проектирования можно посмотреть на сайте GDRW.RU.

Автор :

Vitaly: Кеширование в 1С-Битрикс на Redis

Сразу оговорюсь, тут не будет инструкции как сделать типовое кеширование в битриксе. Если оно вам надо, то сюда. Cмена системного кеширования opcache или memcached на Redis не дает никакого преимущества в производительности. Все эти системы позволяют хранить кеш в оперативной памяти, их производительность находится в одном порядке - сотни тысяч операций чтения/записи в секунду. Ниже будет речь о том, как использовать Redis для хранения данных и как эти данные использовать, что это дает. Мы уйдем от кеширования в битриксе в принципе и посмотрим, что из этого получится в плане производительности.

Проблема производительности при фильтрации
Возьмем популярный сайт, созданный на 1С-Битрикс, и популярный раздел на нем, пусть это будет Hoff и раздел "Диваны". Чтобы увидеть скорость генерации страницы битриксом, нужно в URL добавить параметр show_page_exec_time=Y, внизу страницы появится время генерации. На Hoff, кажется, они вырезают этот блок через JS, но в исходном коде страницы он всегда виден. Так даже удобнее. Для объективности лучше делать несколько обновлений страниц и получить некий средний результат. Конкретно в данный момент мне показывается время генерации страницы от 0.23 до 0.5 с для первой страницы раздела диванов.



Казалось бы, 0.5 секунды для генерации ключевой страницы на сайте - это уже катастрофа, но нет. Катастрофа начинается, когда вы будете менять значения фильтра. Например, по цене. Я поставил значение от 15000, время генерации страницы было более 5 секунд. Как видите, ценовой диапазон задается параметром в URL вида prices=15000_399990. Повторное обновление страницы с тем же ценовым диапазоном показало время 0.5 секунд. И все последующие обновления страницы с той же ценой показывают примерно такое же нормальное время генерации страницы. Поменяйте ценовой диапазон на 1 и у вас история повторится - 5 секунд для первого запроса и 0.5 для всех последующих.

Проблема заключается в том, что любое изменение параметров фильтрации, а также сортировки или изменения количества выводимых товаров на страницу вызывают перегенерацию кеша компонента bitrix:catalog.section или его кастомного аналога, который отвечает за вывод товаров. На hoff.ru еще включена опция "Кешировать при установленном фильтре" - это значит, что при любом значении фильтра будет создаваться новый кеш, именно поэтому повторные запросы с установленным ценовым диапазоном выполнялись за относительно небольшое время. Это не проблема именно Hoff, она наблюдается на многих сайтах, использующих 1С-Битрикс: "Читай-город", "Красное&Белое", "ЦУМ" и т.д.

Как кеширует битрикс

Это был иронический пролог, эта цитата меня всегда умиляла.

Сама концепция кеширования 1С-Битрикс заключается в том, что кешируется результат целиком. Будь то $arResult в работе компонентов или готовый кусок html-кода. Любое изменение входящих переменных образует новый кеш, потому что меняется ключ, формируемый из параметров, а с ним и множество запросов к БД, даже если результат остается таким же. Кеш сохраняется в отдельных файлах и при неверной настройке кеширования количество этих файлов может быть очень большим. Использование opcache или memcached существенно ускоряют работу кеша, но принцип его работы остается тем же, только данные хранятся уже не на диске, а в оперативной памяти. Кроме того, весь кеш генерируется на пользовательских хитах, а не где-то там фоновым процессом темными ночами. Если на сайте низкая посещаемость, то пользователи неизбежно столкнутся с высоким временем генерации страниц, а владелец сайта при низком трафике будет видеть высокую нагрузку на сервере, потому что многие пользователи получают некешированные данные. Особенно, если код на сайте неоптимальный и кеширование используется для его сокрытия (когда без кеша 6000 запросов к БД на хите - я такое видел часто).

Решение кеширования на Redis
Почему бы тогда не кешировать отдельные части результата? Например, не список товаров на страницу, а каждый товар отдельно? Отдельно цены, отдельно порядок следования элементов, отдельно свойства инфоблока и т.д. Divide et impera.

Для решения этой проблемы решено было использовать Redis. Данная NoSQL-СУБД широко распространена, быстрая, обладает хорошим функционалом для хранения как строк, так и структур (наборы, списки, хэш-таблицы). Касательно производительности, то, как и многие подобные системы, хранящие данные в оперативной памяти, он быстрый. Допустим, на моем обычном офисном компе показывает 150 тысяч операций записи/чтения (set/get) в секунду. На сервере на базе 2-х Xeon 4114 / DDR4 более 200 тысяч для одного потока. Ограничения запредельные, допустим, строка может быть максимум 512 Мб, а длина списков более 4 млрд. элементов. Если мы работаем не с BigData, то такие пределы даже для большого интернет-магазина являются достаточными.

Для эксперимента я создал типовой интернет-магазин на базе редакции "Бизнес", загрузил в него реальные товары из партнерских XML-файлов "Озон". Загружено было более 12 тысяч товаров, с ценами, названиями, описаниями и фото. Заполнено было лишь 4 свойства инфоблока, на остальные руки уже не дошли. Данная модель не совсем корректна, потому что у многих интернет-магазинов десятки и сотни свойств инфоблока могут быть заполнены различной информацией. В них часто хранят кроме общей информации (бренд, артикул, штрихкод и т.д.) еще и специфические характеристики для типов товаров (диагональ экрана, процессор и т.д.), что по-моему, совсем неправильно. Встречал интернет-магазины, где использовалось более 2000 свойств инфоблока - редактировать инфоблок и элементы стало невозможным.

Следующий шаг - это подготовка данных. Мы будем генерировать весь кеш в фоне, а пользовательские хиты не будут вызывать перегенерации кеша ни в коем случае. И прежде чем генерировать в фоне кеш, мы должны определиться с его структурой. Она получилась такой:
  • Кеш свойств инфоблока - он с большим TTL, можно неделю, храним поля свойств инфоблока, справочники списков и связанных элементов (например, связанный бренд).
  • Кеш разделов - я много разделов не создавал, но на обычном сайте пара тысяч разделов инфоблока может быть вполне нормой. Будем хранить всё дерево разделов, все их связи, описания.
  • Кеш сортировок - мы можем получить из MySQL последовательный список ID товаров во всех используемых на сайте сортировках. По названию, по цене, по рейтингу и т.д. Тут был задействован тип данных List в Redis. Он позволяет хранить упорядоченные ряды
  • Кеш элементов - список с описанием товаров, все поля элемента инфоблока, цены и значения свойств инфоблока
  • Кеш привязок элементов к разделам - список ID товаров, привязанных к конкретным разделам. Использованы ряды (Sets) - этот тип данных позволяет хранить неупорядоченный набор значений. Нам просто надо знать список доступных ID товаров для конкретного раздела,
  • а за сортировку отвечает другой кеш.
  • Кеш цен - список цен для товаров. Использованы упорядоченные ряды (Sorted sets), данный функционал в Redis позволяет хранить уникальные значения, упорядоченные по оценке (Score), в качестве оценки выступает цена. Очень удобно, когда нужно выбрать значения от и до или получить цену по конкретному ID товара.
  • Кеш фильтров - это список ID товаров, доступных для каждого значения фильтруемых свойств. Например, в отдельном ключе хранится список ID товаров, где brand=samsung. Также со всеми фильтруемыми свойствами. Если у вас 1000 вариантов значений для 10 свойств, то у вас будет 1000 ключей с рядами допустимых ID товаров. Опять же использованы неупорядоченные наборы (Sets).
Пока это выглядит громоздко, столько разных кешей, но на самом деле всё очень просто. Все эти кеши - это простые выборки ID через API битрикса буквально каждый в одну строку и запись в Redis по определенным ключам. Заполнение кеша для 12 тысяч товаров занимает 27 секунд. Все связи реализованы как списки и наборы, и хранятся только ID, а значит их выборка и операции с ними должны быть быстрыми. Реально большие структурированные данные хранятся только в кеше с товарами, разделами и свойствами, но к ним запросы будут очень простые - просто выбрать значения по указанным ключам (по сути по ID).

Теперь нам необходимо создать свой компонент для вывода списка товаров. Он не будет использовать кеш битрикса вообще. Основная логика компонента - это узнать список ID подходящих товаров, выбрать эти товары и отобразить шаблон с данными.

Компонент в качестве параметров может получать: ID инфоблока, ID раздела, фильтр по значениям свойств инфоблока, сортировку, количество выводимых товаров на страницу. Я не нашел правильного способа высчитывать пересечения множеств различного типа в Redis прямо в нем, поэтому решено было использовать расчет пересечений функциями PHP, благо количество элементов измеряется лишь десятками тысяч, а в качестве значений выступают только целые числа (ID товаров).

Логика компонента получилась очень простой:
  1. Узнать подходящие ID товаров для раздела
  2. Узнать подходящие ID товаров для фильтра, если есть
  3. Узнать порядок ID товаров
  4. Найти пересечение всех множеств, определенных ID и получить упорядоченный список ID
  5. Выбрать информацию о товарах из определенного выше списка и отдать в шаблон
Пример работы фильтра
С фильтром нужно дать небольшое пояснение как он будет работать. Например, у нас есть раздел телевизоров, у телевизоров есть два свойства: бренд и диагональ. При подготовке кеша мы должны создать индекс значений обоих характеристик. В случае бренда - это справочник, нам надо для каждого бренда создать свой набор (Set) ID товаров, принадлежащих конкретному бренду. В итоге получатся ключи примерно такого вида:
  • i:1:f:BRAND:v:SAMSUNG = 1, 2, 3, 4, 5...
  • i:1:f:BRAND:v:SONY = 6, 7, 8, 9, 10...
  • i:1:f:BRAND:v:LG = 11, 12, 13, 14...
  • и т.д.
Диагональ телевизора является числовым значением, поэтому ее удобнее будет хранить в виде Sorted Set, то есть упорядоченный ряд, в качестве Score будет использована сама диагональ, а в качестве значения ID товара. И все значения можно будет записать в один ключ вида:
i:1:f:DIAGONAL = 50 1, 55 2, 55 3, 49 4, 43 5...
В дальнейшем из этого ключа будет удобно выбирать ID товаров по диагонали от и до. Или даже считать среднее, если оно вам вдруг понадобится.

Выбор телевизора определенного бренда и определенной диагонали - это будет пересечение двух массивов с ID товаров. Допустим, нам нужен Samsung диагональю от 50 до 55 дюймов. Выбираем два массива в PHP: все ID из ключа i:1:f:BRAND:v:SAMSUNG и все ID из ключа i:1:f:DIAGONAL, где Score больше 50 и меньше 55. Ну а далее array_intersect и получаем список допустимых ID товаров для вывода.

Если же вы хотите выбрать телевизор не только Samsung, но и Sony, то механизм будет немного другим. Для бренда нам уже нужен список из двух ключей, его уже можно получить с помощью функции SUNION. Хотя вы также можете получить 2 массива в PHP и соединить их с помощью array_merge. Скорость работы на сотнях и тысячах товаров примерно одинаковая и будет измеряться миллионными долями секунд.

Ну и дальше уже отфильтрованный список ID накладывается на отсортированный полный список и по нему выбираются товары.

Итоги
Сайт с прототипом запущен здесь - https://test2.keng.ru
Постраничную навигацию не прикручивал пока.

Главной целью эксперимента было увеличение производительности страницы со списком товаров на произвольных запросах с различными фильтрами и сортировками. Были получены следующие цифры:
  • Вся хранимая информация для 12 тысяч товаров в Redis заняла 40 Мб. То есть даже если грузить сотни тысяч товаров, тысячи разделов, сотни значений характеристик для каждого товара, то использование памяти будет на уровне пары-тройки Гб, что по современным меркам очень незначительно. И это финальный размер кеша, он не будет расти из-за нагрузки.
  • Время полного обновления кеша - 27 секунд. При увеличении количества товаров и сложности данных это время будет расти пропорционально. Но пусть даже обновление всего кеша займет 300 секунд - это всё равно лучше, чем выполнять обновление кеша на хитах посетителей. И обновлять можно по ночам, раз в сутки. Также можно обновлять части кеша, например, по событиям изменения разделов, товаров, цен, свойств инфоблока, прав доступа и т.д.
  • Время генерации компонента со списком товаров составило несколько тысячных, от 0.005 до 0.008 с.
  • При фильтрации время генерации компонентом увеличивается в 3-7 раз. 15-35 тысячных вместо 5-8 тысячных секунды - это небольшая разница, но наверняка есть варианты оптимизации хранения данных и расчета пересечений, которые позволят убрать это увеличение времени работы компонента.
  • Расходы компонента по памяти около 2-3 Мб для вывода 60 товаров, они стабильны при любом фильтре.
А самый главный результат - при изменении параметров фильтрации и/или сортировки, время генерации остается стабильным. Можно выбрать бренд, изменить цену, указать часть названия товара, изменить сортировку - не важно что и в каких комбинациях, список товаров всегда генерируется несколько тысячных долей секунды, занимает те же пару Мб в памяти и никогда не создается новый кеш.



Эта картинка выше показывает тайминги для работы различных частей компонента.
  • getSorting_TIMER - это время получения упорядоченного списка ID товаров, используя все выборки. Это основной функционал компонента и он занимает почти половину времени работы компонента. В нем по сути ищется пересечение и разница множества массивов, один из которых содержит 12 тысяч элементов, остальные чуть меньше. В реальных условиях в разделах не хранится по 12 тысяч товаров, поэтому время работы компонента должно быть хотя бы на четверть быстрее.
  • getItems_TIMER - время получения информации о товарах
  • Template_TIMER - время обработки шаблона
  • COMPONENT_TIMER - время работы всего компонента, включая шаблон
  • COMPONENT_MEMORY_USAGE - использование оперативной памяти процессом PHP для компонента (изменение пикового значения)
И еще по генерации кеша тайминги:
  • Property BRAND dictionary ready
  • 0.098195 properties ready (3) - время подготовки кеша для 3 свойств инфоблока и создания справочника по брендам
  • 0.009647 sections ready (7) - время подготовки кеша для всех разделов, сейчас их всего 7
  • 0.367995 items-sections ready (12819) - время подготовки кеша связей товаров с разделами
  • 23.35159 items ready (0) - время подготовки кеша с товарами, их около 12 тысяч
  • 3.348402 sorting items ready - время пересчета всех доступных сортировок товаров
Нагрузочное тестирование
Также было проведено нагрузочное тестирование с помощью ab и siege. Под тестовую виртуальную машину было выделено 16 ядер процессора и 32 Гб памяти, используется php_fpm + nginx, opcache, PHP 7.0.23, Redis 4.0.2, Centos 7. Оценка производительности битрикса выдает 220-240 попугаев. При тестировании нагрузка на CPU была около 85%. На Redis идет около 35% нагрузки и только 1 ядра из 16.
  • Запросы к первой странице без фильтрации - около 300 запросов/секунду.
  • Запросы со случайными значениями ценового диапазона - 120 запросов/ в секунду.
Я не возьмусь оценивать это в реальной посещаемости для реального сайта, но наверняка порядок в десятки тысяч посетителей в сутки точно выдерживает при нагрузке на CPU до 10%. Большинство хитов выполнялись вообще без запросов к БД.

Прочие наблюдения при работе с Redis:
  • Redis может работать через сокет и по TCP. Через сокет получается в 1.5-2 раза быстрее.
  • Master-slave репликация примерно на 30% снизила скорость работы master и на 10-20% для slave.
  • Есть возможность записывать и читать данные сразу по множеству ключей, но на небольшом количестве данных (тысячи ключей разом) скорость почти такая же. И нельзя установить TTL сразу на пачку ключей.
  • Бонусом вы можете в Redis хранить php-сессии
  • Redis позволяет использовать несколько баз данных, в них можно разделить логические части. Например, если вы будете использовать Redis для хранения PHP-сессий, то они будут записываться в базу с индексом 0. Базу с индексом 1 вы можете использовать для системного кеша битрикса на Redis. Ну и базу с индексом 2 уже для хранения каких-то своих данных. Это удобно для очистки. Вы можете очистить либо всё (FLUSHALL), либо всю базу (FLUSHDB). Если у вас всё хранилось бы в одной базе с индексом 0, то при очистке кеша у вас бы очищались и сессии. А так вы можете очистить только базу с кешем битрикса или только со своими данными.
Другие итоги
Пересмотр архитектуры значительной части сайта дает существенный прирост в производительности и решает серьезные проблемы. Лично для меня результаты работы с Redis в битриксе похожи на переход с обычного HDD на SSD - тот же эффект wow! Лучший апгрейд, который мог произойти. Да, сильно дороже в производстве и поддержке, усложняется логика, повышается требование к квалификации разработчиков, но результаты того стоят. Если вы не шарашкина контора с полутора сотрудниками, то такая разработка вам по карману. То, что сейчас опубликовано и работает как концепт по времени разработки заняло 24 рабочих часа программиста. Даже если взять топовые зарплаты - это несколько десятков тысяч рублей на рабочий концепт. Ну пусть далее требуется доработка до готового решения, надо написать другие компоненты, оптимизировать, еще месяц-другой, все равно суммы здесь небольшие на разработку, вполне доступные таким компаниям, которые покупают Enterprise за полтора миллиона рублей или сервера для кластера в надежде решить проблемы с производительностью.
И это только вершина айсберга. Использование Redis, его возможности работы с данными, открывают действительно новый потенциал для Битрикса. Нулевое количество обращений к БД на нагруженном сайте - вполне реально. Сотни тысяч посещений на обычном сервере в аренде - запросто. Всё это дает сокращение инфраструктурных расходов в разы.

Автор :

Сергей Эстрин: Адаптивный форум 2.0 и 2.5: поддержка Schema.org, рейтинги и файлы

responsive-forum-schema-org-settings.png
В этих версиях модуля Простой адаптивный форум (обсуждения) было сделано несколько больших доработок. И если с загрузкой картинок и файлов все понятно, это необходимый функционал, который должен был быть реализован (описано в конце статьи), то на остальном я остановлюсь подробнее.

Поддержка микроформата Schema.org

Schema.org - это особый способ разметки html-кода, позволяющий поисковым системам определять, к чему относятся определенные фрагменты текста и объекты на странице.

Я постарался внедрить поддержку такой разметки в модуле настолько полно, насколько смог. Но для разных сайтов может потребоваться разная разметка, т.к. форум может и не называться форумом на сайте, а использоваться и для немного других целей, поэтому я сделал выбор варианта разметки (сущности) формата Schema.org в параметрах компонента:



Всего на данный момент поддерживаются 8 сущностей:

  • DiscussionForumPosting: обсуждение на форуме (этот тип используется по умолчанию, даже если вы ничего не выбирали)
  • SocialMediaPosting: пост в социальной сети
  • Article: статья
  • NewsArticle: новостная статья
  • TechArticle: техническая статья
  • ScholarlyArticle: школьная статья
  • Report: отчет
  • Question: вопрос
Для всех типов кроме Question, для сообщений используется сущность Comment (комментарий), для Question используется сущность Answer (ответ, которая является потомком Comment).

Параметры издателя (имя, адрес, телефон, логотип) используются только для типов Article и NewsArticle, для остальных типов их заполнять не нужно

После установки необходимых настроек, вы можете проверить разметку Schema.org в валидаторах:
Google: https://search.google.com/structured-data/testing-tool
Яндекс: https://webmaster.yandex.ru/tools/microtest/

Рейтинги

Также в этой версии была добавлена поддержка рейтингов (с использованием функционала рейтингов главного модуля). Может быть использован рейтинг двух видов: "Мне нравится", "Нравится/Не нравится".

responsive-forum-ratings-like.png
responsive-forum-ratings-plus-minus.png

При использовании второго вида ("Нравится/Не нравится"), добавляется разметка Schema.org "aggregateRating", что может позволить поисковой системе Google отображать в поиске страницы следующим образом (звезды):

google-stars-rich-snippet-rating.png

Примечание: Имейте в виду, что сама по себе разметка "aggregateRating" не гарантирует появление звезд в поиске, у Google есть свои критерии, для каких сайтов использовать сниппет со звездами, для каких - нет, и она этих критериев не раскрывает.

Компонент "Профиль пользователя"

До версии 2.5, в модуле не было своего компонента профиля пользователя. Вообще, раньше я считал что он не нужен, и профиль может быть реализован с помощью других средств, которых в системе Битрикс достаточно. Но на деле оказалось, что компонент профиля все-таки нужен, хотя бы для того, чтобы просто выводить профиль (а не редактировать), а в редакции Старт есть только стандартный main.profile. D старших же редакциях, компоненты профиля не заточены под использование вне модуля социальной сети и т.д. Поэтому я все же решил его добавить, но не как страницу комплексного компонента форум, а как отдельный комплексный компонент, позволяющий как отображать, так и редактировать профиль. Вы можете разместить его в отдельном разделе, а у комплексного компонента форума указать шаблон пути к странице пользователя.

responsive-forum-user-profile.png

Загрузка файлов и изображений

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

responsive-forum-file-upload.png

Можно установить ограничение на количество файлов, прикрепленных к сообщению, размер одного файла, установить список расширений файлов, которые могут быть прикреплены к сообщениям.

События (программистам)
  • Добавлены события для изменения списка подписчиков на тему при отправке сообщения (OnGetSubscribers)
  • Добавлены события для изменения базовых фильтров для форумов, разделов результатов поиска по форумам (OnGlobalsGetSectionFilter, OnGlobalsGetSectionFields, OnGlobalsGetForumFilter, OnGlobalsGetForumFields, OnGlobalsGetSearchParams). Данные события позволяют, например, реализовать распределение прав доступа к форумам (или просто управлять видимостью форумов в соответствии с определенными условиями). По умолчанию, глобальные фильтры содержат массив array("SITE_ID"=>SITE_ID), т.е. на каждом сайте в многосайтовой системе битрикс будут свои форумы.
Мелочи

Из небольших нововведений - это возможность выводить на главной странице форума не список форумов и подразделов, а один конкретный форум, который можно выбрать в параметрах компонента (но для начала придется разместить компонент со стандартными настройками, чтобы этот форум создать).

Кроме того, был устранен ряд ошибок и произведены мелкие улучшения, например, в почтовых уведомлениях теперь присутствует якорь для перехода на добавленное/измененное сообщение на странице.

Описание api было обновлено в соответствии с добавлением новых функций

Страница модуля: на сайте | в маркетплейсе
Онлайн демо
Обсуждение
СайтВсе модулиTwitter

Автор :

Руслан Мухамедьяров: Как выбрать в карточке товара с SKU, если известен id SKU? Компонент дефолтный. все манипуляции происходят здесь /catalog.element/.default/script.js, но непонятно что там подправить.

Как выбрать в карточке товара с SKU, если известен id SKU?
Компонент дефолтный.
все манипуляции происходят здесь /catalog.element/.default/script.js, но непонятно что там подправить.

Автор :
1 2 3 6
Страница 1 из 6