Нашел в своих архивах статью 4х летней давности. Писалась для CNews, но там ее "причесали", а хотелось бы опубликовать именно в таком "1с-нативном" виде.
_______________________________
Производительность систем автоматизации учета критична для предприятий массового обслуживания потребителей и для сфер бизнеса, которым характерно быстрое принятие решений на основе анализа оперативных данных.
Традиционно факторы, влияющие на увеличение быстродействия информационных систем, специалисты, занимающиеся этой проблематикой, делят на три обособленные группы - оборудование, СУБД и код приложения.
Как правило, вопрос выбора оборудования решается на более ранней стадии автоматизации, и оно не всегда «заточено» под будущую платформу, роли серверов максимально фрагментированы и разнесены, и любая новая закупка более мощного сервера ставит нелегкий вопрос "а куда девать старый?" Особенно трагично выглядит лицо айтишника, наблюдающего индикаторы утилизации CPU и HDD на уровне 10% от номинала после удачно проведенной комбинации по "отжиманию" немалых инвестиций у руководства. Возможности по прокачке СУБД за счет оптимизации индексов, регулирования параллелизма и отключения журнала транзакций также быстро заканчиваются. После этого вдруг с тоской вспоминается эпоха 1С:7.7, когда все "летало" на более слабом железе и закрадывается предательская мысль: а так ли хороша восьмая платформа 1С?
Оптимизация кода с точки зрения нетривиальности решений становится наиболее интересным и перспективным направлением приложения творчества IT-персонала.
Попробую развеять эти упаднические настроения и поделиться опытом по увеличению быстродействия за счет возможностей, предоставляемых платформой 8.2.
Во-первых, надо четко понимать, за счет каких бизнес-процессов происходит торможение системы:
- либо большое количество пользователей с однотипными ролями постоянно конкурируют за одинаковые ресурсы, банально мешая друг другу, теряя время на ожидании снятия блокировки таблицы, например с остатками товаров;
- либо требуется периодическая (чаще ежемесячная) обработка очень объемной первичной информации, например расчет себестоимости товара, реализованного через сеть розничных точек;
- либо сложная комбинация первого и второго, когда в одной базе сидят фронт и бэк офисы, бухгалтеру надо перепроводить и закрывать прошлые месяца, а менеджерам надо проводить сегодняшние документы.
Далее нам нужно классифицировать пользователей по информационным ресурсам, в которых они нуждаются и по степени свежести (оперативности) этих ресурсов:
- Менеджерам по продажам нужны оперативные остатки продаваемых ими товаров, сроки поставок отсутствующих товаров и взаиморасчеты с покупателями, причем платежи они должны видеть сразу после разнесения бухгалтером банковских выписок.
- Бухгалтерам важно успеть к определенным датам рассчитать и перечислить налоги, сдать регламентированную отчетность, в реальном масштабе времени они отслеживают только банк и кассу.
- Расчетчику надо успеть до 5 числа рассчитать зарплату и подать руководству на подпись платежную ведомость, а в бухгалтерию передать информацию по затратам и налогам.
Как видим, по времени и ресурсам бухгалтеры и менеджеры пересекаются только в финансовом учете. Всю остальную деятельность можно спокойно разнести по разным базам и серверам, а обмен между базами проводить в нерабочее время. Таким образом, мы за счет грамотного проектирования архитектуры информационных баз, распределяем нагрузку на оборудование и зарабатываем еще несколько очков!
После апгрейда оборудования и декомпозиции информационной системы могут остаться однотипные пользователи фронт-офиса, для которых время отклика системы имеет решающую роль с точки зрения успешности бизнеса. Справедливости ради, надо еще упомянуть бухгалтеров, которые получают сомнительное удовольствие от ночных посиделок в ожидании завершения процедуры закрытия месяца. Задачи по ускорению работы системы в таких случаях лежат в плоскости оптимизации кода, и порой даже 20% выигрыша во времени могут дать такой же прирост в выручке, или, как минимум, сохранить семью бухгалтера :)
Под оптимизацией 1С-кода я понимаю несколько технологических приемов:
- механизм управляемых блокировок: он позволяет увеличить параллельность проведения документов за счет того, что при операции типа "запись" блокируется не вся таблица, а только указанный диапазон строк. Это позволяет одномоментно проводить два документа "Реализация Товаров и Услуг", если в них нет одинаковых товаров, либо эти товары отгружаются с разных складов. Причем механизм управляемых блокировок работает независимо от СУБД (будь то MS SQL или Postrge SQL), т.к. срабатывает на уровне 1С-сервера приложений. В режим управляемых блокировок программистами 1С переведены почти во все типовые конфигурации.
- реализация концепции "тонкий клиент": в платформе 8.1 можно было переносить выполнение некоторых наиболее трудоемких участков кода на процессор 1С-сервера. В платформе 8.2 эта концепция получила еще более глубокое развитие за счет управляемых форм и использования "четырехзвенной" архитектуры - СУБД+Сервер приложений+web-сервер+клиент. Таким образом, скорость реакции системы перестает зависеть от способностей "железа" компьютеров конечных пользователей. Концепция "тонкий клиент" в той или иной мере реализована во всех типовых конфигурациях 1С.
- удаление/откладывание "лишних" регистров при проведении документов: "лишний" функционал в типовой конфигурации появляется из-за того, что конфигурация является максимально универсальным тиражным продуктом. За универсальность приходится расплачиваться быстродействием, т.к. не весь заложенный функционал может быть востребован данным конкретным бизнесом. Или функционал может быть востребован редко, в таких случаях движение некоторых регистров можно перенести «на потом», выполнять в фоновом режиме, или вообще отключить.
- Отключение таблицы итогов: при проведении/перепроведении большого массива многострочных документов можно временно блокировать механизм пересчета итогов регистров сведений и регистров бухгалтерского учета с помощью команды УстановитьИспользованиеИтогов. Операция рискованная с точки зрения временного искажения данных об остатках регистров, но она того стоит. Важно после завершения не забыть вернуть режим обратно и пересчитать итоги, начиная с самого раннего проведенного документа
- РАУЗ: В типовых конфигурациях «1С:Управление производственным предприятием» и «1С:Комплексная конфигурация» программистами 1с внедрен замечательный механизм – РАУЗ (Расширенная аналитика учета затрат). Этот механизм позволяет рассчитывать месячную себестоимость не заботясь о хронологической последовательности приходных и расходных документов внутри месяца, соответственно не надо перепроводить документы для перерасчета сумм в партионных регистрах. Себестоимость рассчитывается методом линейных уравнений. Те клиенты, кто согласились перейти с партионного учета на РАУЗ выиграли несколько дней жизни ежемесячно!
- минимизация влияния невостребованного функционала: существуют сервисные фоновые задачи, которыми пользуются редко или никогда, например, пересчет индексов полнотекстового поиска. Его отключение дает существенный выигрыш при проведении "тяжелых" документов, таких как "закрытие месяца".
- оптимизация запросов: задача выборки нужной информации из базы данных может быть решена множеством способов, но среди этих способов всегда существует несколько наиболее оптимальных по времени выполнения. Наличие вариативности решений делает процесс оптимизации запросов почти творческим, подчас требующим озарения. Вот лишь небольшой перечень рекомендаций, которыми стоит вооружиться программисту:
- максимально использовать фильтры в параметрах виртуальных таблиц, а не в условиях ГДЕ,
- не использовать запросы в цикле,
- по возможности использовать временные таблицы, и не забывать про индексацию полей-коннекторов
- получить сертификат 1С:Эксперт по технологическим вопросам: это не совсем технологический прием, скорее правильный профессиональный путь внедренца, рассчитывающего получить место в серьезном проекте.
В комплексе все эти мероприятия дают очень яркий, хорошо ощутимый эффект, в некоторых случаях выигрыш в скорости измеряется десятками раз. Медленная информационная система, как правило, вызывает раздражение конечных пользователей, но когда система работает нормально, ее не замечают. При этом сотрудникам удается выполнить больший объем работы, и остается время для анализа и планирования.
Выводы: вопросы производительности информационных систем по важности стоят в одном ряду с такими важными вопросами как функциональные возможности конфигурации и дружественность интерфейса (usability). Отечественная платформа 1С по своим возможностям (прозрачности, функциональности, масштабируемости, стоимости) уже давно достойно конкурирует с серьезными зарубежными решениями от SAP, Oracle, Microsoft.
