Оптимизация без оптимизации: как мы ускорили 1С в 10 раз без трудоемкой оптимизации запросов и алгоритмов. Практический опыт

Сегодня я хочу поговорить об оптимизации 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.