"Крест ИТ", или как жить, если у вас в ИТ ландшафте выросло Кудрово/Мурино/Девяткино

Публикация № 1399393 09.03.21

Администрирование - Производительность и оптимизация (HighLoad)

Добавлять новую функциональность в ИТ-ландшафт, базирующийся на тяжелых «монолитах», с каждым годом становится все сложнее. О способах преодоления проблем больших и сложных приложений на INFOSTART MEETUP Saint Petersburg.Online рассказал архитектор компании BIA Technologies Марат Шайхутдинов.

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

Разберемся, почему это происходит, как с этим жить, и почему с этим придется столкнуться любой компании, которая «доживет» до обретения своего зрелого ландшафта.

 

Концепция «Крест ИТ»

Хорошая модель, которая описывает концепцию этой идеи, называется «Крест ИТ». Она базируется на двух основных фактах:

  • Бюджет, выделяемый на ИТ, либо не растет, либо растет очень медленно.
  • Затраты на уже реализованные решения растут всегда, и растут достаточно быстро.

 

 

Из этой простой установки рождается печальный факт – рано или поздно любой бюджет, выделяемый на ИТ, будет «съеден» затратами на решения, которые были реализованы ранее.

Эта концепция хорошо описывается простым графиком. Посмотрите на две области: слева область с довольным человечком, справа – с грустным.

  • Область со смайликом описывает ресурс, который остается на реализацию новых интересных решений, полезных для бизнеса.
  • Правее человечек не такой веселый, показывает, как затраты на поддержку «съедают» весь выделенный на ИТ бюджет и продолжают расти, получая свое в виде постоянных аварий, инцидентов и тому подобное.

Что мы можем сделать как разработчики, чтобы оставаться в левой части как можно дольше? В контексте этой модели есть два глобальных решения:

  • Что-то сделать с бюджетом, чтобы он рос ускоренно. Наверное, иногда это получается, но крайне редко.
  • Как-то повлиять на скорость роста затрат на поддержку, чтобы красный график был как можно более пологим.

Что влияет на угол наклона графика? Очевидно, что факторов будет много, и в разных компаниях эти факторы, скорее всего, будут разными. И для них при всей несхожести будет соблюдаться принцип Парето. Это значит, что два-четыре основных фактора будут генерировать максимальный, либо большую долю объема затрат. В нашем конкретном случае найти если не факторы, то причины и место обитания этих факторов, было достаточно просто.

 

Тяжелые системы как основа ИТ-ландшафта

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

 

 

Из анализа объема операций и долей задач, которые реализуются в наших основных системах, без всякой калькуляции можно сделать вывод, что почти все затраты приходятся на наш ТОП-3 систем. На первую – с большим отрывом.

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

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

К сожалению, если и было время, когда это можно было сделать – оно упущено много лет назад. Слоник уже вырос, съесть его за раз не получилось и не получится. Придется делать это за несколько подходов.

 

Как появляются монструозные системы

Прежде чем рассказывать «ужасы нашего городка», и как тяжело жить с большими системами, скажу, что у них есть определенные плюсы. Сам факт существования больших систем – в нашем случае это более 10 лет – говорит, что у таких систем есть какие-то плюсы, драйверы их постоянного роста:

  • Есть как минимум несколько классов задач, которые в таких системах решаются лучше, чем в менее масштабных.
  • Монолитные системы удобнее разрабатывать: пользователю проще сформулировать свою задачу и понять свое пожелание относительно уже существующих объектов, возможностей и интерфейса. То же касается разработчиков с аналитиками.
  • Задача реализовать что-то новое связана с повышенными сложностями. А тут, когда вы разрабатываете в уже устоявшемся монолите, вся команда разработки освобождается от мук творчества. В монолите всегда есть один – максимум два – правильно работающих способа в отличие от разработки с нуля, где всегда куча вариантов, которые подходят, и сложно выбрать единственно правильный. А когда цель ясна, средства понятны – команде разработки комфортнее работать.

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

 

Ключевые проблемы больших систем

На каждом новом этапе встречаются один-два-три фактора, которые катастрофически влияют на производительность, стоимость сопровождения, поддержки и разработки в этих системах.

 

 

Я разделил факторы, оказывающие негативное влияние на систему, на три большие группы.

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

 

Первая группа факторов: растущие показатели

Давайте перейдем к первой группе факторов. Эта группа факторов – самая сложная и самая простая.

 

 

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

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

Давайте пробежимся по способам решения для каждого из этих факторов.

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

Объем функциональности рано или поздно приводит к другой сложности. Это когнитивные сложности.

 

Фактор второй: когнитивные сложности

В нашей системе ведется разработка больше 10 лет. За это время реализована большая функциональность: сотни и тысячи процессов так или иначе автоматизированы с помощью нашей большой системы. Эти процессы и варианты их использования, которые мы реализовали, сформировали целые комки, сложные для понимания и анализа, с которыми приходится работать.

 

 

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

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

Необходимо разработать «базу знаний», которая позволит нам быстро и качественно спроектировать новое решение. Вовремя увидеть, что запроектированное решение повлияет так или иначе на какие-то процессы, которые мы не хотим затронуть.

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

Хочется надеяться, что мы сможем собрать базу знаний, и это позволит не просто разрабатывать новые решения или быстро разбираться с инцидентами. Есть понимание, что когда наступит час Х, и мы захотим вынести большой объем функциональности в кластер, во внешнюю систему, нам эта «база знаний» будет жизненно необходима. В противном случае безболезненно или хотя бы приемлемо болезненно вынести эту функциональность будет сложно.

 

Третий фактор: качество кодовой базы

И третий, самый важный фактор, который влияет на стоимость поддержки уже реализованных решений – качество кодовой базы.

 

 

На качество кодовой базы постоянно оказывается достаточно мощное влияние.

  • В нашей системе одновременно работает множество разных команд разработчиков, у каждой свой подход, своя доменная модель, и самих разработчиков достаточно много. Даже при небольшой текучке мы постоянно сталкиваемся с такими проблемами, когда важный кусок кода разрабатывал один разработчик, перед уходом передал эту работу другому, а другой разработчик передает третьему.
  • Специфика работы в монолите не позволяет правильно разделить доменные области. Очень сложно сказать, что эту часть разрабатывает одна группа разработчиков, вот эту – другая. Очень размыты границы между ответственностью команд. Есть большая куча объектов, которая разрабатывается одновременно несколькими разработчиками: это приводит к тому, что сложно разделить эти домены. Их границы размыты и малопонятны.
  • Плюс ко всему у нас есть вопросы к историчности. Как я говорил, база работает больше 10 лет. Сначала она работала на платформе 8.1, затем – 8.2, затем – 8.3. Все эти артефакты так или иначе остаются, и нам приходится что-то с этим делать.

Как сделать так, что даже при большой кодовой базе и множестве факторов, которые влияют на качество разработки, как-то с этим управляться?

  • Базовое решение – повысить общий уровень разработки. Обучение и адаптация, входной фильтр разработчиков. Наши разработчики понимают ряд вопросов лучше, чем в среднем по рынку, например: вопросы производительности, то, как работают индексы, как выполняются планы запросов, и как эти планы зависят от состояния статистик.
  • Использование общих шаблонов и подходов, плюс код-ревью и автоматизация проверок позволят выровнять, нормализовать качество кода, сделать новые доработки и сделать приемлемым и понятным поддержание старых.

 

Про подход к проектированию новых решений

Остается еще один важный момент – то, как мы проектируем новые решения.

 

 

Правильный подход к задачам также является очень важным. Даже при неплохом уровне разработчиков все равно нужно хорошо погружаться в разработку некоторых задач.

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

Но есть задачи, которые делаются с расчетом, что доработки будут постоянно модифицироваться. Как пример: реализация бизнес-процессов, выполнение производственных функций. Тут подход – сделать раз-раз и в продакшн – не совсем оправдан. Надо вовремя увидеть, что задача относится именно к этому классу и отнестись к ней по-другому. Хороший пример такого подхода у нас был реализован при разработке нашей внутренней библиотеки стандартных подсистем.

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

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

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

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

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

Системный архитектор должен следить, чтобы разрабатываемые задачи не требовали глубокого погружения, вовремя увидеть сложные задачи и найти ресурсы для их правильной проработки. Почему это важно? Потому что все равно придет момент, когда что бы мы ни делали, затраты на поддержку съедят весь имеющийся у нас ресурс. Мы придем к моменту, когда матрицу придется перезагружать. И чем больше и качественнее у нас будут проработаны эти механизмы, чем более они будут сконцентрированы, тем легче нам будет разнести систему. Растянуть расставание с большой тяжелой базой на более длительный период либо как-то минимизировать время разработки во время резкого перехода, если вдруг возникнет такая необходимость.

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

 

Вопросы

На одном из слайдов был рассказ про вынос функциональных блоков из большой системы. Расскажи про проблемы, которые были с этим связаны. Что мешает функциональность в большом монолите на сторонние, рядом стоящие решения?

Готовых 100% успешных решений для выноса этой функциональности в отдельные блоки у нас нет. К сожалению, все объемные кластеры функциональности – функциональность работы с заказами, то, как мы рассчитываем себестоимость и цены продукции – все это было реализовано в монолите и, конечно, требует выноса в отдельный функциональный блок. Но мы этого не смогли сделать? Почему? Потому что это действительно жизненно важные элементы бизнеса заказчика, они постоянно дорабатываются и вынос этой функциональности сродни операции на работающем сердце. Чтобы сделать это безопасно, с одной стороны, необходимо остановить разработку, на что не может пойти заказчик. Поэтому единственный вариант это реализовать – это либо дождаться, когда другого варианта не будет, либо второй вариант – когда бизнес скажет, что хочет что-то кардинально новое. Тогда естественно будет повод разработать новую систему и быстро перевести комплект функциональности на работу с внешней системой. Чтобы это сделать как можно более безопасно, нам и нужны хорошие разработчики и база знаний по всем кейсам, которые позволят сформировать задание на переход. Сергей Носков в одном из предыдущих докладов говорил: «У кого одна база, хочет ее разделить, у кого их несколько, хочет объединить». Это вечный цикл.

Как происходит обрезание системы? Сколько оно занимает по времени?

Мы не столько обрезаем старую базу данных – у нас есть волшебная штука, которая создает новую базу, в которой будет консистентные данные за последний период. При наших объемах – это единственный вариант. Из-за специфики хранения данных на MS SQL, альтернатив нет. По времени, так как это происходит зеркально, не останавливая процесс работы бизнеса, последний раз это заняло дня три-четыре.

Сколько человек занимается администрированием СУБД таких размеров?

DBA-шников – двое. А разработчиков у нас много.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Saint Petersburg.Online. Больше статей можно прочитать здесь.

Приглашаем всех принять участие в тематических митапах Инфостарта и INFOSTART EVENT 2021 (6-8 мая, СПб).

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Terve!R 10.03.21 13:11 Сейчас в теме
Мне кажется, это все справедливо только для действительно крупных систем и больших команд разработки. Не все могут в таких поработать)
3. Aleksey.Polushin 18.03.21 12:09 Сейчас в теме
(1) у нас система почти на 4 000 пользователей - но уже чувствуется, что надо как минимум прекратить расширение функционала существующей системы и дальнейший функционал уводить на "микросервисы" с глубокой интеграцией, а лучше уже начать "дробить" существующую систему. А система вроде как и не очень крупная.
2. Rustig 1202 12.03.21 06:27 Сейчас в теме
(0) рабочих примеров мало...вообще ничего не осталось в памяти после прочтения....что можно взять здесь и сейчас - и применить ?..
Оставьте свое сообщение

См. также

Диспетчер Хранилища Запросов в SQL Server 2016+ (он же Query Store) Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Если вы используете SQL Server 2016 или более позднюю версию, то у вас есть возможность использовать встроенную систему мониторинга, которая позволяет отслеживать самые базовые метрики выполняемых запросов и статистику ожиданий (потребления ресурсов). Эта информация позволяет быстро получить самые ресурсоемкие запросы с их планами и агрегированной статистикой выполнения.

26.04.2019    13850    Aleksey.Bochkov    7    

Повышение производительности веб-сервисов. Переиспользование сеансов

WEB Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Повышение производительности веб-сервисов. Переиспользование сеансов. Практическая реализация.

вчера в 15:00    376    sorter1    2    

Мониторинг сервера 1С:Предприятия на GNU/Linux с помощью Zabbix

Zabbix Бесплатно (free)

Специалист по информационным системам в компании «Камин-Софт» Алексей Федотов выступил на митапе Инфостарта, посвященном работе 1С и Linux. Алексей поделился с коллегами, как контролировать работу 1С на Linux с помощью Zabbix.

06.10.2021    1044    Sloth    1    

1С, Linux, облака…

Облачные сервисы, хостинг Zabbix v8 Бесплатно (free)

Архитектор проекта ENOTE Александр Кирилюк выступил на Infostart Meetup «1С и Linux». Александр поделился с коллегами, как начать жить в облаках, выбрать для этого подходящие ЦОДы и ПО и справиться как с распространенными, так и редкими проблемами Linux-систем.

05.10.2021    721    ArtfulCrom    2    

Опыт миграции из собственного датацентра в облако AWS Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Хотя данная публикация и не имеет прямого отношения к 1С, она может быть интересна тем, кто занимается крупными базами данных на MS SQL Server. Описывается опыт миграции баз данных в облако AWS в компании glassdoor.com, где я занимался этим проектом. Это первый драфт текста, получившийся довольно скомканным - в процессе буду дополнять.

29.07.2018    12213    Aleksey.Bochkov    9    

Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности

Производительность и оптимизация (HighLoad) Рефакторинг и качество кода Технологический журнал v8 Бесплатно (free)

Расскажем про инструменты, рассмотрим планы запросов, увидим, как отслеживать и бороться с проблемами производительности на боевой базе.

07.09.2021    3459    ivanov660    22    

Показатель Page Life Expectancy (PLE)

Производительность и оптимизация (HighLoad) Администрирование СУБД Бесплатно (free)

От переводчика: публикация составлена по материалам BrentOzar.com (Brent Ozar).

18.08.2021    1252    vasilev2015    6    

Кластер для отказоустойчивости

Производительность и оптимизация (HighLoad) Администрирование СУБД Бесплатно (free)

На Infostart Meetup «PostgreSQL VS Microsoft SQL» выступил руководитель проектов в по разработке ПО в компании «Газинформсервис» Денис Рожков. В рамках доклада Денис рассказал о том, какие механизмы кластеризации используются для PostgreSQL и в MS SQL и поделился с коллегами, какие решения можно использовать для построения отказоустойчивого кластера на PostgreSQL.

18.08.2021    1777    FB_3393521717335803    0    

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Технологический журнал v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    32628    MrWonder    42    

Адекватный параллелизм в 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Параллелизм ускоряет выполнение тяжелых регламентных операций на СУБД, но может негативно влиять на работу многопользовательских учетных систем. О том, как анализировать влияние параллелизма и настраивать его для MS SQL и PostgreSQL, рассказал ведущий разработчик компании ООО МКК «Ваш Инвестор» Вадим Фоминых.

13.08.2021    3082    Shmell    7    

Создаем счетчики производительности Windows для 1С

Производительность и оптимизация (HighLoad) Бесплатно (free)

В статье описан подход, позволяющий создавать счетчики производительности Windows для 1С:Предприятие.

09.08.2021    3428    blackhole321    8    

Снова про анализ технологического журнала с помощью PowerShell

Технологический журнал v8 Бесплатно (free)

Универсальная методика анализа технологического журнала (далее - ТЖ) с помощью Powershell без применения алгоритмов программирования.

05.08.2021    1422    cdiamond    0    

Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года. Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии". Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность. Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры. **update от 04.03.2016 по вопросам из комментариев

05.08.2015    66892    Sergey.Noskov    119    

Распространенные ошибки разработчиков, приводящие к проблемам производительности

Производительность и оптимизация (HighLoad) Рефакторинг и качество кода v8 Бесплатно (free)

Рассмотрим примеры ошибок, анализ, исправление и мероприятия по недопущению подобного в будущем. Всего будет 18 примеров.

02.08.2021    8809    ivanov660    77    

Fill factor

Производительность и оптимизация (HighLoad) Бесплатно (free)

От переводчика: Публикация составлена по материалам BrentOzar.com (Brent Ozar).

02.08.2021    2562    vasilev2015    6    

Parameter sniffing и генерация планов для разработчиков 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Особенности генерации планов запросов. Статья написана по мотивам вебинара Виктора Богачева.

01.06.2021    8037    vasilev2015    17    

Долго открывается конфигуратор Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    43803    Gilev.Vyacheslav    1    

Поиск причин блокировок СУБД

Производительность и оптимизация (HighLoad) v8 v8::blocking 1cv8.cf Бесплатно (free)

Расследование блокировок СУБД. Статья написана по мотивам вебинара Виктора Богачева.

28.04.2021    5534    vasilev2015    13    

Тонкости эксплуатации, плюшки и особенности Postgres Pro Enterprise

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

В ходе онлайн-встречи INFOSTART MEETUP Novosibirsk Руководитель ИТ из компании ИнфоСофт Антон Дорошкевич поделился с коллегами тонкостями и опытом работы с Postgresql для 1С. 

22.04.2021    2225    a.doroshkevich    4    

Решение нестандартных проблем производительности на реальных примерах

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

На екатеринбургском Infostart Meetup выступил с докладом архитектор ИС центра разработки ФТО Александр Криулин. Он поделился с коллегами кейсами нестандартных проблем производительности и рассказал о способах их решения.

24.03.2021    4799    AlexKriulin    37    

Видеодемонстрация применения Теста-центра для нагрузочного тестирования конфигураций Промо

Нагрузочное тестирование v8 1cv8.cf Бесплатно (free)

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

16.09.2012    36378    Aleksey.Bochkov    29    

Рецепты приготовления технологического журнала

Технологический журнал Бесплатно (free)

Понимание принципов событий технологического журнала позволяет решать многие проблемы производительности и стабильности работы платформы 1С. О том, как взаимосвязаны события технологического журнала и как с их помощью можно анализировать серверные вызовы 1С, на INFOSTART MEETUP Ekaterinburg.Online рассказал программист 1С из компании ДНС-Ритейл Максим Старков.

22.03.2021    4911    max_st    5    

Анализ полного технологического журнала, 100ГБ+

Технологический журнал Бесплатно (free)

В этой статье рассматривается анализ полного технологического журнала, размер которого за 1 час достигает 50Гб+. Когда у какого-то пользователя что-то происходит, но не постоянно, и выделить определенного пользователя не получается, и проще собрать полный технологический журнал. Но на дальнейшем анализе доступные визуальные средства не выдерживают таких объемов, и просмотр журнала объемом 50Гб попросту вылетает. Но поведение 1С все же хотелось бы изучить и проанализировать, что происходит.

18.03.2021    2591    Axel2009    18    

Анализ производительности: Трассировка + Логи системного монитора

Производительность и оптимизация (HighLoad) Бесплатно (free)

Небольшая заметка о том, как можно анализировать производительность при помощи собранной трассировки и показателей логов системного монитора.

16.03.2021    986    AlekseyBelyy    8    

Повышенная нагрузка на диски сервера баз данных SQL Server Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

С проблемой повышенной нагрузки на диски (дисковые хранилища и массивы, далее просто диски), сталкиваются почти все администраторы и специалисты технической поддержки при эксплуатации средних и крупных информационных систем на базе SQL Server (от 50 активных пользовательских сессий). Но всегда ли правильно идет интерпретация проблемы, попробуем разобраться на нескольких практических примерах.

15.03.2015    45041    gallam99    17    

Соединение вложенными циклами

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Nested loops и отсутствующие индексы. Статья написана по мотивам вебинара Виктора Богачева.

12.03.2021    3507    vasilev2015    22    

Негативное влияние большого количества ролей на производительность 1С

Производительность и оптимизация (HighLoad) Роли и права 8.3.14 ERP2 Россия Бесплатно (free)

Столкнулись с интересной проблемой во время работ с базой ERP. Первоначально проблема была в том, что один дописанный функционал работал слишком медленно и требовалось понять почему , однако вскоре выяснилась любопытная деталь – скорость выполнения операции под разными пользователями отличалась.

10.03.2021    3900    aviconsult    21    

Использование системы мониторинга Zabbix с 1С для мониторинга ключевых показателей бизнеса

Zabbix Бесплатно (free)

Мониторинг бизнес-показателей в базе 1С помогает руководителям оперативно принимать решения, реагировать на сбои, видеть реальное состояние каждого из этапов бизнес-процесса. О том, как использовать Zabbix для построения дашбордов и мониторинга ключевых показателей бизнеса, на митапе Infostart Saint Petersburg.Online рассказал Алексей Орловский.

17.02.2021    6602    orlovskiy-a    0    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    69002    yuraos    112    

Highload-оптимизация 1С: теория и практика на примере консолидированной отчетности группы "Магнит" и розничной аптечной сети "Магнит"

Производительность и оптимизация (HighLoad) BigData v8 Бесплатно (free)

Тема оптимизации 1С на больших данных бесконечная и всеобъемлющая, поскольку на производительность влияет целый ряд факторов – количество пользователей, данных, транзакций, неоптимальные запросы и т.д. Об инструментах для локализации проблем производительности и практических кейсах оптимизации рассказал Алексей Олейник, руководитель сектора автоматизации отчетности МСФО компании «Информационные технологии Магнит».

11.01.2021    26097    user662404_itlexusss    14    

Анализ блокировок СУБД: таблица изменений плана обмена 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Практический пример анализа типичной проблемы ожидания на блокировках СУБД, возникающих при использовании планов обмена 1С. Сервер СУБД: Microsoft SQL Server.

18.12.2020    3347    zhichkin    7    

Контекст всегда важен. История проблем производительности

Производительность и оптимизация (HighLoad) Бесплатно (free)

Небольшая история о проблемах производительности из-за нехватки процессорных мощностей. А также описание основных показателей работы CPU.

26.11.2020    7410    YPermitin    21    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

Не секрет, что многие пользователи, использующие партионный учет (а таких очень много, даже среди огромных холдингов, несмотря на пропаганду РАУЗ) при больших нагрузках сталкиваются с резким замедлением списания партий.

21.06.2013    59082    Антон Ширяев    117    

Анализ проблем производительности по динамике мониторинга RAS 1C

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

07.10.2020    4792    ivanov660    13    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

Производительность и оптимизация (HighLoad) v8 ДО Бесплатно (free)

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    5308    Nykyanen    16    

Описание почти всех событий технологического журнала

Технологический журнал v8 Бесплатно (free)

Краткое описание событий технологического журнала с примерами. Все для быстрого старта.

19.08.2020    28440    YPermitin    38    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    61208    Gilev.Vyacheslav    46    

Адаптация автоматической классификации ошибок технологического журнала при появлении новых текстов и типов

Технологический журнал v8 1cv8.cf Бесплатно (free)

Корректируем классификацию ошибок ТЖ в процессе работы для конфигурации мониторинг производительности

17.08.2020    914    ivanov660    0    

Нестандартные блокировки при работе с OLAP-нагрузкой

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    2689    Филин    7    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

В статье обсудим пример практической настройки конфигурации «Мониторинг производительности» для автоматической классификации ошибок по группам/кластерам на данных текстов описания ошибок. Используем механизм векторной модели текстов и косинусное сходство между ними.

25.06.2020    4354    ivanov660    13    

Параллельные вычисления в 1С 8 Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    37558    gallam99    19    

Выбор процессора для 1С: конец споров или начало?

Производительность и оптимизация (HighLoad) Бесплатно (free)

Периодически занимаясь исследованиями производительности я повидал много решений. Делюсь некоторыми выводами на основании теста Гилева и собственных мыслей.

25.05.2020    26510    starik-2005    248    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

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

24.05.2020    11195    DataReducer    22    

[SQL Server] Использование trace flag 9592 для сжатия траффика в кластере AlwaysOn

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

18.05.2020    2644    Aleksey.Bochkov    4    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    45313    madmpro    32    

Учимся готовить кроликов с редиской: опыт применения Rabbit MQ и Redis в интеграционных проектах

Производительность и оптимизация (HighLoad) Интеграция Бесплатно (free)

При построении мощных производительных отказоустойчивых решений для интеграции во всем мире активно используются технологии обработки очередей сообщений с помощью брокера RabbitMQ и кэш-сервера Redis. О практическом опыте использования этих технологий при построении ИТ-ландшафта, включающего системы на 1С, на конференции Infostart Event 2019 Inception рассказал Сергей Наумов.

12.05.2020    9099    SergeyN    3    

Ок, Лариса! Мониторинг проблем производительности с применением нейронных сетей

Производительность и оптимизация (HighLoad) Бесплатно (free)

Проводить мониторинг производительности вручную, выявляя закономерности в куче графиков и десятках таблиц, довольно сложно. Но это не значит, что разбираться с инцидентами нужно только после жалоб от пользователей. О том, как обучить нейронную сеть и заставить ее оповещать о проблемах, на конференции Infostart Event 2019 Inception рассказал начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков.

27.04.2020    5103    ivanov660    5    

Замеры APDEX против "ощущений" бухгалтеров

Автоматизация ИТ-компании APDEX Бесплатно (free)

Очень часто пользователи недовольны, как работает информационная система. Но даже когда ИТ-специалисты все полностью меняют, пользователи остаются недовольными. О том, как объективно оценить проведенные изменения, на конференции Infostart Event 2019 Inception рассказал руководитель ИТ-службы ИООО «Лукойл Белоруссия» Роман Жульпо.

24.04.2020    4808    it-boy    19    

Пример поиска ошибок в технологическом журнале

Технологический журнал Производительность и оптимизация (HighLoad) Бесплатно (free)

Примеры bash - скриптов для поиска ошибок в технологическом журнале.

23.04.2020    4006    vasilev2015    7    

Фреймворк "Мониторинг производительности". Руководство пользователя

Производительность и оптимизация (HighLoad) Бесплатно (free)

Описание и руководство "Мониторинг производительности": краткое описание конфигурации, сборник из статей, примеров - собрано в одном файле.

21.04.2020    4877    ivanov660    3    

Эти занимательные временные таблицы

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    16087    YPermitin    0    

Оптимизация запросов 1С посредством индексации временных таблиц. Миф? Тестируем, смотрим, считаем

Производительность и оптимизация (HighLoad) Практика программирования v8 Бесплатно (free)

Появилось свободное время, решил проверить на работе индексацию таблиц. Решил поделиться с Вами результатами исследования. Давайте порассуждаем на эту тему? Часто ли вы пользуетесь индексацией в запросах? Платформа 8.3.16.1224

03.04.2020    8689    feva    15