DataLife Engine > Блог / Статьи о главном > Тестирование производительности 1с

Тестирование производительности 1с


16-01-2015, 21:11. Разместил: admin
Уделим внимание замеру производительности в конфигурациях на платформе 1с. С этим ведь никто спорить не будет, что скорость программы влияет на скорость работы пользователей? А скорость - это физический показатель. В 1с предусмотрено производить замеры производительности не прибегая к специфичным средствам. Достаточно отладчиком произвести замер и он покажет с тысячными долями секунды, где происходят тормоза. Укажет место, где нужно сделать оптимизацию.
 
Отметим, что даже тогда, когда программист скажет, что разогнать отчет или обработку нереально, не торопитесь в это верить (!). Просто попросите сделать замеры отладчиком и вместе, сообща просмотрите, где происходят тормоза или не оптимально работает по скорости. Если проблема в основном в теле запроса в базу, то и здесь можно ускорить даже стандартными средствами написания текста запросов в разы! Можете нам поверить.
 
В эпоху, когда спрос на время очень высок, скорость программы не должна отставать.

 
 


«Да не может такого быть»

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


 Был на практике один пример. У одного заказчика в обработке поиска номенклатуры запрос работал 60-150 секунд при каждом нажатии на кнопку «Поиск». Результат всегда был почему-то разным. В теле процедур этой обработки запрос за время множества переделок и доделок несколькими программистами был настолько написан не оптимально, что и вызывало такие тормоза. Было произведено очень скрупулезное обследование на предмет правильности написания самого запроса. Перерыт весь интернет на предмет правильности написания как надо. Сначала было ускорено в два раза. Это даже нового разработчика не устроило. Это ключевой момент! Именно разработчика должно не устраивать. Добавлены необходимые индексы в справочники и регистры накоплений. Ускорено еще в два раза. «Да не может такого быть»  — восклицает разработчик. В конце концов, запрос пришлось просто писать заново, что и привело к результату в подборе 1-2-10 секунд. Что и является оптимальным. При условии получения данных из базы по четырем типам цен, по номенклатурному справочнику в более чем 150 тыс. элементов, с учетом характеристик и серий, данных по резервам, остаткам по всем складам, с учетом вхождения в комплекты, плюс сам подбор осуществлялся по символам вхождения в наименование. И вот когда разработчик остался удовлетворенным, только тогда это сработало.
 

 

Нужно постоянно делать замеры производительности 1с!

 

Артемий Лебедев сказал, что «работа дизайнера заключается в том, чтобы не испортить смысл дизайном». Мы немного перефразируем: работа программиста заключается в том, чтобы не испортить функционал своим кодом.


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

 

 


 


Методы получения данных 

 
Еще в бытность программирования на платформе 1с7.7 постоянно сталкивались с проблемой производительности этой платформы. Одолевали постоянные блокировки. Критично одолевали. В большинстве случаев пользовались методом создания отдельной базы  — копии. И в ней выводили отчеты. Но это не панацея. Данные не всегда были актуальны. Ведь в текущем режиме в базе данные постоянно обновляются и пополняются. Выход из положения находили разный и всегда искали его скрупулезно.

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

 

 
 

 

Кто сказал, что мы должны полагаться на типовые механизмы?

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


 


Экспериментировали даже над тем, что отчет уже выведен, а его отображение меняли с помощью скрытия или раскрытия колонок. Данные получены и выведены, а отображение отчета не устраивает. Ну, например, по причине, что колонок много. Все они не помещаются на экране, т.е. не находятся на должном близком расстоянии и их трудно сравнивать. А, изменив галочками в настройках видимость, сразу можем манипулировать колонками как нам нужно. К сожалению, там мы не дошли до того, чтобы можно было в отчете менять колонки местами, а всего лишь их скрывали, но в целом как пример оптимальной работы с отчетом мы получили.


Также пользовались методом альтернативного получения данных. Ведь не обязательно получать данные в отчет путем выполнения именно запроса в базу. В 1с7.7 данные можно было получить по итогам регистров путем прямого обращения к ним. И это давала поразительное ускорение на то время. Но это уже особенность именно этой платформы. В 1с8.2 такого уже нельзя было сделать, да и необходимости в этом не появлялось. Запросы достаточно хорошо отрабатывали свое предназначение. Правда, при правильном их построении.
 
 

 

Тесты


По производительности программу бесспорно нужно тестировать. В этом плане Евгений Гилев на сайте gilev.ru прав и дает дельные рекомендации по проработке этого вопроса. Здесь мы рекомендуем в тяжелых случаях обращаться за помощью к нему, если ваши системные администраторы или программисты не могут справиться с оптимизацией работы баз 1с. 
 
Существует определение, что типовые конфигурации не будут тормозить и оптимально написаны. С этим утверждением мы совсем не согласны. На опыте ощутили, что очень много мест, где можно приложить руку и увеличить скорость в разы, не прибегая к сложным поискам. Существуют досадные ошибки разработчиков типового функционала и их очень много. На стадии запуска и работы в базе, построенной на конфигурации управления производственным предприятием (УПП 1.3), очень много заплаток на этот счет было сделано. И на форумах очень много таких моментов обсуждается. Многие способы оптимизации мы внедряли и по сей день работает. Спасибо всем, кто делится своим опытом. Что-то получалось использовать, но в основном приходилось все на своей шкуре испытывать и самим подправлять. Но советы помогали, на что именно обратить внимание и где искать причину. Даже случалось так, что находили решение проблемы, точно такое же, как сделали мы сами у себя. Другими словами изобрели велосипед очередной. 


 

 

 Например, маленькая проблема в конфигурации Управление торговли (УТ 10.3) в документе «Установка цен номенклатуры» при наличии более тысячи строк документ очень и очень долго открывался и тормозил просто ужасно при пролистывании. При простом замере через отладчик ответ был найден моментально. Был не правильно написан типовой код по обращению к базе по определению условия является ли номенклатура сама по себе «услугой» или нет. И таких обращений было сделано на каждую строку в документе. После этого была проанализирована вся конфигурация на предмет такой проверки и выявились досадные проверки при записи каждого документа складского учета, где проверялись условия номенклатура является «набором» или нет, «услугой» или нет, «комплектом» или нет, заполнена ли «единица измерения мест» и установка «коэффициента» по этой единице в табличную часть документа. И все эти кусочки кода написаны столь не оптимально, что просто диву даешь, почему в типовом коде такое используется. Ведь достаточно в код поставить условия проверки через запрос и практически к этим кускам кода совершенно программа 1с перестала обращать внимание и тратить ресурсы. А такие кусочки на себя отбирали 5-15% каждый и в совокупности в базе фигурировали постоянные блокировки. Даже использование управляемых блокировок не спасало положения. А стоило эти «кусочки кода» придирчиво и скрупулезно вылущивать в конфигурации, так про блокировки мы вообще забыли. Мы не выходили в положение, что блокировок было 700, а потом стало 100. Мы вообще про них забыли, полностью удостоверившись, что дело в коде и установке индексов реквизитов. Но отметим. Без управляемых блокировок в 1с было бы совсем невозможно работать.

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

Мы не ждем манны небесной, а постоянно ищем узкие места в коде и делаем оптимизацию. Вот и в вышеуказанном примере в документе ценообразования в УТ10.3 было исправлено и пользователи вообще «обалдели» от такого результата. По-другому и не скажешь. Столько времени они мучились и им казалось, что причиной такого торможения было из-за наличия в документе много строк. И принимали это как должное! А ведь здесь не нужно было обращаться ни к каким великим специалистам. Достаточно было направить программиста на замер этого процесса, потому что 1с не должна так тормозить (!) на элементарном отображении хранимой информации, пусть там хоть 99999 строк в табличной части. Можно и нужно это подправить.
 

А у вас тормозит документ «Установка цен»?


 

 


Правильность требований

 
Когда заказчики формулируют свои требования, в основном они затрагивают лишь те, которые относятся к непосредственной функциональности системы. Не функциональные же аспекты, такие как производительность, гибкость, время старта, необходимость техподдержки и прочее, остаются на усмотрение разработчика. Однако очень часто первое тестирование не функциональных требований отодвигается до самого последнего момента цикла разработки. К сожалению, это ошибка, встречающаяся слишком часто. Причины этого могут быть различными. Возможно, нет смысла делать что-то быстрым и гибким, если оно при этом не будет выполнять основные требуемые функции, а тестирование может быть очень сложным. Возможно, первые версии системы не будут работать под максимальной загрузкой. Бывает, вызывает улыбку (а иной раз и слезу) когда рекламируют, как вводятся данные в систему. Забьют пару документов и рады. Мол, вот функциональность на лицо. Пользуйтесь и радуйтесь. А стоит в систему загрузить 200 тысяч позиций номенклатур, цены по ним и остатки, то сразу ценность такой системы может сойти на нет, так как она не смогла справиться с таким объемом информации. А ведь кроме этих данных в базе присутствуют еще множество справочников, документов и регистров.

Не обращать внимание на производительность системы?
 
Производительность играет серьезную роль для системы и ее тестирование должно начинаться как можно раньше.
 
 
 

 

 

Периодические тестирования

 

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


Под периодическим тестированием мы подразумеваем метод постоянного возвращения в уже работающие модули, обработки, отчеты, документы, где производится по ним замер производительности через отладчик. Даже, если мы ускорили работу ранее в несколько раз, мы все равно с накопленным опытом на следующий момент тестирования находим множество не оптимальностей. Забытых или неважных на тот момент. Разницы нет, в чем причина. А вот причина, что после всех этих замеров происходила оптимизация работы всей базы и неожиданно для нас самих управляемые блокировки действительно стали в типовом коде справляться и базе вообще не наблюдались взаимоблокировки пользователей. Многие пользователи перепроводят групповыми обработками документы, считается себестоимость, восстанавливается последовательность, а в базе нет блокировок. Это результат постоянного возвращения в уже работающие и довольно долго работающие модули, и их исправление, оптимизация. Типовые или не типовые здесь разницы нет. Правилось всё. Главное это понимать, что делается и самое главное, чтобы пользователи не простаивали из-за того, что программа не работает, т.е. не позволяет им проводить документы или проводит их очень долго.
 
 

 

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

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


 Совсем недавно произошел у одного заказчика момент перехода с Microsoft SQL-сервера на PostgeSQL-сервер. Неожиданным оказалось то, что скорость работы в базе данных 1с упала в сотни-тысячи раз. Например, товарный отчет вместо 5-10 секунд стал выводиться 25 минут. Это было полной неожиданностью и катастрофой использования каждодневного инструмента для множества пользователей. Стали подозревать в новом формате хранения данных. Оказалось зря! Всё гораздо проще. Microsoft SQL даже при плохом программировании выдавал более оптимальные результаты работы и за программистов использовал более оптимальные методы вывода и обработки информации. Возможно виновато не программирование, а заточенный метода на работу именно с этим SQL-ем. А вот в PostgeSQL это оказалось не рабочим. Ранее запросы работали нормально. Но стоило их запустить на PostgeSQL-сервере, как скорость упала во множество раз. Мы сделали простой замер производительности (! простой) и выявили не оптимальность написания запросов. Эта не оптимальность видна при первом же взгляде. Невооруженным взглядом. Для работы в Microsoft SQL это было не критично и «ЛЕВОЕ СОЕДИНЕНИЕ» с регистром «Цены номенклатуры» работало нормально. При критичном подходе, когда каждая секунда пользователя дорога, то и на прежнем сервере можно было бы разогнать отчет до того же состояния. Просто это не замечали. Ведь не стояла проблема в жутких тормозах.

Другими словами мы не подозревали, что нами же написанный код будет настолько не оптимальным. Спросите почему мы так написали ранее?

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

 

Обработки обслуживания


По оптимизации во многих случаях могут помочь простые рекомендации по запуску обработок обслуживания баз SQL. Можно до скончания века увеличивать ресурсы железа (серверов, компьютеров), а платформа возьмет все задействует и по-прежнему будет тормозить. Без планов обслуживания SQL-баз нереально добиться быстродействия. А вот с ними база 1с на SQL себя будет чувствовать прекрасно и вы вместе с ней, если конечно у вас не файловый вариант. Для установки таких планов обслуживания следует обратиться к специалисту.

 
 

 


Вывод


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

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

 Замеры скорости работы программы

 
 
 
Хаки для Dle 10.4
скачать форекс советники Ilan

Вернуться назад