Мои мысли о жизни, работе и разных интересных штуках вокруг меня.
Показано: 0 · Страница
Думаю, эту картинку для 1Ci нарисовал человек, прямо вот максимально далекий от разработки самой конфигурации и программирования вообще. Потому как программист видит на ней ровно два месседжа о продукте:
На прошлой неделе листал комментарии к 8.3.15 и наткнулся на метод ПолучитьРазмерДанныхБазыДанных(). Стало любопытно, как эта штука работает и насколько её данные расходятся с теми, которые можно получить из, например, Management Studio.
В итоге накатал что-то вроде консоли, через которую методу можно передавать разные метаданные, и принялся следить за запросами платформы к БД.
В общем, размер данных платформа считает примерно таким выражением:
CAST(
SUM(
CAST(
DATALENGTH(T1._Fld40) AS NUMERIC(12, 0)
)
) AS NUMERIC(18, 0)
)
И так для каждого поля, которое есть у объекта, включая стандартные. Если есть табличные части — они тоже считаются. Результат суммируется.
Выводы?
Ну, во-первых, понятно, почему у метода такое дурацкое название. Он считает не размер таблиц, как я изначально подумал, а именно размер данных — то есть на оценку не влияют ни расходы на схему данных, ни расходы на индексы, ни механика экстентов. Учитывается только размер самих данных, которые хранятся непосредственно в объекте.
Таким образом, реальный объём места, которое слопал условный справочник номенклатуры, будет больше того, которое покажет метод. Возможно, значительно. Для точной аналитики такой подход не годится, но чтобы быстро оценить распределение данных в БД – вполне подходит.
Во-вторых, метод никак не считает расходы на историю данных для анализируемых объектов, что честно указано в документации. Теоретически их можно посчитать вручную, оттолкнувшись от _DataHistoryMetadata, но подождем релиз-другой — возможно, разработчики это добавят.
В-третьих, СУБД в ходе расчетов выгребает все содержимое нужных таблиц, а потом считает размер того, что выгребла. То есть вызов, скорее всего, приведет к куче сканирований и может быстро вымыть буферный кэш. На 1cFresh запросы будут делаться с учетом разделителей, но это слабое утешение, как по мне.
В общем, на работающем проде применять с осторожностью.
Недавно внедрили в нашу конфигурацию встроенный в платформу механизм истории данных вместо морально и функционально устаревшего велосипеда из SSLi. Сейчас как раз дописываю выгрузку историю данных в бэкап и загрузку его обратно: удивительно, но этого пока не умеет ни БСП, ни БТС, ни SSLi (впрочем, от последней я и не ждал).
Как закончу, расскажу подробнее. Пока хочу отметить любопытную опцию, которая пригодилась по ходу дела: встроенные в платформу обработки, которые доступны из меню «Все функции», можно выгрузить в виде обычных epf-файлов! Трюк очень подробно разобрали коллеги на Инфостарте (вот тут и вот тут). Вкратце магия выглядит вот так:
КопироватьФайл(
"v8res://mngbase/StandardDataChangeHistory.epf",
"Q:/StandardDataChangeHistory.epf"
);
Полный список стандартных форм и обработок, которые можно вытащить, способ получения этого списка, а также куча споров вокруг и около — по ссылкам выше.
Зачем это пригодится вам — честно, не знаю. Что касается нас, то мы делали интерфейсы для работы с историей данных и было любопытно, как они написаны у самой 1С (спойлер: довольно неряшливо).
Хочу поделиться парой классных текстов о современном софте. Они не особенно свежие (первый-то уж точно), но наверняка ведь кто-то пропустил:
К чему я это вспомнил? На прошлой неделе участвовал в хакатоне среди программистов нашей компании. Узнал кучу клевых штук, а по итогам даже занял первое место (вместе с ещё двумя участниками, у которых получились очень похожие решения).
(если вы — тоже сотрудник «Первого БИТа», то итоги хакатона лежат на портале; там же — отзыв другого победителя, Димы Лещенко)
В процессе нужно было развернуть и настроить целую гору софта: EDT, RabbitMQ, Docker, GitLab, JIRA, SonarQube и ещё вагон инструментов поменьше и попроще. Ладно, к RabbitMQ у меня претензий нет: легкий и быстрый, но вот остальное… Про хороший аппетит EDT я знал и раньше, а вот прожорливость GitLab и JIRA по-настоящему удивила.
Да, в моём случае всё запускалось в докере; да, конфигурация не была оптимальной (например, было развернуто несколько серверов PostgreSQL вместо одного); да, докер был для Windows, а его реализация под эту платформу — тема для едких шуток у всех сисадминов, с которыми я знаком. Но потратить 12 гигабайт ОЗУ прямо со старта?! Про процессор вообще молчу — нагрузка была такая, будто компьютер просчитывал ядерный взрыв в реальном времени.
Короче, лучшей иллюстрации к тезисам Никиты подобрать трудно: софт выше слопал море ресурсов и невозмутимо попросил ещё, даже не приступив к какой-то понятной задаче. Впрочем, в то же время это отличная иллюстрация к тексту Евгения: я, на секундочку, одной-единственной командой развернул несколько операционных систем со сложными серверами внутри. И потратил на это несоизмеримо меньше времени чем, скажем, пришлось бы потратить несколько лет назад.
У меня нет ответа. Думаю, ни у кого нет. Это такой вечный холивар внутри профессии: какую сторону не займи, на деле все равно балансируешь между двумя крайностями — с одной стороны, надо писать хороший, быстрый код, с другой — надо не свалиться в преждевременную оптимизацию. Первое в итоге дает чистое удовольствие от хорошо сделанной работы: вспоминаешь, что ты, черт побери, неплох! Второе — просто позволяет не нажить бед с башкой в поисках идеального алгоритма сортировки пузырьком :-)
Закинул на GitHub короткую функцию, с помощью которой произвольную таблицу значений можно превратить в табличный документ.
Для чего? Чтобы посмотреть её содержимое. Саму таблицу на клиент передать нельзя, а вот табличный документ на её основе — можно. Кроме того, у табличного документа есть клиентский метод Show(), который отображает его в отдельном окне.
То есть можно прямо из режима предприятия просматривать разные служебные таблицы, не тратя время на создание интерфейса для них. Просто передаем их в функцию по ссылке выше, получаем табличные документы, возвращаем их на клиент и выводим.
Всем привет! С вами снова Джонни Кэтсвилл и передача «Самодокументируемый код»!
Сегодня мы переберем строки таблицы значений с Н по Й:
Вроде и мелочь совсем, но когда в пределах одного модуля в пятый раз натыкаешься на такой подход к именованию переменных — глаз невольно начинает дергаться :-)
Дело даже не в том, что этот участок труднее разобрать — просто он неплохо говорит о качестве модуля в целом. Скорее всего, писавший его программист был вымотан, и поблизости можно встретить что-нибудь вроде отважной выгрузки справочника номенклатуры в таблицу значений, чтения кучи объектов «через точку» и прочего тяп-ляп.
Несколько дней назад обсуждал с коллегой, какой способ проверки заполнения ссылки лучше. С одной стороны, время назад на каком-то курсе я слышал авторитетное мнение, что функцию ЗначениеЗаполнено() нужно использовать с осторожностью, так как её логика — сопоставлять переменную всем возможным пустым значениям, которые есть в конфигурации. И это, мол, огромная тормозная лапша. Как альтернативу автор курса советовал использовать метод ссылки Пустая(), а композитные реквизиты проверять примерно так:
СсылкаЗаполнена = Ссылка <> Неопределено И Не Ссылка.Пустая();
Коллега в свою очередь утверждал, что ЗначениеЗаполнено() быстрее, так как это встроенная функция, которая не тратит время на поиск метода у объекта (в скриптовых языках это сравнительно медленная операция).
На моей памяти ни тот, ни другой метод узким местом никогда не были, но меня разобрало любопытство; написал тест, который проверяет ссылочную переменную на пустое значение обеими способами и замеряет время, которое было потрачено.
В среднем результат выглядит примерно так. Там четыре шага — на первых двух предполагается, что ссылка определена, а на третьем и четвертом добавляется соответствующая проверка. В последней колонке таблицы виден контекст выполнения теста (клиент или сервер).
Вывод довольно очевиден: ЗначениеЗаполнено() никакой деградации не показывает, более того — работает быстрее, чем метод Пустая() (особенно если мы начинаем проверять переменную на Неопределено). Конечно, отклонение не слишком значительное, но на каких-то длительных регламентных операциях вполне можно сэкономить пару секунд.
Да и чисто практически проще делать проверку одним универсальным вызовом, а не пытаться угадать все возможные значения переменной.
Чаще всего неразрешимые ссылки на объекты метаданных образуются в ходе удаления объектов (и, иногда, при объединении конфигураций). На ИТС есть статья по этой теме, там хорошо описаны детали.
На работе программы битые ссылки сказываются далеко не всегда. Конечно, поле без привязки к данным заметить несложно, но вот удалили вы, допустим, функциональную опцию — что с того, что ссылка на неё осталась где-нибудь в команде на форме? Она будет просто лежать, как обрезанный провод, инертный и безвредный. Ничего по нему не идет.
Однако такие штуки постепенно захламляют конфигурацию, и от них правильно избавляться, и на ИТС предложена не больно-то эффективная методика (последовательный перебор всех возможных мест, где может быть битая ссылка). Представьте себе сложную форму документа с множеством элементов; сколько времени придется потратить на поиск? Еще не факт, что успешный.
Есть более грубый, но действенный метод: последовательно удалять с формы группы элементов. Можно начинать с больших групп (например, со страниц). После каждого удаления выполнять проверку конфигурации и смотреть — исчезла битая ссылка или нет. Перед началом работы лучше удалить из формы весь код, чтобы платформа не ругалась на обращения к несуществующим элементам.
Проблема, кстати, может быть не в элементах, а в самой форме — но там её куда проще найти (хранилище настроек, условное оформление, команды; в общем, кандидатов немного).
Ещё можно сделать выгрузку конфигурации в файлы и порыться в полученных XML-ках. Это неплохая идея ещё и потому, что сам по себе внешний вид элементов может вас обмануть: если, например, речь идет о ссылке на функциональную опцию в команды формы, то при проверке свойств команды вы даже не заметите, что есть какая-то проблема. А вот в XML-ке будет болтаться какой-то подозрительный GUID вместо наименования опции — считай, явка с повинной :-)
Короткий фрагмент кода из обработки для настройки механизма истории данных, о которой я только что писал. Эта функция определяет, является ли Attribute стандартным реквизитом с именем StandardAttributeName, принадлежащим объекту метаданных MetadataObject. Где она нужна? Допустим, вы перебираете стандартные реквизиты объекта и по какой-то причине хотите пропустить один из них.
На первый взгляд решение выглядит максимально индусским. Почему бы, например, просто не сравнить два реквизита — проверяемый и тот, что хотим отсеять?
If Attribute = MetadataObject.StandardAttributes.Order Then
Дело в том, что такой код не сработает: результат операции сравнения двух стандартных реквизитов объекта метаданных в платформе 1С — всегда Ложь.
О'кей, скажете вы — может, тогда не будем усложнять и напишем вот так?
If Attribute.Name = "Order" Then
Однако так тоже не сработает, если ваш код будет запущен в русскоязычной конфигурации: стандартный реквизит, который мы пытаемся найти, в этом случае будет называться «Порядок».
Тем не менее, к самому стандартному реквизиту внутри коллекции можно обращаться и по-русски, и по-английски. Потом получаем текущее имя атрибута и сравниваем с именем того атрибута, который проверяем.
Конечно, можно было просто сделать сравнение имени реквизита и с «Order», и с «Порядок» — но это, во-первых, некрасиво, а во-вторых — стандарты программирования у нас в компании запрещают писать код на русском. В общем, мне хотелось найти более общее решение.
Что до конструкции Try/Catch — она тут на тот случай, если стандартного реквизита с таким именем в конфигурации нет вообще (и попытка обратиться к нему по имени приведет к ошибке).
Выложил на GitHub обработку для настройки механизма истории данных, который сравнительно недавно появился в платформе. Эта обработка:
Обработка поддерживает пакетные операции — например, можно включить историю разом для нескольких документов и всех справочников. Или вообще удалить все внесенные настройки, откатив состояние механизма к тому, которое заложил разработчик конфигурации.
По-моему, неплохо получилось. Я писал эту штуку больше для себя, разминая мозг по вечерам — но мы, возможно, даже включим её в нашу конфигурацию! Сейчас версионированием данных в ней занимается SSLi, и её механизмы трудно назвать эффективными — медленные и сильно раздувают базу. Надеюсь, платформа на тестах покажет себя лучше.
На Инфостарте и ИТС можно найти похожие разработки, но они либо глючат, либо работают только на русскоязычных конфигурациях (не имеют английского интерфейса + опираются на БСП), либо просто-напросто устарели (например, не поддерживают работу с константами).
Выложил на GitHub скрипт на баше, который по собранному технологическому журналу 1С определяет наиболее частотные исключения.
Скрипт анализирует события EXCP. Это основной источник информации об ошибках, хотя, конечно, не единственный: например, есть EXCPCNTX (событие, которое началось, но не закончилось в тот момент, когда произошла ошибка). Кроме того, если исключение происходит во время серверного вызова, то в поле RetExcp у события CALL будет текст ошибки, которая вернется на клиент.
Впрочем, в большинстве случаев EXCP и, иногда, EXCPCNTX вполне достаточно. Часто их собирают просто по умолчанию — нагрузки это не создает, зато позволяет прогонять собранные логи через какой-нибудь инструмент аналитики (скрипт выше, например) и держать, так сказать, руку на пульсе.
В конце недели столкнулся с довольно глупой ситуацией: отладка через TCP/IP на сервере 1С перестала работать. То есть сам по себе режим отладки включен, однако конфигуратор «не видит» контекстов отладки на сервере.
Ситуация глупая в том смысле, что понять причину довольно сложно: явных ошибок платформа не выдает. После проверки очевидных вариантов (фаервол, порты и так далее) остается только руками разводить.
Решил проблему, переключившись на отладку через HTTP. Инфрастуктурно это более сложная схема, но настраивается она довольно просто; если вкратце, то нужно:
Подробнее процесс настройки описан на ИТС.
Случайно наткнулся на пример запроса в 1С, который считает разницу между двумя датами (в годах, месяцах и днях).
Код, возможно, действительно работает (я не проверял), но как по мне — это хороший пример того, как делать не надо. Проблема в том, что автор забудет смысл большинства если-тогда-иначе через пару месяцев, не говоря уже о посторонних разработчиках, которые решат использовать этот код на своих проектах. В итоге при первой же доработке, которую потребуется провернуть на этом участке, куда дешевле будет заменить решение на что-то более наглядное, а не доработать.
И это еще далеко не самый наглядный пример. Взять хотя бы регулярки для проверки e-mail. Хочется выйти подышать, да? :-)
Архитектор нашего основного продукта (и, по совместительству, мой тимлид) рассказывает о том, как мы внедряли 1С в Дубае. Погружений в технические детали нет, так что можно смотреть всем, кто хотя бы чуть-чуть в теме.
Видео записано на краснодарской конференции разработчиков в июне прошлого года, так что кое-что уже поменялось. Например, у нас появились вполне рабочие прототипы программы на арабском языке, а объём автотестирования вырос настолько, что мисс Ванессу стоит считать отдельным членом команды :-)
Получил вводную: документ закрытия месяца у заказчика проводится без малого час. База не особенно большая, но такая продолжительность в любом случае не вариант. Даже если учесть, что закрытие месяца — это ни разу не частотная операция и её можно делать, например, ночью.
Лезу в код, делаю замер производительности и вижу, что и почти всё это время платформа тратит на одну-единственную процедуру, выполняя пакет запросов. Смотрю первый из них; ну, думаю, классика — запрос данных через точку от составного типа. Наверняка СУБД пристегивает целый вагон соединений с тяжеленными таблицами документов, вот оптимизатор и не успевает набросать адекватный план.
Проверяю теорию — так, а тип SalesDocument включает всего восемь документов. Это, условно, в пределах допустимого (считается, что оптимизатор в состоянии подобрать адекватный план выполнения запроса, если количество соединений — в пределах восьми).
Смотрю размеры таблиц документов — не особенно-то и большие. Выполняю запрос отдельно от пакета — да, работает не мгновенно (читает около 350 000 записей и отбирает примерно 200 000), но никак не час.
Ладно, первый запрос пакета тяжелый, но проблема не в нём. Лезу во второй и понимаю, что до этого прочитали весь регистр Inventory и отобрали большую часть записей, а теперь — читаем его ещё раз и склеиваем обе выборки по куче условий. Подходящего индекса в таблице движений нет — только стандартный по регистратору и он, конечно, не подходит.
Проверил — именно тут платформа и проводит большую часть времени, ожидая ответа от СУБД.
Отказаться от двойного чтения всей таблицы регистра не вышло: я перебрал несколько вариантов, но все они требовали изменения структуры хранения данных, что было неприемлемо. В итоге остановился на промежуточном варианте: во втором запросе соединение с реальной таблицей движений регистра заменилось на соединение с заранее созданной временной таблицей, проиндексированной по полям соединения.
Это тот случай, когда общая рекомендация 1С сработала идеально — вместо 50 минут документ стал проводиться за три, а после дополнительной оптимизации кода — за минуту. То есть, в пятьдесят раз быстрее того, что я имел вначале.
Такой результат я счел достаточным (минута для закрытия месяца — это в общем случае нормально) и остановился.
ЦУП нужен, чтобы:
В первом случае можно включить анализ запросов и, допустим, серверных вызовов. По результатам можно понять, что в системе грузит сервер приложений, а что — сервер СУБД. Часто так делают даже не решая конкретную проблему, а просто чтобы устранить узкие места и увеличить запас прочности системы на будущее.
Во втором сценарии включают анализ блокировок или взаимоблокировок — когда знают, что они есть в системе, и хотят получить отчет: кто заблокировал, кого, когда, на какой строчке кода и так далее.
В обеих случаях мониторинг запускают только в периоды основной нагрузки и минут на десять-пятнадцать. Массив исходных данных получается сравнительно небольшим (ЦУП'у нужно его обработать перед выдачей результата, чем больше данных — тем больше времени потребуется). Кроме того, не будет собрано лишних данных — например, не будет анализа нагрузки от регламентных работ, которые вы проводите ночью.
Кроме того, это снижает влияние сбора данных на работу системы. Дело в том, что ЦУП может собирать очень тяжелый ТЖ, способный заметно нагрузить железо (на 30% медленнее? подержи мое пиво). С этим лучше быть осторожным.
Для всего, что перечислено выше, достаточно аналитических показателей ЦУП'а: анализа запросов, ожиданий на блокировках, анализа взаимоблокировок 1С и MS SQL. Что до оперативных показателей — количества выполняемых запросов, суммарного времени их выполнения и так далее — то популярностью они не пользуются. Польза от них обычно не стоит времени на настройку, и ЦУП по большому счету никогда не проектировался для того, чтобы постоянно собирать их.
Задача: нужно найти в общих модулях конфигурации методы с определенным параметром (в этом примере — с параметром DecimalPlacesFor).
Обычный поиск по коду конфигурации даст массу ложных срабатываний (например, все обращения к параметру с таким именем в теле методов). Поиск по регулярным выражениям платформа пока не поддерживает, поэтому выгодно выгрузить конфигурацию в файлы и натравить на папку общих модулей скрипт на баше.
Первая часть скрипта (до пайпа) выполняет сам поиск, вторая — отрезает лишнее, чтобы на вывод уходили только названия модулей и найденных в них методов. Получится, например, так:
Профит? Профит!
Посмотрел вебинар Евгения Филиппова про Баблокс. В общем, это такая дополнительная методика оценки производительности. Как и Апдекс, опирается на замеры времени — но предлагает иную механику расчета.
Чтобы посчитать Баблокс, нужно умножить продолжительность операции на зарплату пользователя, который эту операцию делает. Зарплатой может быть:
В итоге получим сумму, которую бизнес потерял, условно, из-за тормозов программы. В этом главный плюс методики: это число проще донести до среднего финансового директора. Что означает Апдекс, равный нулю целых пяти десятых — еще поди объясни, а вот что такое потерянные триста тысяч рублей — понятно сразу.
Кроме того, снимаются субъективные вопросы, которые возникают при каждом внедрении. Например, определение ключевых операций; вот скажите, что важнее — быстрее продать товар или оприходовать на склад? Когда известно, сколько компания теряет в деньгах на каждой из этих операций — ответ дать куда проще.
Конечно, это не идеальная модель. Например, возьмем такую ситуацию: программа тормозит у кладовщиков, но нормально работает у бухгалтеров. Зарплата кладовщиков ниже, чем зарплата бухгалтеров, и Баблокс для них будет невелик. Однако бухгалтера работают с тем, что ввели кладовщики, и пока последние не закончили — бухгалтерам нечем заняться. То есть компания теряет деньги из-за тормозов программы у кладовщиков, но Баблокс это не покажет.
В общем, Баблокс вряд ли подвинет позиции Апдекса внутри айти-сообщества, но это и правда любопытный подход, который может здорово помочь в диалоге с клиентом.
Что можно считать большим внедрением 1С? Фактически, эта платформа в России используется почти везде — даже в тех компаниях, где широко применяются решения конкурентов (например, тот же SAP). Конечно, где-то объемы внедрения невелики и 1С решает чисто утилитарные задачи вроде формирования отчетности, но среди работ ЦКТП можно найти по-настоящему колоссальные проекты — например, оптимизацию системы «Деловых линий», которая рассчитана на пять тысяч одновременно работающих пользователей.
В общем, всё это приводит к тому, что средним внедрением в России сейчас считаются базы, в которых одновременно работают сотни пользователей, а большим внедрением — базы, где работают от тысячи пользователей (и больше).
Размер базы при этом — не критерий: есть множество конфигураций, не предполагающих одновременной работы пользователей. Классический пример — 1C:Документооборот, менее классический — «Управление Автовокзалами» Авибуса. Последняя в состоянии накопить в своей центральной базе огромный объем данных от удаленных узлов своей распределенной сети (автовокзалов и автостанцией), однако большое количество одновременно работающих пользователей для нее не характерно.
Если отключить для всех измерений оборотного регистра опцию «Использование в итогах», то обороты для регистра рассчитываться не будут. Более того, таблица оборотов регистра будет удалена из базы данных, и попытка обратиться к ней на языке запросов 1С приведет к ошибке.
Такой трюк может быть уместен, когда мы накапливаем какие-то данные, а потом просто фильтруем их по регистратору или по другим полям. То есть от регистра нам нужна только его таблица движений. В этом случае нет никакого смысла тратить ресурсы сервера на расчет таблицы оборотов и её хранение.
Конечно, при виде такой задачи в голову сразу приходит регистр сведений. Однако эффективность этого варианта зависит от количества измерений, которые вы собираетесь завести в регистре; дело в том, что каждый индекс по регистру сведений включает все его измерения (а периодические регистры — ещё и период). Между тем, платформа создает базовый индекс по измерениям, индекс для каждого измерения с признаком «Ведущее», а ещё — индекс для каждого измерения, ресурса или реквизита, которые вы решите проиндексировать отдельно. И это мы еще не дошли до таблиц срезов, где применяется тот же подход!
В общем, накладные расходы на содержание индексов могут быть довольно заметны, если регистр сведений спланирован не особенно удачно и содержит сравнительно много измерений (скажем, больше двух-трех). В этом случае «плоский» оборотный регистр без оборотов смотрится вполне прилично.