Почему мне нужно следить за чистотой моего ПК.

Во многом оптимизация 1С и скорость работы зависит от работы с блокировками, запросами и индексами. Постараемся ответить на вопрос «как ускорить работу 1С» (вопрос, как ускорить запуск 1С, мы рассмотрим в другой статье) и избежать жалоб пользователей на «долгое проведение документов», которое неминуемо сказывается на бизнес-процессах.

Часть 3. Производительность 1С

Блокировки в 1С 8.3: поиск и устранение в коде, перевод на управляемые блокировки

Блокировки являются частью механизма ACID. Рассмотрим его концепцию, представленную в виде упрощенной схемы, на примере SQL SERVER

В автоматическом режиме управление блокировками осуществляется самой СУБД. При этом на MS SQL сервере появлялись такие побочные эффекты, как блокировки пустых таблиц и приграничного диапазона данных (уровень Serializable), что создавало дополнительные проблемы в многопользовательской работе. Для решения этих проблем фирма 1С создала управляемые блокировки.

1С Управляемые блокировки

Механизм блокировок был вынесен на сервер 1С, а на уровне СУБД изоляция снизилась до минимума. На MS SQL уровень изоляции был понижен до Read Committed с механизмом разделяемых блокировок на платформе 8.2 и механизмом версионирования строк на платформе 8.3 (так называемый Read Committed Snapshot Isoliation). Точнее, это одноименное свойство базы данных и два режима работы Read Committed, зависящие от этого параметра.

При последнем уровне изоляции (RCSI), механизм позволил не пересекаться на сервере СУБД читающих и пишущих транзакций по одним и тем же ресурсам. Всю основную работу на себя взял сервис блокировки 1С, определяющий на основании родных метаданных, пускать или не пускать транзакции на сервер СУБД, чтобы не происходило нарушений бизнес-логики. Проблемы с блокировками пустых таблиц и приграничных диапазонов ушли в прошлое.

СУБД	Вид блокировки	Уровень изоляции транзакций	Чтение вне транзакции
Автоматические блокировки
Файловая База Данных	Таблиц	Serializable	Dirty read
MS SQL Server	Записей		Dirty read
IBM DB2	Записей	Repetable Read или Serializable	Dirty read
PostgreSQL	Таблиц	Serializable	Consistent reading
Oracle Database	Таблиц	Serializable	Consistent reading
Управляемые блокировки
Файловая База Данных	Таблиц	Serializable	Dirty read
MS SQL Server 2000	Записей	Read Commited	Dirty read
MS SQL Server 2005 и выше		Read Commited Snapshot	Consistent reading
IBM DB2 до версии 9.7	Записей	Read Commited	Dirty read
IBM DB2 версии 9.7 и выше	Записей	Read Commited	Consistent reading
PostgreSQL	Записей	Read Commited	Consistent reading
Oracle Database	Записей	Read Commited	Consistent reading

Для того чтобы узнать, в каком режиме блокировок находится база программы 1С, необходимо выполнить следующий запрос из SSMS в контексте нужной базы:

Блокировки 1С. Пользователь не будет ждать на блокировках, произойдет ускорение работы 1С, если придерживаться определенных правил:

Продолжительность транзакций должна быть максимально сокращена по времени. Проведение в транзакции длительных расчетов в 100% случаев приведет к блокировке при работе на OLTP системе.
Исключены длительные внешние операции в рамках транзакции, например, отправка и принятие подтверждений по электронной почте, работа с файловой системой и другие дополнительные действия. Все операции должны быть вынесены в отложенные короткие задания.
Максимально оптимизированы запросы.
Создание индексов должно производиться только по мере необходимости, для обеспечения оптимальной производительности запросов в пределах приложения.
Минимизированы включения в кластерный индекс часто обновляемых столбцов. Обновления столбца/ов кластерного ключа индекса требует блокировки, как на кластерном индексе, так и на всех некластеризованных индексах (так как их строка-локатор содержит ключ кластерного индекса).
По возможности создан и используется покрывающий индекс для сокращения времени выборки данных.
Использование самого низкого уровня изоляции транзакциями, что потребует перехода на режим управляемых блокировок.

Инструменты для диагностики блокировок:

Технологический журнал;
Центр управления производительностью из инструментария 1С;
Облачные сервисы Гилева;

Ниже приведен пример мониторинга системы сервисом Гилева. Общая длительность блокировок ~15 часов. Более 400 активных пользователей. После принятия решений и оптимизации – время таймаутов меньше минуты, а количество блокировок сократилось в ~670раз.

Было:

Стало:

В ситуации, когда «все висит и долго проводиться», а сервисы мониторинга не настроены или не используются совсем, помня принцип Парето, необходимо сосредоточить внимание на коде.

В автоматическом режиме наличие блокировок на сервере можно обнаружить с помощью системной процедуры в контексте нужной базы. Данная хранимая процедура позволяет определить, в каком режиме работают блокировки, их статус, тип и прочее:

Доработав процедуру под 1С, можно получить наглядную информацию о том, что происходит в данный момент на сервере, с учетом специфики таблиц 1С:

Фрагмент 1

//Блокировки в терминах 1C SELECT * FROM dbo.ReturnLockName1C(DEFAULT,DEFAULT) as t Where TableName1C IS NOT NULL ORDER BY t.Resource

Применение данного механизма позволяет получить полную информацию об имеющихся блокировках на текущий момент. Если в отчете одни S-блокировки, проблема может заключаться в длительном запросе или запросах. Для установления причины и места их появления в коде можно пойти разными путями: использовать объекты DMO SQL-сервера (но учитываем, что данные из них сбрасываются после перезагрузки сервера) или настроить Data Collector, сохранив данные мониторинга в таблицах на определенное время. Главное, получить тексты проблемных запросов.

Использование объектов DMO SQL-сервера

Выводим дату старта сервера для понимания актуальности данных. Разбиваем пакет по рейтингу чтения (физического, логического, нагрузке на процессор). В этом случае используются основные данные из sys.dm_exec_query_stats. Текст запроса переводим в термины 1С. Если по тексту запроса можно понять контекст вызова, то осталось посмотреть план запроса, найти проблемные операторы и понять, что можно сделать.

Фрагмент 2

//время запуска SELECT sqlserver_start_time FROM sys.dm_os_sys_info; //Toп запросов no физическому чтению SELECT TOP (50) (total_physical_reads) AS Итого_физическое_чтение,

Определение проблемных запросов в результате сбора Data Collector

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

После того, как проблемные запросы собраны сервером без сторонних мониторингов, можно составить рейтинг полученных данных по необходимым параметрам.

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

Пример проблемного запроса и образец настройки технологического журнала:

Оптимизация запросов как возможность ускорить 1С 8.3

Последствия неоптимальных запросов могут проявляться в виде длительных проведений документов, мучительно долгого формирования отчетов, «зависания» системы и прочих неприятных событий.

При работе с запросами НЕЛЬЗЯ:

Соединять таблицы с подзапросами;
Соединять обычные таблицы с виртуальными;
Использовать логического «ИЛИ» в условиях;
Использовать подзапросы в условиях соединения;
Получать данные через точку от полей составного типа без ключевого слова «Выразить».

При работе с запросами МОЖНО:

Создать индексы в условиях запроса, полях соединения, агрегации и сортировки;
Фильтрацию виртуальных таблиц необходимо производить с использованием параметров отбора.

Использование индексов и их влияние на качество производительности системы

Очень много написано про индексы, о необходимости их использования и влияние на качество работы системы. Постараемся разобраться в тонкостях «устройства» индексов, вариантах применения и преимуществах перед обычными таблицами.

Индексирование является важной частью ядра СУБД. Отсутствующие индексы, или наоборот, их излишнее количество, влияют на скорость выборки, модификацию, добавление и удаление данных. Рассмотрим индексирование на примере наиболее распространенной СУБД компании Microsoft.

Для общего понимания, как это работает, рассмотрим подробности устройства механизмом хранения данных, которые мы обычно представляем в виде таблицы (например, Excel).

Единицей физического хранения данных является страница - модуль размером в 8 Кбайт, принадлежащий только одному объекту (например, таблице или индексу). Страница является наименьшей единицей для чтения и записи. Страницы собраны в экстенты. Экстент состоит из 8 последовательных страниц. Страницы экстента могут принадлежать как одному, так и нескольким объектам. Если страницы принадлежат нескольким объектам, экстент называется «смешанным».

Ее содержимое можно посмотреть ниже:

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

По умолчанию, если не использовать специальных операторов T-SQL, пустая таблица создается в виде «кучи» – простого набора страниц и экстентов. Данные в «куче» не имеют никакого логического порядка. Ядро SQL Server отслеживает принадлежность страниц и экстентов к определенному объекту с помощью специальных системных страниц, называемых «картами распределения индекса» (Index Allocation Map). Каждая таблица или индекс имеет по крайней мере одну страницу IAM, называемую «первой страницей IAM».

Таким образом, после создания обычной таблицы, по умолчанию, получается хаотичное расположение данных. Посмотреть статус таблицы можно с помощью следующей процедуры:

Основные индексы, которые использует платформа 1С

Фрагмент 3

Мифы и реальность:

Миф первый: кластерные индексы и таблица данных – это две разные сущности, хранящиеся отдельно друг от друга.

Миф второй: кластерных индексов в одной таблице может быть много.

Скачал программу для оптимизации СУБД. Создал рекомендованные индексы. Скорость выборки увеличилась на 50%. Изменение и добавление данных замедлилось в 7раз.

Кластеризованный (кластерный) индекс

Кластеризованные индексы представляют собой набор страниц, которые сортируют и хранят строки данных в таблицах или представлениях на основе их ключевых значений – столбцов, включенных в определение индекса. Существует ограничение на данный вид индексов в 16 столбцов и 900 байт. Для каждой таблицы существует только один кластеризованный индекс, потому что строки данных могут быть отсортированы только в одном порядке. Создание кластеризованного индекса происходит посредством реорганизации таблицы, а не копирования данных, что дает возможность сохранить таблицу в виде сбалансированного дерева.

Фрагмент 4

SELECT NAME, TYPE, TYPE_DESC FROM sys.indexes WHERE object_id = OBJECT_ID("ДанныеТрассировки")

Некластеризованный индекс

Некластеризованные индексы имеют структуру отдельную от строк данных. В некластеризованном индексе содержатся значения ключа кластерного индекса, и каждая запись содержит ключ кластеризованного индекса (не RID, т.к. таблицы 1С не используют кучи, за редким исключением).

Можно добавить неключевые столбцы на конечный уровень некластеризованного индекса и обойти существующее ограничение на ключи индексов (900 байт и 16 ключевых столбцов), выполняя полностью индексированные запросы.

После добавления некластерного индекса, произошло копирование данных, и появился еще один объект:

Фрагмент 5

SELECT NAME, TYPE, TYPE_DESC FROM sys.indexes WHERE object_id = OBJECT_ID("ДанныеТрассировки")

Схема кластерного индекса после получения его из кучи в виде сбалансированного дерева:

Схема некластерного индекса, полученного из кластерной таблицы (обратите внимание, столбец row locator имеет ключ кластерного индекса):

Влияние индексов на производительность запросов

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

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

Обратим внимание, что кластерный индекс блокировать ни в коем случае нельзя, т.к. это закроет доступ к данным таблицы. Это относится только к тем индексам, которые вы создали самостоятельно, через T-SQL. Причина создания индексов средствами T-SQL, минуя «1С:Предприятия», связана, в первую очередь, с ограниченными возможностями платформы 1С в части манипуляции индексами и включения в созданный/емый индекс дополнительных полей.

Инструкция T-SQL, которая выполняет действие по блокированию индекса:

//Блокируем отдельный индекс в таблице -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 DISABLE; //Включаем нужный индекс -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 REBUILD;

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

Определение необходимых или лишних индексов для ускорения выполнения запросов

По умолчанию 1С создает определенный базовый набор индексов. Зачастую, их просто не хватает. SQL-сервер имеет механизмы, которые позволяют понять на основании рабочей нагрузки, насколько необходимы имеющиеся индексы.

Помощник по настройке ядра СУБД (Database Engine Tuning Advisor) анализирует базы данных и составляет рекомендации по оптимизации производительности запросов. Его можно использовать для выбора и создания оптимальных наборов индексов, не обладая экспертным уровнем понимания структуры баз данных или внутренних процессов SQL Server. Помощник по настройке ядра СУБД позволяет выполнять следующие задачи:

Устранение неполадок производительности конкретного проблемного запроса;
Настройка большого набора запросов в одной или нескольких базах данных.

Объекты DMO (dynamic management objects), к которым относятся динамические административные представления и функции динамического управления. Например, инструкцией T-SQL можно получить все индексы, которые не использовались с момента последнего запуска сервера.

Фрагмент 6

WITH vl as (SELECT OBJECT_NAME(I.object_id) AS objectname, I.name AS indexname, I.index_id AS indexid FROM sys.indexes AS I INNER JOIN sys.objects AS O ON O.object_id = I.object_id WHERE I.object_id > 100 AND I.type_desc = "NONCLUSTERED" AND I.index_id NOT IN (SELECT S.index_id FROM sys.dm_db_index_usage_stats AS S WHERE S.object_id=I.object_id AND I.index_id=S.index_id AND database_id = DB_ID("Имя_базы’))) SELECT objectname,T1.NameTable1C, indexid, indexname FROM vl OUTER APPLY dbo.ReturnTableName1C(objectname) as T1 ORDER BY objectname, indexname;

Инструкция, с помощью которой можно создавать необходимые индексы, которые рекомендует ядро СУБД:

Фрагмент 7

SELECT T1.NameTable1C as Наименование_таблицы_1C, "CREATE INDEX " + " ON "
Оптимизатор запросов во время генерации плана выполнения запроса выявляет необходимость создания недостающего индекса. Эту информацию он сохраняет в XML ShowPlan. Т.к. планы запросов хешируются и инструкции сохраняются (до следующего перезапуска сервера), то их можно извлечь, обработать и получить готовые инструкции создания необходимых индексов для любого плана выполнения в кэше. Стоит обратить внимание на частоту выполнения запроса: чем она выше, тем более актуальными являются результаты выполнения запроса и, соответственно, собранные показатели. Если запрос выполнялся единожды, его результаты не столь показательны.

Фрагмент 8

CROSS APPLY query_plan.nodes(’//StmtSimple") AS stmt(stmt_xml) WHERE stmt_xml.exist("QueryPlan/Missinglndexes") = 1) SELECT TOP 30 DatabaseName as Наименование_базы, TableName as Наименование_таблицы, T1.NameTable1C as Наименование_таблицы_1С, equality_columns as Столбцы_сравнения, include_columns as Столбцы_для_включения,

Фрагмент 9

USE [Имя_базы] GO CREATE NONCLUSTERED INDEX ON .[_Document497] ([_Fld12771_TYPE],[_Fld12771_RTRef]) INCLUDE ([_Date_Time],[_Fld12771_RRRef],[_Fld12782RRef],[_Fld12784]) GO Некоторые особенности индексирования по агрегатным полям и полям сортировки.

Создание индекса на столбцах, указанных в предложении «УПОРЯДОЧИТЬ ПО» (ORDER BY), помогает оптимизатору запроса быстро организовать результирующий набор данных, так как значения столбцов отсортированы в индексе заранее. Внутренняя реализация механизма «СГРУППИРОВАТЬ ПО» (GROUP BY) также сначала сортирует значения столбцов для быстрой группировки необходимых данных.

При использовании типовых рекомендаций стоит проверять результат до и после оптимизации. Приведем пример использования логического объединения «ИЛИ» и его альтернативы (для устранения проблемы типовыми рекомендациями) – методики изменения запроса через синтаксис «ОБЪЕДИНИТЬ ВСЕ».

Сам запрос 1С с «ИЛИ»:

ВЫБРАТЬ Код, Наименование, Ссылка ИЗ Справочник.Контрагенты КАК Контрагенты ГДЕ Контрагенты.Код = "000000004" ИЛИ Контрагенты.Код = "0074853" ИЛИ Контрагенты.Код = "000000024" ИЛИ Контрагенты.Код = "009679294" ИЛИ Контрагенты.Код = "0074742" ИЛИ Контрагенты.Код = "000000104";

Модификация запроса с «ОБЪЕДИНИТЬ ВСЕ»:

ВЫБРАТЬ Код, Наименование, Ссылка ИЗ Справочник.Контрагенты КАК Контрагенты ГДЕ Контрагенты.Код = "000000004" ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Код, Наименование, Ссылка ИЗ Справочник.Контрагенты КАК Контрагенты ГДЕ Контрагенты.Код = "0074853" ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Код, Наименование, Ссылка ИЗ Справочник.Контрагенты КАК Контрагенты ГДЕ Контрагенты.Код = "000000024" ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Код, Наименование, Ссылка ИЗ Справочник.Контрагенты КАК Контрагенты ГДЕ

Фактический план запроса (для удобства отображения и сравнения производительности, запросы перехвачены и выполнены в SSMS):

В данном случае, после оптимизации производительность упала в два раза из-за многократного использования оператора Key Lookup, который всегда сопровождается оператором Nested Loops. Поэтому, используя схему по оптимизации запроса, следует замерять целевое время до и после использования доработок. Данный пример показан с целью «доверяй, но проверяй», поскольку между типовыми рекомендациями и практическими задачами может быть несогласованность.

Одной из распространенных задач, которую приходится решать администраторам и программистам, является проблема низкой производительности баз данных "1С:Предприятие". Как показал наш опыт, решение данной проблемы - это всегда комплексная задача и для ее успешного разрешения приходится проверять многие гипотезы:

Возможные аппаратные проблемы

Слабый сервер (или его отсутствие). Подобная ситуация наиболее характерна для небольших организаций, где сервером называют обычную рабочую станцию с установленной Windows XP. На таком компьютере чаще всего отсутствуют необходимые "признаки сервера": резервирование основных компонентов (жесткие диски, блоки питания, вентиляторы), быстрая дисковая система (несколько дисков SCSI, SATA, SAS, объединенных в массив), два или более процессоров, достаточный объем оперативной памяти. Сложно ожидать от компьютера, не обладающего хоть частью из вышеперечисленного чудес производительности и надежности в работе! Если с Вашей базой банных работает более 10 человек, то Вам стоит задуматься о приобретении и настройке специализированного сервера.

Перегрев оборудования. Наиболее частая причина, которая вызывает множество мелких и не очень проблем при эксплуатации компьютерного оборудования. Чаще всего проявлется в непонятном ("глючном") поведении оборудования, когда компьютер начинает плохо загружаться, сам выключаться, "тормозить" и т.д. А если плохо работает компьютер, то также плохо начинают работать и программы, запущенные на нем. Особенно это касается программ, которые могут создавать пиковую (неравномерную) нагрузку на основные компоненты компьютера: процессор, память, сетевой адаптер, жесткий диск. Например, такая ситуация может возникнуть при формировании достаточно большого отчета в программе "1С:Предприятие" или при интенсивном проведении накладных. Нужно соблюдать температурный режим при эксплуатации компьюторного оборудования, если этого правила придерживаться, то многие проблемы исчезают.

Неправильные настройки аппаратных компонентов. Программы "1С:Предприятие" чувствительны к качеству локальной сети, поэтому необходимо уделять повышенное внимание к подбору компонентов для локальной сети. Рекомендуется использовать по возможности одинаковые сетевые платы, коммутаторы, аккуратно монтировать локальную сеть.

СОВЕТ: Если процессор Вашего сервера поддерживает технологию HT (Hyper-Threating) и на сервере установлена только одна база данных "1С:Предприятие", то рекомендуется отключить эту опцию в BIOS. Это связано с тем, что при включенной опции HT программа "1С:Предприятие" использует не более 50% вычислительных возможностей процессора (только один из двух виртуальных процессоров). Это можно легко увидеть на графике загрузки процессора в "Диспетчере задач". Для серверов с двумя или более базами данных необходимо произвести дополнительные испытания и определить наиболее оптимальный в Вашем случае вариант. Для серверов с двумя физическими процессорами (Intel Xeon) рекомендуется всегда отключать эту опцию при работе с базами данных "1С:Предприятие".

Настройка параметров операционной системы и локальной сети

Драйверы периферийных устройств. Если в вашей организации используются принтеры Canon 810 или Canon 1120 не устанавливайте программу «Монитор» (отображается в правом нижнем углу в виде значка с принтером). Использование данной программы приводит к существенному снижению производительности работы программ "1С:Предприятие".

Антивирусные программы. Для повышения быстродействия работы программы "1С:Предприятие" мы рекомендуем исключать из проверки антивирусными программами файлы следующих типов: *.dbf - файлы данных, *.cdx - индексы, 1cv7.md - файл конфигурации, 1cv7.dd - словарь данных (для DBF версии) или 1cv7.dds - словарь данных (для SQL версии). Файлы этих типов не могут быть заражены вирусами, однако их постояная проверка на вирусы приводит к снижению скорости работы программы.

Межсетевые экраны. Использование межсетевых экранов ("фаэрволов","брандмауэров") необходимо для защиты Вашего компьютера от несанкционированного доступа через локальную сеть. Чаще всего неправильная настройка подобных программ приводит к проблемам с ключами защиты (HASP) для "1С:Предприятие", снижению скорости загрузки и работы в программе. Имеет смысл отключить межсетевые экраны на большинстве рабочих станций в локальной сети, оставив его включенным только на компьютере непосредственно подключенным к интернету.

Неправильное программирование

Один из самых сложных для исправления обычными пользователями класс проблем. Как правило, при неправильном программировании сильно снижается производительнсоть следующих операций в "1С:Предприятие":

подбор по справочнику;
проведение документа;
формирование отчета.

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

Расчет значений в вычиляемых полях формы списка происходит не всегда. Так при движении по горизонтали (вправо-влево, между колонками) по форме списка, программа не перерассчитывает значения. А при перемещении по вертикали (вверх-вниз, между строками) по форме списка, вычисляются только значения в текущей строке, т.е. строке в которой находится курсор. Однако если мы начинаем быстрый подбор по форме списка, то при перемещении на первое найденное значение вычисляются все строки в видимой части формы списка. Эту особенность важно помнить при разработке быстрых форм подбора (форм списка)!

ПРИМЕР: Перемещение на одну строку вверх-вниз в форме подбора в справочнике «Номенклатура» конфигурации «1С: Торговля и Склад» вызывает 23 запроса к базе данных, набор только одной буквы при быстром подборе - 245 запросов при видимой части формы в 12 строк и 47 запросов при видимой части формы в 2 строки!

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

Второй, для программистов:

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

Ограничения сетевой версии

Этот пункт относится прежде всего к сетевым базам данных формата DBF, производительность которых резко падает при увеличении как объема отдельных таблиц (например, справочника «Номенклатура») или при общем росте базы данных. Для комфортной работы с базами данных большего размера рекомендуется использовать клиент серверную (SQL) версию программы "1С:Предприятие" или выделенный терминал сервер.

Переход на клиент серверную версию "1С:Предприятия" позволяет существенно повысить производительность отдельных операций программы (построение отчетов, расчет временных итогов, проведение документов, поиск по справочнику), повысить надежность программы и снять ограничение на допустимый объем базы данных. При многолетней работе в единой базе данных не происходит такого резкого падения производительности как в сетевой DBF версии, поэтому можно отказаться от необходимости периодической свертки старого периода.

Базы данных формата SQL могут обслуживать до 100 пользователей. Некорректный выход из базы данных пользователя не приводит к необходимости переиндексации базы данных. Сервер может выполнять автоматическое резервное копирование базы данных.

Несколько рабочих процессов на одном сервере дают возможность эффективно использовать объем оперативной памяти и ресурсы процессора для выполнения запросов, а также подключить клиентский сеанс к другому рабочему процессу при «крахе» текущего.
За понимание, что запущено на конкретном сервере, отвечает программа «Агент сервера» (ragent). Остановка агента сервера сделает сервер недоступным для использования кластером. Свою информацию агент хранит в файле srvribrg.lst.

Информацией о рабочих базах, задействованных рабочих процессах владеет «Менеджер сервера» (rmngr). Эту информацию он хранит в файле 1CV8Reg.lst. Остановка менеджера сервера может привести к перезапуску клиентских приложений в случаи удачного рестарта менеджера или к полной остановке работы рабочих серверов всего кластера.

1С: Предприятие допускает возможность создания на одном сервере несколько независимых кластеров. Каждый из них идентифицируется в сети уникальным «IP портом» и уникальным номером в служебных файлах. Первый кластер по умолчанию получает порт 1541.

Для управления кластером предназначена оснастка «Серверы предприятия».
Подключаться к серверам можно по имени или IP адресу сервера.

Агент сервера

Агент сервера «знает» о всех кластерах, которые запущены на сервере. Эта информация хранится в файле srvribrg.lst со списком кластеров и администраторов списка. Основной порт агента – 1540. На каждом Рабочем сервере может быть запущен только один агент, обслуживающей все возможные кластера на данном сервере.

Разберемся поподробнее со свойствами кластера

Интервал перезапуска

Данный параметр перезапускает рабочие процессы сервера 1С по заданному значению в секундах. Обычно параметр используется на тех серверах приложений, которые имеют 32х разрядную систему, так как там объем памяти ограничен ~ 3.7 гб., если используется операционная система 64х разрядная, а сервер приложений 32х. Если же ОС использует 32х разрядную архитектуру, тогда общий объем потребления памяти рабочего процесса составляет ~ 1.7 гб. И пользователи часто могут получать сообщение об ошибке вида “Недостаточно памяти на сервере 1С Предприятие”. Самый простой способ избежать данной ошибки, это сделать перезапуск рабочих процессов, к примеру 86400 секунд (1 сутки). При изменении параметра, отсчет времени начинается со старта службы сервера приложений 1С.

Допустимый объем памяти

Перезапуск рабочих процессов по достижению определенного порога занятой памяти рабочим процессом в килобайтах.

Интервал превышения допустимого объема памяти

Означает, если в течении заданного количества секунд произойдет превышение памяти, заданного в параметре “допустимый объем памяти”, тогда сервер 1С примет решение перезапустить рабочий процесс.

Допустимое отклонение количества ошибок сервера

Вычисляется следующим образом. У нас есть серверные вызовы, которые возможно увидеть в технологическом журнале по событию “CALL” а также есть различные исключительные ситуации, которые в технологическом журнале можно увидеть по событию “EXCP”. Платформа вычисляет соотношение данных событий. Предполагается, что данных событий должно быть приблизительно одинаково. Если же в каком-либо рабочем процессе данное соотношение превышает соотношение данных событий в других рабочих процессах на некую значительную величину, то такой рабочий процесс признается проблемным. Как раз данная величина задается в этом параметре. Рекомендуемое значение – 50.

Принудительно завершать проблемные процессы

Если мы включим данный параметр, то по параметру “допустимое отклонение количества ошибок сервера”, проблемные процессы будут завершены. Если параметр выключен, то платформа выводит событие технологического журнала “ATTN”, которое обозначает проблемный процесс.

Выключенные процессы останавливать через

Если сработает один из параметров “интервал перезапуска” или “допустимый объем памяти, то при перезапуске рабочего процесса, он может “отвалиться”. Если клиент во время перезапуска не обращается к серверу (бездействует), то при следующем обращении он плавно переключится на новый рабочий процесс. Если же клиент обращается к серверу в момент перезапуска рабочего процесса, то в данном случае он получит сообщение об ошибке и завершит свою работу. Чтобы этого не произошло, необходимо задать значение данного параметра в секундах. Обычно хватает 120 секунд. За это время рабочий процесс успеет обработать текущие запросы клиентов и перевести их на новый рабочий процесс. Тех активных клиентов, которых процесс не успел обработать, завершается и клиенты возможно могут получить ошибку.

Уровень отказоустойчивости

Данная настройка живет сама по себе не зависимо от количества центральных серверов. Уровень отказоустойчивости может принимать любые значения. К примеру, уровень отказоустойчивости = 1, тогда каждый сеанс пользователя удваивается. Если уровень отказоустойчивости = 2, то каждый сеанс умножается на 3. Также возрастает нагрузка на сервер. При изменении уровня отказоустойчивости, если у нас центральный сервер, он реплицирует на каждый центральный сервер: “реестр кластера”, “сервис блокировок кластера”. Также идет репликация на остальные серверы таких сервисов, как “сервис сеансовых данных”, “сервис оперативной отметки времени”, “сервис блокировок объектов”, “сервис лицензирования”, “сервис нумерации”. Среди них самым тяжелым является “сервис сеансовых данных”.

Режим распределения нагрузки

По производительности. Когда клиентское соединение подключается, оно будет подключено к тому серверу, где присутствует рабочий процесс с более доступной производительностью. Доступная производительность задается в свойствах рабочего процесса:

Доступная производительность на уровне 1С вычисляется следующим образом: ко всем рабочим процессам делается эталонный серверный вызов 1 раз в 10 минут и замеряется время данного вызова. Полученное число делится на 10000 (десять тысяч) и механизмами сервера приложения вычисляется эталонное время. В том случае, если производительность какого-либо рабочего процесса стала на 25 % меньше, чем у остальных, с данного рабочего процесса соединения начинают уходить на остальные рабочие процессы до тех пор, пока все соединения не уйдут.

Приоритет по памяти. Подключения пользователей будут производиться к такому рабочему серверу, у которого больше доступной памяти.

Менеджер кластера

Менеджер кластера отвечает за работу кластера. У каждого кластера свой Менеджер. Менеджер хранит информацию о кластере в файле 1CV8Reg.lst (реестр кластера). У каждого Менеджера кластера также есть свой порт на Рабочем сервере. Для первого кластера по умолчанию порт Менеджера 1541. Именно этот порт отображается в оснастке «Серверы 1С: Предприятия» в ветке «Кластеры», идентифицируя кластер.
Менеджер принимает запросы от клиентской части 1С: Предприятия и принимает решение, какому Рабочему процессу отдать этот запрос на обслуживание.

Для взаимодействия с рабочими процессами Менеджер использует служебный порт.

Рабочий процесс

За «работу с клиентами» отвечает Рабочий процесс. Рабочих процессов в кластере 1С: Предприятия 8 может быть несколько. Количество рабочих процессов не создается вручную, а рассчитывается исходя из описаний требований задач по отказоустойчивости и надежности. Менеджер сервера решает, какой из рабочих процессов будет обслуживать клиентское подключение. Для клиентских подключений Рабочим процессам по умолчанию выделяется диапазон IP портов 1560 – 1591. Кроме этого, каждому Рабочему процессу назначается Служебный порт для обмена с менеджером кластера.

Настройки рабочего сервера, по документации фирмы 1С, можно изменять только в версии КОРП сервера приложений 1С. По факту настройки работают как в версии КОРП, так и в версии ПРОФ. Если данные настройки использовать в версии ПРОФ, это будет являться нарушением лицензионного соглашения.

Максимальный объем памяти рабочих процессов

Данный параметр сам по себе ничего не ограничивает. Он работает в связке с параметром “безопасный расход памяти за один вызов”. Представим, что все наши рабочие процессы суммарно достигли приблизительно расхода по памяти от заданного значения данного параметра. И теперь некий пользователь хочет сделать некий серверный вызов, который хочет потребить большое число памяти. Как только серверный вызов превысит объем заданной памяти в данном параметре на объем памяти параметра “безопасный расход памяти за один вызов”, именно данный пользователь получит ошибку вида: “превышен безопасный расход памяти за один клиент-серверный вызов”. Это нужно для того, чтобы один какой-либо пользователь не смог “завалить” рабочий сервер. Значение параметра 0 равно 80 % памяти, установленной на сервере 1С.

Безопасный расход памяти за один вызов

Значение 0 (по умолчанию) составляет 5 % от значения параметра “максимальный объем памяти рабочих процессов”. Может быть значение -1. Это означает, что любой клиент-серверный вызов, превысивший заданное значение параметра “максимальный объем памяти рабочих процессов”.

Объем памяти рабочих процессов, до которого сервер считается производительным

Означает, если установлено значение и рабочие процессы заняли объем памяти, указанный в данном параметре, сервер будет продолжать работать, но не будет принимать новые подключения до тех пор, пока память не освободится.

Количество ИБ на процесс

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

Количество соединений на процесс

Так же как параметр выше, только зависит от количества соединений на процесс. Значение 0 будет означать, что на каждом рабочем сервере будет только один рабочий процесс.

Менеджер под каждый сервис

У каждого центрального рабочего сервера есть главный менеджер кластера с определенными сервисами:

Они выполняются одной службой “rmngr”. Представим, что данная служба начинает потреблять много памяти или тратить процессорные ресурсы. Обычно есть несколько типичных подозреваемых. Но вдруг вы встали в “тупик” и не можете понять, что именно нагружает службу, вы можете установить галочку “менеджер под каждый сервис”, служба разобьется на 21 процесс (таково количество сервисов в главном менеджере кластера). И соответственно по PID процесса можно будет вычислить, какой сервис нагружает систему.

Центральный сервер

Это сервер, у которого хранится реестр кластера в файле 1СV8Clst.lst. В файле хранится список баз, список администраторов кластера, список требования назначения функциональности, список профилей безопасности, в общем все настройки кластера. Данный файл присутствует только там, где установлена галочка “центральный сервер”. Центральных серверов может быть несколько. Так же на центральных серверах присутствуют такие сервисы, как “сервис блокировки кластера”, “сервис конфигурации кластера”. Пока хотя бы один центральный сервер работоспособен, кластер функционирует. Как только самый последний центральный сервер вышел из строя, кластер становится неработоспособным не зависимо от настроек отказоустойчивости.

Требование назначения функциональности

Кластер серверов 1С Предприятия 8.3 предоставляет некоторый набор функциональных возможностей (называемые объекты требований), распределением которых между рабочими серверами внутри кластера можно управлять. Например, можно указать, что все фоновые задания в кластере будут выполняться на выбранном рабочем сервере. Для того, чтобы поместить соединение или сервис кластера на какой-либо рабочий сервер, необходимо для выбранного рабочего сервера создать требование назначения функциональности. Это требование определяет возможность или невозможность конкретного сервера выполнять ту или иную работу. Рассмотрим более подробно, что собой представляет требование назначения функциональности.

Перенос пользовательских соединений

Допустим мы хотим, чтобы пользовательские соединения работали на рабочем сервере № 1, но если этот сервер выходит из строя, мы хотим, чтобы они переходили на другой рабочий сервер № 2

Для этого нам необходимо на сервере № 1 создать требование назначения функциональности:

На сервере № 2 прописать такие же настройки, но изменить приоритет:

Важность приоритета реализована наоборот. То есть, приоритет 1 выше, чем приоритет 2.

Вывести рабочий сервер из кластера

Вывести рабочий сервер из кластера мы можем и просто, удалив его из списка, но в таком случае всех пользователей “выкинет” из системы. Чтобы более безболезненно осуществить вывод, можно сделать следующее:

Создать требование назначения функциональности со следующими настройками:

Данная настройка означает, что новые подключения к этому рабочему серверу не будут. Те пользователи, которые работали, они продолжат работу, но постепенно перейдут на другие рабочие сервера.

Сервис лицензирования

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

Фоновые задания

С выходом платформы 8.3.7, фоновые задания разделились на 2 группы:

1. Фоновые задания, вызываемые из кода конфигурации

2. Регламентные задания

Поэтому необходимо несколько настроек назначения функциональности:

1. Чтобы фоновые задания выполнялись быстро, необходимо добавить сеансовые данные для фоновых и регламентных заданий

После создания необходимых требований назначения функциональности, необходимо их применить:

Частичное – применение, которое не нарушит работу пользователей

Полное – применение, которое может нарушить работу пользователей.

На практике ни разу не встречалось, чтобы при полном применении нарушало работу пользователей или что-то подобное. Но все возможно, имейте ввиду. После применения, перезапуск службы сервера приложений 1С не обязателен.

Вы всегда можете обратиться к специалистам по оптимизации работы 1С, наш практический опыт сэкономит Ваше время.

Использование System Monitor для диагностики проблем производительности 1С: Предприятия 8

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

System Monitor является основным инструментом для идентификации узких мест в системе. Компоненты анализируемой системы интерпретируются как объекты, параметры которых представляются в виде набора счетчиков, при этом для каждого объекта определен свой набор счетчиков. Некоторые приложения в процессе установки расширяют системный набор своими, специфическими объектами и счетчиками, характеризующими производительность этого приложения. Например, при установке Microsoft SQL Server к стандартному набору объектов и счётчиков операционной системы добавляются специфические объекты и счётчики сервера баз данных.

Потенциальные узкие места, которые могут оказать наибольшее влияние на производительность:

Память

Недостаток объема оперативной памяти, установленной на компьютере, оказывает негативное влияние на производительность всех компонент 1С:Предприятия 8 и Microsoft SQL Server.
При увеличении количества пользователей и объема информационной базы требования к этому ресурсу со стороны сервера 1С:Предприятия 8 и Microsoft SQL Server возрастают.
Нехватка памяти приводит к увеличению интенсивности страничного обмена между файлом подкачки и физической памятью, что существенно снижает производительность системы.

Процессоры

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

Дисковые операции

Производительность дисковой подсистемы является одним из решающих факторов, определяющих производительность Microsoft SQL Server.
На производительность сервера 1С:Предприятия 8 влияния, как правило, не оказывает.

Конфликты блокировок Microsoft SQL Server

Один из основных факторов снижения производительности в многопользовательском режиме
Вероятность возникновения конфликтов блокировок можно снизить за счет доработки прикладного решения

Идентификация узких мест

В таблице приведен перечень основных объектов и счетчиков, используемых при анализе проблем с производительностью.

Объект	Основные счетчики	Описание	Основные признаки наличия проблемы	Варианты решения проблемы
Память	Memory \ Pages/sec	Характеризует интенсивность обмена между дисковой подсистемой и оперативной памятью. Обращение к дисковой системе происходит из-за того, что запрашиваемые страницы отсутствуют в оперативной памяти.	Нормальное значение этого счетчика должно быть близко к нулю. Увеличение показания этого счетчика свыше 20 страниц в секунду говорит о необходимости увеличения объема оперативной памяти.	Увеличение объема оперативной памяти, установленной на компьютере. Перенос приложений, интенсивно использующих оперативную память, на отдельный компьютер. Например, установка сервера 1С:Предприятия 8 и Microsoft SQL Server на разных компьютерах.
Процессор	Processor \ %Processor Time	Время, которое процессор тратит на выполнение полезной работы, в процентах от общего системного времени.	Если среднее значение величины утилизации процессора превышает 85%, значит, процессор – узкое место в системе.	Замена процессоров на более быстродействующие. Увеличение количества процессоров. Перенос приложений, интенсивно использующих процессор на отдельный компьютер. Например, установка сервера 1С:Предприятия 8 и Microsoft SQL Server на разных компьютерах.
Процессор	System \ Processor Queue Length	Длина очереди к процессору.	Если в течение длительного времени средняя длина очереди превышает значение 2, то это говорит о том, что процессор является узким местом.
Дисковая система	Physical Disk \ %Disk Time	Процент времени, которое диск был занят, обслуживая запросы чтения или записи.	Снижение утилизации процессоров сервера	Установка более быстрых дисков. Использование дисков с интерфейсом SCSI. Использование аппаратного RAID - контроллера. Увеличение количества дисков в RAID - массиве.
Дисковая система	Physical Disk \ Avg. Disk Queue Length	Показывает эффективность работы дисковой подсистемы. Представляет собой среднюю длину очереди запросов к диску.	Увеличение очереди запросов к дисковой подсистеме
Сетевой интерфейс	Network Interface \ Bytes Total/sec	Скорость, с которой происходит получение или посылка байт через сетевой интерфейс	Значение этого счётчика не должно превышать 65% величины пропускной способности сетевого адаптера.	Установка сетевого адаптера с более высокой пропускной способностью (если позволяют параметры сети). Установка дополнительного сетевого адаптера.
Блокировки	SQL Server: Locks \ Lock Wait Time (ms)	Показывает общее время ожидания (в миллисекундах) выполнения запросов на блокировку за последнюю секунду	Среднее значение общего времени ожидания не должно превышать заданного времени отклика системы умноженного на количество активных пользователей	Сокращение времени выполнения транзакции. Обеспечение единого порядка доступа ко всем ресурсам. Оптимизация запросов в прикладном решении. Правильная установка признаков индексирования у реквизитов объектов конфигурации позволяет существенно сократить диапазон блокировок. Поддержание актуальности индексов и статистики Microsoft SQL Server. Использование в запросах оператора "ДЛЯ ИЗМЕНЕНИЯ".
Блокировки	SQL Server: Locks \ Average Wait Time (ms)	Показывает среднее время ожидания (в миллисекундах) выполнения каждого запроса на блокировку	Не должно превышать заданного времени отклика системы
Взаимные блокировки	SQL Server: Locks \ Number of Deadlocks/sec	Показывает количество запросов на блокировку в секунду, которые закончились взаимной блокировкой	Ненулевое значение счетчика

Основные показатели низкой производительности

1. Производительность системы не удовлетворяет требованиям бизнес-логики автоматизируемого предприятия на значительной части операций;

2. Большая часть пользователей системы жалуется на:

2.2 Неприемлемую общую производительность системы;

2.3 Неприемлемую производительность на отдельных операциях;

2.4 Внезапное ухудшение производительности;

2.5 Частое возникновение ошибок:

2.6.1 «Lock request time out period exceeded »;

2.6.2 «Превышено максимальное время ожидания предоставления блокировки»;

2.6.3 «Transaction was deadlocked on lock resources with another process and has been chosen as deadlock victim »;

2.6.4«Конфликт блокировок при выполнении транзакции»

Если производительность системы признается неудовлетворительной, то необходимо провести анализ загруженности оборудования, в соответствии с данными рекомендациями:

Выполнить ряд замеров со следующими счетчиками производительности:

Память – обмен страниц \ сек

Процессор - % загруженности процессора

Система – длина очереди процессора

Физический диск – средняя дли очереди диска

Сеть – обмен байт\сек (исключено, так как все на одном сервере и сетевая активность минимальная)

Анализ данных замера

Анализ данных следует проводить на основании среднего и максимального значения для каждого счетчика на выбранном интервале времени.

Эти значения отображаются в нижней части основного окна «Системного монитора».

Ниже в таблице приведены описания счетчиков «Системного монитора» и предельные значения для каждого из них.

При превышении этих значений следует рассмотреть вопрос об увеличении производительности соответствующей аппаратной компоненты.

Группа	Счетчик	Описание	Критерий	Узкое место
	обмен страниц \ сек	Интенсивность обмена между дисковой подсистемой и оперативной памятью	Среднее: около 0 Максимальное: не более 20	Недостаточно оперативной памяти
Процессоры	% загруженности процессора	Загруженность процессоров	Не более 70% в течение длительного времени
	длина очереди процессора	Очередь к процессорам	Не более 2 * количество ядер процессоров в течение длительного времени	Недостаточная производительность процессоров
Физический диск	средняя дли очереди диска	Очередь к дискам	Не более 2 * количество дисков, работающих параллельно	Недостаточная производительность дисковой подсистемы
Сетевой интерфейс	обмен байт\сек	Скорость передачи данных через сеть	Не более 65% от пропускной способности сетевого адаптера	Недостаточная пропускная способность сетевого интерфейса

С 14 версии в битрикс появились SEO настройки, которые помогают SEO оптимизировать 1С Битрикс под свои задачи. Одним из ключевых моментов этой оптимизации является возможность делать автоматизированные шаблоны, в которых можем задавать мета-теги: H1 , title , description , ключевые слова и ключевые слова у картинок такие как title и название самой картинки alt .

Как вы догадались, в данном уроке пойдет речь о SEO настройках 1С битрикс и рассмотрим принципы работы данного функционала.

SEO поля имеют свойства наследования, их можно задавать начиная с инфоблоков, далее разделов, и заканчивая каждым элементом, который можно сформировать под конечный запрос.

Можно разделить формирование SEO полей на три этапа:

Настройка SEO полей инфоблока;
Настройка SEO полей разделов и элементов;
Настройка комплексного компонента.

Определение:

SEO настройки – набор правил, определяющие, шаблоны вывода мета данных для оптимизация сайта по SEO параметры поисковых машин.

Оптимизация SEO полей инфоблока

Давайте на примере нашего каталога товаров, проведем SEO оптимизацию инфоблоков в битрикс. Перейдем в административную часть сайта, Инфоблоки, выберем каталог товаров, открываем вкладку SEO и по порядку проводим настройки полей.

Первая секция настроек предназначена для шаблонов мета-тегов title , description , keywords , а также заголовки страницы H1 . С помощью данной кнопки […] , которая расположена рядом с каждым полем мы можем формировать необходимые нам шаблоны для СЕО оптимизации сайта на битрикс.

Сформируем шаблон META TITLE , в поле пропишем:

Каталог {=this.Name} от интернет-магазина dws.mcdir.ru.

Добавляя в конец название, или домен нашего магазина мы тем самым уникализируем TITLE . Чуть ниже отобразилось наше полное название TITLE , и обратите внимание, что подставляемое поле «Имя раздела» выводится с заглавной буквой. Можно оставить как есть, но желательно что бы предложение было сформировано правильно. Воспользуемся другим оператором {=lower arg1 ... argN} который приведет название раздела к нижнему регистру.

Прописываем и название сразу изменилось, так же этот фильтр-обработчика доступен при нажатии следующей кнопки […] , где далее выбираем Поля раздела, Название текущего раздела в нижнем регистре.

Перечень операторов в битрикс:

{=lower arg1 ... argN} - приведение к нижнему регистру;
{=upper arg1 ... argN} - приведение к верхнему регистру;
{=concat arg1 ... argN ", "} - сцепление строк через разделитель;
{=limit arg1 ... argN "" NN} - ограничение NN элементов по разделителю;
{=translit arg1 ... argN} - транслитерация выбранных аргументов;
{=min arg1 ... argN} - выборка минимального числового значения;
{=max arg1 ... argN} - выборка максимального числового значения;
{=distinct arg1 ... argN} - уникальные (без дублей) значения.

Для оптимизации шаблона META KEYWORDS просто пропишем перечисление ключевых слов с нашим заголовком раздела в нижнем регистре. Первым по приоритетный выводим название раздела в нижнем регистре, далее разбавляем наши заголовки словами (заказать, купить, приобрести в своем городе, и т.д.)

Пример seo оптимизации META KEYWORDS :
{=lower this.Name} , заказать {=lower this.Name} , купить {=lower this.Name}, приобрести в Краснодаре {=lower this.Name} , {=lower this.Name} от дистрибьютора

Внизу видим, как даны ключевые слова сформировались. Далее настроим краткое описание для мета-данных DESCRIPTION разделов каталога.

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

Пример seo оптимизации DESCRIPTION :
Интернет магазин dws.mcdir.ru, в разделе {=lower this.Name} представлен огромным выбор одежды на любой вкус. Наш магазин находится в Краснодаре и мы являемся официальным дистрибьютором в России.

Внизу отобразился готовый результат шаблона DESCRIPTION , теперь сформируем Заголовок раздела, он же будет выводиться в H1 .

Переходим к следующей секции "Настройка для элементов". Оптимизируем по аналогии как работали с разделами за исключением шаблона DESCRIPTION куда выведем производителя товара с закрепленного свойства элемента.

По аналогии заполняем, мета данные для свойств самих картинок, таких как ALT и TITLE . Если до этого раннее картинки были загружены на сайт то данные к ним не применяться, они останутся как прежние, а срабатывание этого функция будет в том случае, когда картинка будет обновлена или при создании нового элемента, когда будете загружать файл.

Чуть ниже в битрикс находится секция «Управление», с помощью отмеченной вкладки "Очистить кеш вычисленных значений", сможете сразу видеть отображения всех внесенных изменений, кеш будет обновляться и результат будет сразу отображаться.

После проведенных нами настроек обязательно сохраним инфоблок.

SEO настройки разделов и элементов

С оптимизацией инфоблока в битрикс разобрались, теперь перейдем в каталог одежды и при необходимости настроим разделы, которые не соответствуют нашему описанию. К примеру, мы в описании DESCRIPTION писали, что у нас в интернет магазине «…. огромным выбор одежды на любой вкус…» , это описание не соответствует некоторым разделам как «Обувь», «Аксессуары» и текущие разделы подкорректируем под свое описание.

Выбираем, изменить раздел «Обуви», открываем вкладку «SEO », и проверяем текущие описания разделов. Если данная вкладка не отображается, проведите настройки текущей формы, как это сделать я объяснял в уроке "Формы редактирования". В описании DESCRIPTION видно явное несоответствие разделу «… раздел обувь с огромным выбором ОДЕЖДЫ на любой вкус …» . Давайте в данном случае напишем не Обувь, а Продукция.

Для этого можно отмечаем «Изменить для этого раздела и его подразделов», поле стало активным для редактирования. Теперь внесем свои правки и в дальнейшем если сейчас сохранимся, то все подразделы текущего раздела унаследуют данное свойство.

Всегда начинайте правки SEO полей с основного раздела.

Спустимся ниже и проверим описание для элементов. Проверим формирование описание подразделов, и далее проводим соответствующие правки в разделе Аксессуары.

Добавление нового элемента в битрикс

Давайте для примера добавим новый элемент в данный раздел. Жмем кнопку Создать товар, заполняем основные поля. Переходим на вкладку SEO , а тут видим, что не отображаются в готовом варианте наши заголовки, хотя по умолчанию свойства везде проставлены. Даже если по умолчанию проставим новое свойство, результат система нам не покажет.

Для того что бы битрикс отобразил полные мета-данные, элемент нужно сохранить и желательно сделать это таким образом что бы другие пользователи не видели отображение этого элемент и в тоже время мы могли его видеть из под своей учетной записи Администратора.

Нам нужно настроить права доступа к текущему элементу, для этого, переходим на вкладку доступ и устанавливаем права для групп «Все пользователи» и «Все авторизованные пользователи» Нет доступа. Как вывести вкладку «Доступ» и настроить ее поля я показывал в уроке Настройка прав доступа .

После того как закончили с настройками формы в битрикс, переходим на вкладку SEO и жмем кнопку Применить. У нас сформировался полные заголовки при этом сам элемент Активный, но все пользователи кроме группы администраторов его на сайте не видят. Это поверьте очень удобно, дает возможность администратору полностью проверить элемент до конечной его публикации.

Включаем SEO в компоненте

После оптимизации, инфоблока, разделов и элементов в битрикс перейдем в каталог на визуальную часть сайта и посмотрим отображение наших заполненных форм шаблонами мето-данных. Если у нас не отображается в компоненте заголовок элемента или раздела и на всех страничка он не изменяем, это говорит о том, что в компоненте, в Дополнительных настройках, не установлен параметр «Устанавливать заголовок страницы».

Перейдем в настройки компонента и активируем данный параметр.

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

У нас сразу изменился заголовок страницы. Открыв страницу в режиме кода, мы видим корректное отображение SEO данных битрикс.

Как видите, с помощью оптимизации SEO параметров в 1С битрикс, можно гибко настроить сайт под поисковые запросы, а простота настройки механизма понятна даже ребенку.

Пользуйтесь данным параметров SEO настроек в битрикс для оптимизации и развивайте своего сайта.