Я не являюсь сертифицированным экспертом по технологическим вопросам, а так же не проходил никаких курсов типа такого
http://Курсы-по-1С.рф/news/2016-10-17-new-optimiza... . Могу говорить только со стороны своего опыта. Оценить и улучшить работу своей системы без внешнего подрядчика вполне реально.
Есть два простых инструмента:
1) для того, что бы понять все ли в порядке с железом - тести Гилева. Это база данных, которая тестирует ЦП, ОЗУ и ПЗУ, а результаты выдает в сравнении с результатами других пользователей на похожем железе. Если у вас данные хуже, то это явный звоночек, что нужно апгрейдить технику или улучшыть настройку СУБД, если у вас серверная база.
2) замер производительности в режиме отладки. Он многое происходящее в системе не показывает (особенно в модели клиент-сервер), но для оценки тонких мест очень даже хорошо себя показал. Это замечательное подспорье для улучшения своих собственных (не типовых) решений.
Еще есть ЦУП, но для его использования нужно прочитать поставляемую с программой методичку и разобраться с непростыми настройками технологического журнала. Для больших предприятий - это конечно нужная штука в качестве мониторинга всей системы и отлова трудновоспроизводимых проблем. Но при оптимизации наличия конкретной проблемы производительности считаю излишне сложным инструментом.
Для поднятия боевого духа могу поделится тремя случаями из практики.
1) Ко мне обратились с просьбой ускорить заполнение документа данными - казалось бы в системе информации очень мало, но на хорошем железе алгоритм отбора отрабатывал несколько минут. С помощью замера производительности выяснил, что алгоритм избыточен - изначально собиралась большая таблица, с нее делалась маленькая выборка, большая таблица уничтожалась и по элементам маленькой выборки делались множественные подзапросы, которые формировали структуру подобную первоначальной таблице и на которые все время и уходило. Пара часиков модификации алгоритма и отбор теперь занимает 10 секунд.
2) Когда-то давно я был разработчиком системы для маленького украинского дистрибутора. Через несколько лет это уже была компания национального масштаба с филиалами во всех областях и они пригласили меня для решения проблемы обмена. У них РБД, которой для сбора данных с филиалов теперь требовалась целая ночь. Практически весь мой код остался за эти года не тронутым и я уже знал где оптимизировать - просто раньше это не имело смысла, так как обмены укладывались в час-два. Согласовал с руководителем проекта и просто выбросил из обмена ненужные данные, подняв скорость сразу в 2-3 раза.
3) Разрабатывал систему он-лайн мониторинга. Обработка главного диспетчера собирала данные и выводила целых 15 минут, что было крайне не "оперативно". С помощью замера производительности выяснил, что большая часть времени уходит на общение с СУБД. тогда я переписал алгоритмы на использование таблиц с предварительно подготовленными данными в оперативной памяти - это позволило ускорится с 15 минут до 4-5. Далее тест Гилева подтвердил своими попугаями, что проблемы в железе. Мы использовали виртуальную машину на украинском хостинге. Арендовали за те же деньги у Хецнера в Германии и сразу получили двойной прирост быстродействия всего - монитор стал отрабатывать за 1-2 минуты. Далее немного подкрутили параметры самой виртуальной машины (поэкспериментировали с различными видами виртуального ЦП, попробовали другие режимы эмуляции) и в результате получили дополнительный небольшой прирост, который позволил обновлять монитор меньше чем за минуту.
Средний
