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

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

Я расскажу о нашем опыте, как мы у себя оптимизировали 1С на тех участках, где она «тупила» и «тормозила», и как мы сделали это без оптимизации запросов, алгоритмов и т.д.

Оптимизация «по учебнику»

Напомню классический подход к оптимизации .

Допустим, у нас «тупит» и «тормозит» 1С. Мы это видим по системам мониторинга, либо нам говорят об этом пользователи. Что мы, как специалисты 1С, должны делать «по учебнику»?

• Мы находим узкие места , где «болит» больше всего - например, система начинает «висеть», когда идет массовый расчет себестоимости, или начисление зарплаты, или массовый ввод реализации, как это было у нас.
• Когда найдены узкие места, мы должны посмотреть, что можно оптимизировать, чтобы ускорить работу системы.
  • Возможно, нужно оптимизировать запросы , чтобы они захватывали меньше данных,
  • Или переписать алгоритмы с транзакциями , чтобы они чаще отдавали данные, либо обрабатывали более короткий промежуток времени.
  • Если это не помогает, мы пробуем нарастить серверное оборудование.

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

Мы у себя в компании столкнулись с тем, что 1С в некоторые моменты времени «зависала» и «тормозила». Руководство потребовало решить эту проблему, но:

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

Несколько слов о компании

Пару слов о нашей компании.

Компания «Ароса» - мы поставляем продукты питания в HoReCa, (в кафе, бары, рестораны), в государственные учреждения, в ритейл. Работаем в Москве, Питере, Сочи.

Отгружаем:

• Порядка 100 тонн товаров в сутки, сейчас даже больше.
• В день обрабатываем порядка 800 и более заказов - суммарно во всех заказах примерно 4000 строк.
• В основном это штучная отгрузка.

Я в нашей компании отвечаю за автоматизацию складов, т. е. непосредственно за нашу WMS-систему.

Основная учетная система у нас - это «Управление торговлей». А на складе мы используем WMS «Кортес». В мире 1С в качестве WMS-системы наибольшее распространение получило решение от компании Axelot, но кроме него есть и другие WMS-решения на 1С, одно из них используем и мы.

Кейс 1. Обработка заказов

Первое узкое место, про которое я расскажу - это процесс обработки заказов на складе.

У нас процессы на складе выстроены следующим образом:

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

И каждый день в 18:00-19:00 при достижении определенных значений количества заказов в сутки мы стали сталкиваться с «зависаниями» системы - в те один-два часа, когда шла основная обработка заказов операторами, работать в системе было практически невозможно.

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

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

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

Операторы вынуждены были играть в игру «Я зарезервирую этот рейс с пятой попытки», потому что реализовано все это было не идеально. Когда оператор нажимал кнопку «Зарезервировать товар по рейсу», у него появлялись песочные часы - система начинала обрабатывать первый, второй, третий заказ, и, допустим, на четвертом заказе возникало ожидание на блокировке - пользователю выдавалась ошибка, что произошел таймаут. Попытка номер два, пробуем еще раз и т.д.

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

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

• Первый пик - это 17:00-19:00 часов, когда операторы обрабатывают первую порцию заказов.
• И второй пик ночью, когда они массово начинают обрабатывать вторую порцию заказов.

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

Как это выглядит технически?

• Когда оператор нажимает кнопку «Зарезервировать рейс», его сеанс никакого резервирования не выполняет - просто делается запись в служебный регистр сведений, что по этому рейсу необходимо сделать резервы.
• Стартует фоновое задание, которое начинает выполнять все необходимые действия.
• Когда другой оператор параллельно в это же время делает те же действия по своим рейсам, его рейс также встает в очередь.
• И потом, когда фоновое задание закончит работу с первым рейсом, оно переходит к обработке второго рейса. Когда закончит второй, перейдет к третьему, если он есть в регистре. Если третьего нет, то оно завершается.

Таким образом, заказы перестали обрабатываться параллельно.

На скриншоте показано, как все это выглядит интерфейсно в используемом у нас решении «Кортес» на толстых формах. Сейчас все это происходит примерно следующим образом:

• Когда пользователь нажимает кнопку «Зарезервировать товар», у него напротив определенного рейса появляется значок часиков. Это означает, что данный рейс отправлен в работу.
• При этом интерфейс у пользователя не «замерзает», он может дальше строить какие-то отчеты, отправить в работу еще какой-то рейс, но его сеанс больше не занимается этой работой.
• Когда рейс будет отработан, эти часики уйдут.

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

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

• Ожидания в пиковые периоды практически ушли;
• Нервозность склада снизилась;
• Скорость обработки рейсов существенно выросла;
• И что самое важное для нас и бизнеса - все это было сделано просто и быстро.

Кейс 2. Отгрузка рейсов

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

С точки зрения 1С в это время по каждому рейсу запускалось массовое перепроведение заказов , потому что надо сделать соответствующие движения по документам, списать этот товар по регистру остатков с ячеек отгрузки, сделать какие-то движения по резервам и т.д. И из-за того, что несколько кладовщиков делали это одновременно, опять происходило ожидание.

Возможно, у нас все было плохо в запросах, и их нужно было оптимизировать, но сильно вникать в это нам не хотелось, может быть, потому, что мы ленивые.

В итоге мы реализовали отложенное проведение.

• С точки зрения бизнес-логики для нас было не принципиально, чтобы в 7:00-8:00 утра, когда идет погрузка машин, товар был правильно списан по регистрам. Для нас было главное, чтобы у документов был статус «Отгружен», и пользователи в своих формах видели, что они такие-то документы обработали. Поэтому, когда кладовщики отгружают рейсы, документы заказов не перепроводятся, у них просто меняется реквизит статуса на «Отгружен».
• При этом делается запись в регистр сведений «Документы к проведению» , что такие-то рейсы, такие-то заказы надо потом допровести.
• И потом, спустя несколько часов, когда нагрузки на систему нет, стартует фоновое задание, которое пробегает этот регистр, смотрит эти рейсы, эти заказы, которые надо обработать, и допроводит их.

По сути, мы реализовали отложенное проведение. Ничего нового здесь нет, эта идея уже много лет работает и в УТ 10-ой редакции, и в УПП.

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

Кейс 3. Создание и проведение реализаций

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

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

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

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

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

• В УТ продажник оформляет документ «Заказ», с помощью подбора подбирает свободные остатки, и проводит документ.
• При проведении заказа система проверяет, хватает ли свободных остатков, нет ли долгов по дебиторке, все ли условия по оплате выполнены. И, если все хорошо, заказ проводится. Если заказ проведен, то значит, товара клиенту хватит.
• Далее продажник переводит в статус «К отгрузке», вводит на его основании:
  • реализацию;
  • счет-фактуру;
  • наш служебный документ «Распоряжение на склад», который с помощью обменов потом летит к нам в WMS.

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

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

Мы посмотрели на эту проблему и решили сделать так, чтобы реализации создавались и проводились в отдельном потоке фоновым заданием .

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

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

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

Результат в данном случае тоже был похожий:

• Мы решили проблему ожидания на блокировках.
• Пропускная способность УТ в этот период увеличилась.
• Пользователи сменили «гнев на милость».

Главное, что с того момента, как у них все «накипело», и они по управленческой структуре дошли до верха, сказали нам: «Сделайте что-нибудь, вы же 1С-ники, вы же программисты», прошло достаточно мало времени до того, как мы поняли, в чем проблема, и решили ее - проверили, протестировали.

Итоги

Подведу небольшой итог.

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

• Возможно, вы сможете перенести эти операции на другое время , чтобы они выполнялись, когда система не будет сильно нагружена;
• Может вам удастся организовать для этих операций один поток, чтобы исключить причину блокировок .
• Конечно, купить железо за 1000 долларов - это более правильно, но нам надо получить результат быстрее и с максимальным эффектом. Если логика при этом не пострадает, то почему бы и нет.

*******************

Данная статья написана по итогам доклада (), прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.

Приглашаем вас на новую конференцию .

Одной из распространенных задач, которую приходится решать администраторам и программистам, является проблема низкой производительности баз данных "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").

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

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

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

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

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

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

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

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

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

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

А между тем бывают следующие ситуации:

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

2. В системе имеются четко локализованные проблемы производительности, которые не воспроизводятся на тестовой базе в однопользовательском режиме. Например, пользователи жалуются на недостаточную производительность документа «РеализацияТоваровУслуг», но при проведении этого документа в нерабочее время и/или на тестовой базе производительность оказывается в норме.

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

4. Система запускается в рабочую эксплуатацию после существенного изменения условий работы системы:

изменилась конфигурация;

изменилась используемая версия 1С:Предприятия;

изменилась используемая СУБД;

изменилась конфигурация оборудования;

и т.п.

5. На начальном этапе эксплуатации системы ее производительность была признана удовлетворительной, но по мере наполнения информационной базы производительность стала падать.

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

7. Система стабильно работает с удовлетворительной производительностью. Необходимо гарантировать своевременную и точную диагностику проблем производительности в случае их возникновения.

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

Источники проблем :

«Неудовлетворительное» железо
в момент наблюдаемых проблем серверное оборудование сильно загружено

Отсутствие регламентных процедур для СУБД
Не выполняется обновление индексов и статистики

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

Хорошо известно, что каждый ИТ-сервис имеет свою специфику, а сочетание, например, таких сервисов, как 1С:Предприятие 8 и база данных SQL расположенных внутри именно вашей ИТ-инфраструктуры дает инвариантность конфигураций.
Мы накопили практический опыт решения такого рода сложных задач с помощью:

Команда

Команды квалифицированных технических специалистов с различной специализацией. В каждом проекте по оптимизации 1С:Предприятия участвуют системные инженеры уровня «Эксперт», ИТ-архитектор и 1С-программист.

Платформа

Собственной облачной ИТ-инфраструктуры (IaaS). Мы разворачиваем стенд — копию вашей базы 1С, оптимизируем и тестируем ее с различными версиями платформы 1С, чтобы найти оптимальное сочетание по производительности.

Компетенция

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

Из чего состоит процесс по увеличению производительности 1С?

Аудит 1С системы

Чтобы не ориентироваться на ощущения пользователей по скорости работы 1С:Предприятия, аудит производительности мы начинаем с тестирования. Это дает объективный критерий, с которым сравнивается конечный результат работы. Тестирование проводится интегральное, т.е. замеряется общая производительность всей системы в целом — версия 1С:Предприятие, 1С-конфигурация, база данных и ИТ-инфраструктура.

Оптимизация

На этом этапе производится тщательное компонентное тестирование различных элементов системы и их последующая оптимизация.

Основные проблемы с производительностью 1С вызывают следующие элементы:

• Бизнес-процессы. Пользователи некорректно работают в 1С;
• Оборудование и сеть. Высокая загрузка серверного оборудования и сети;
• Системы управления базами данных. Не выполняется регулярная профилактика, обновление статистики и индексов БД;
• Неоптимизированный код измененной конфигурации. 1С программист сделал изменения, которые загрузили систему лишними операциями.

Именно по этим направлениям и ведется работа при комплексной оптимизации.

Итоговое тестирование и сравнение результатов

По окончанию работ проводится финальное интегральное тестирование быстродействия работы 1С:Предприятия 8. Если достигнуто увеличение производительности на десятки процентов, то результат признается годным. В противном случае — продолжаются работы из второго этапа.

Какие параметры мы проверяем и настраиваем при оптимизации 1С?

Что является результатом работ?

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

Отправить эту статью на мою почту

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

Основные жалобы, отмечаемые пользователями:

Стали медленно проводиться документы

Отчеты слишком долго формируются

Программа чаще зависает

Знакомые жалобы, не так ли?

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

Устаревшее оборудование

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

Для этого необходимо проверить требования к железу, предъявляемые 1С 8.3

Это можно сделать на официальном сайте http://1c.ru/rus/products/1c/predpr/compat/hard/demand.htm

Неактуальная платформа

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

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

Увеличить работоспособность возможно редактированием настроек серверов SQL и 1С:Предприятие.

Для этого в BIOS выключаем все опции по экономии питания процессора и устанавливаем производительность на максимум. Это удобно делать, например, через утилиту PowerSchemeEd.

Сервисы, которые редко используются, желательно отключить. К таким службам можно отнести FullText Search и Integration Services

Не забываем установить на максимум количество памяти, которое отведено серверу. Это требуется, чтобы SQL-сервер заранее успевал отчистить память, контролируя заполнение.

Как вариант, возможно переключить службу 1С в режим отладки. Благодаря этому дополнительно увеличивается оптимизация 1С.

Большая база данных

По мере работы любая база со временем увеличивается в объеме. Поэтому не стоит забывать про регулярное профилактическое обслуживание системы. Это удобно сделать стандартным средством "Тестирование и исправление информационной базы".

Данный инструмент поможет оптимизировать БД путем реструктуризации и реиндексации. Чтобы воспользоваться обработкой требуется в режиме конфигуратора. Обработка выглядит следующим образом:

Некорректная настройка фоновых и регламентных заданий

Дефрагментация индексов и обновление статистики желательно проводить в ежедневном режиме, потому что при понижении фрагментированности индексов значительно снижается оптимизация 1С.

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

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

Некорректное взаимодействие с другим ПО

Помимо этого проблема быстродействия 1С:Предприятия может быть связана с другим предустановленным программным обеспечением.

Чаще всего это антивирусы с неправильными настройками. Соответственно для обеспечения корректной работы 1С требуется проверить настройки используемого антивируса. Например, для «Касперский» настройки указаны на официальном сайте https://support.kaspersky.ru/general/compatibility/11683

Нестабильный канал связи

Чаще всего эта проблема актуально при работе в 1С через WEB-интерфейс или удаленный рабочий стол. Если в компании используется удаленный доступ, то обязательно надо проверить работоспособность канала связи.

Ускорение 1С в пользовательском режиме

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

На вкладке «Поддержка и обслуживание» (Раздел «Администрирование») доступен широкий перечень функций, увеличивающих ускорение 1С:

Отключение автоматического запуска неиспользуемых регламентных заданий;

Выключение полнотекстового поиска;

Свертка БД за предыдущий период;

Удаление помеченных объектов;

Оптимизация 1С

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

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