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