|
|||||||||||||
ВступлениеПубликация предназначена в первую очередь для программистов, ведущих разработку ПО в крупных информационных системах с массивным потоком обрабатываемой информации и большим количеством пользователей. Я изучаю вопросы оптимизации более 15 лет, за это время участвовал и руководил проектами оптимизации информационных систем на базе различных конфигураций 1С практически во всех областях учета. На мой взгляд, первопричина зависаний и плохой работы программы 1С - некачественный программный код модулей конфигурации этой самой 1С. Если у вас проблемы с производительностью системы, вы можете устанавливать супер современное оборудование, тратить месяцы на обучение продвинутых пользователей, пробовать любые тонкие настройки ИТ-техники - без оптимизации программного кода, рано или поздно, вы сталкнетесь с теми же проблемами производительности, а зачастую с более серьезными. Поэтому данная статья посвящена исключительно программной оптимизации. Рекомендую на этапе разработки использовать тестовую копию рабочей базы с тем же режимом работы (файл/сервер). Для приближения условий тестирования в тестовой базе к реальным условиям работы, в предлагаемой методике реализована возможность запуска нагрузочных сессий для имитации рабочего режима. Во-первых, давайте определимся, что же такое качественный код. Предлагаю очень простое и понятное определение правильного программного кода: "Нечего добавить и нечего убрать" Т.е. если при взгляде на код модуля вы понимаете, что ни один логический блок нельзя убрать или заменить более оптимальной структурой, не испортив требуемого функционала - будем считать, что это лучшая реализация из возможных, код качественный и работа по его улучшению завершена. Во-вторых, при оценке программного кода необходимо руководствоваться здравым смыслом и не рассматривать его исключительно через призму рекомендаций 1С. В крупных информационных системах действуют свои законы и правила работы с данными. Очень часто, следуя рекомендациям 1С, мы достигаем противоположного эффекта. Для примера - использование временных таблиц. Из личного опыта: в 90% случаев причина зависаний и отказов 1С в клиент-серверном режиме - бездумное и необоснованное использование команды "Поместить" при построении запросов к базе данных. В рамках этой публикации хочу остановиться на одном из самых узких мест с точки зрения производительности - обработке записи/проведения документов. Ниже представлена многократно проверенная методика оптимизации модулей проведения. Описанные методы и объекты помещены в небольшую конфигурацию, выгрузка демонстрационной базы во вложении. Используемые в публикации скриншоты созданы из вложенной демонстрационной базы. Подготовка конфигурации к оптимизации кода.Добавляем новые объекты из приложенной конфигурации:
Не забываем добавить права на новые объекты в общедоступную роль. Добавленная подсистема реализует следующие возможности:
Определение проблемных зон кода1. Информацию о проблемах при проведении получаем от наших пользователей - они предоставляют ее в избытке. 2. Выбираем объект, работа которого наиболее критична для бизнеса. 3. В конфигураторе открываем модуль формы обработки "ТестПроведения". 4. Устанавливаем точки останова в процедуре "ВыполнитьТест" до и после основного цикла тестового проведения (в исходной обработке для обычных форм №стр 341 и 444). ![]() 5. Запускаем 1С в режиме отладки.
![]() Выбор вида тестируемого документа ![]() Выбор способа отбора тестируемых объектов ![]() Запуск тестирования 6. При остановке на первой точке останова включаем режим замера производительности ![]() Включение замера производительности 7. При остановке на второй точке останова отключаем режим замера производительности, в окне результата замера, начиная с первой строки, фиксируем области с наиболее длительным выполнением. ![]() Участки кода с максимальными временными затратами 8. Продолжаем отладку. После завершения теста в окне сообщений отобразится результат замеров с временными показателями. Собственно уменьшение этих показателей и является нашей целью. ![]() Результат тестирования Анализ и исправление проблемных зон программного кода1. Переходим к найденным участкам кода, анализируем на возможность оптимизации. О методах оптимизации кода статей множество, поэтому кратко, на что обращаем внимание:
![]() Проблемный участок кода 2. Если найден сомнительный код и появились идеи по его исправлению, добавляем в общий модуль "МодульОптимизация" копию найденой процедуры(функции) с именем, содержащим префикс <Вид оптимизируемого документа>. Объукт документа передаем в параметре. 3. Оптимизируем код в новой процедуре(функции). ![]() Исправленный код в модуле оптимизации 4. Добавляем в начало исходной процедуры(функции) переключение по значениям параметра сеанса на новую процедуру(функцию). 5. Повторяем алгоритм, описанный в п.II, но перед запуском команды "Выполнить тестирование" меняем настройки режима тестирования: устанавливаем флаги "Автоматическое тестирование кода до/после оптимизации" и "Сверка проводок, сформированных до и после включения режима оптимизации". ![]() Включение режима сверки 6. После завершения теста в окне сообщений отобразится результат ваших стараний - показатели до и после использования оптимизированного кода. ![]() Вывод результата оптимизации и сверки проводок 7. Выполняем алгоритмы II и III до тех пор, пока не будут ликвидированы критические проблемы производительности. 8. Если достичь желаемого результата не удается и проведение все равно занимает неприемлемо много времени, перенесите функционал проведения на сервер , используя алгоритм отложенного проведения. Упрощенная схема подобного алгоритма реализована в приложенной демонстрационной базе. Описание настроек обработки "ТестПроведения"Центральным объектом метода оптимизации является обработка "ТестПроведения". Описание ее настроек и команд:
Настройки нагрузочных сессий:
Запуск режима оптимизации в рабочей базеПеред включением режима оптимизации для всех пользователей рабочей базы рекомендую включить оптимизацию для 1-2х пользователей, которые особенно нагружены и недовольны зависаниями и сбоями. Во-первых это даст объективную оценку результата, во-вторых - это дополнительный пользовательский тест алгоритмов, которые в результате проведения оптимизации кода могут существенно отличаться от исходных. Как правило, достаточно эксплуатировать базу в таком режиме 3-5 дней, после чего можно включить режим оптимизации для всех. Включение и выключение режима оптимизации производится с помощью предопределенного элемента "ВключениеОптимизации" справочника "ДопКонстанты". Включение и выключение режима для всех пользователей производится установкой поля "Значение" элемента "ВключениеОптимизации" в "Истина" или "Ложь" соответственно. Для этого можно использовать флаг "Оптимизация включена для всех пользователей" в обработке ТестПроведения. Для включения оптимизированных обработчиков только для конкретного пользователя необходимо добавить в табличную часть "Значения" элемента "ВключениеОптимизации" строку, поместив в поле "Ключ" код пользователя, а в поле "Значение" - значение "Истина". Для включения/выключения использования определенной оптимизированной процедуры(функции), необходимо добавить в табличную часть "Значения" элемента "ВключениеОптимизации" строку, поместив в поле "Ключ" имя этой процедуры, а в поле "Значение" - значение "Истина" или "Ложь" соответственно. Все эти настройки реализованы в тестовой демонстрационной базе. ЗаключениеОписанная методика позволяет провести анализ, оптимизацию программного кода, провести сверку результатов работы исходных и оптимизированных алгоритмов формирования проводок документов. При этом, кроме ощущамого прироста производительности, вы получаете возможность представить заказчику результат своей работы в числовых показателях производительности, подтвержденных реальными замерами. Процесс оптимизации чужего кода - занятие длительное, кропотливое и существенно отличающееся от обычного программного творчества, которым нам, программистам, приходится заниматься. Это бесконечный анализ, поиск новых решений, их реализация, и далеко не каждое решение оказывается удачным. Несмотря на существенный опыт в этой области, на ощутимую оптимизацию конфигурации у меня уходило порой до нескольких месяцев. При этом многие типовые модули приходилось переписывать заново, полностью меняя логику исходных алгоритмов. Но результат этой работы - стабильная рабочая система, в которой сбои и зависания - исключительная редкость. По-этому, если ваша программа 1С работает не так быстро, как вам хотелось бы - проведите ревизию программного кода и оптимизируйте его, оно того стоит.
|
|||||||||||||