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

Публикация № 1228165 24.04.20

Администрирование БД - HighLoad оптимизация

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

Предисловие

 

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

Основная платформа автоматизации – 1С, основные учетные функции реализованы в конфигурации «Управление производственным предприятием». Но сразу сделаю поправку – сами заправки работают на автономных кассовых решениях, с 1С не связанных. Это для понимания, почему мы могли или не могли делать определенные вещи.

Мой доклад о том, как мы трансформировали нашу информационную систему из состояния «А» в состояние «Б». Я не так давно работаю в компании – с конца 2017 года, и вместе со мной обновилась ИТ-команда. Поэтому на многие вопросы, например, почему информационная система находилась в состоянии «А», я не смогу ответить. Мы даже для себя выработали шутливый паттерн «исторически так сложилось». Я думаю, многие бывают в такой ситуации, когда у вас «исторически так сложилось»: что-то построено и работает не так, как вам хотелось бы, или это не удовлетворяет бизнес сегодня.

На предприятии работает 1 300 человек, из них около 350 – активные пользователи информационной системы, в частности системы УПП. И прямо в воздухе витала общая неудовлетворенность работой системы – УПП работала медленно и не очень стабильно. И хотя все это знали, почему-то очень длительный период ничего по этому поводу не предпринималось.

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

 

О системе

 

 

Я как математик по образованию люблю формализовать задачи, формулировать требования и то, что у нас есть. Поэтому первое, что мы сделали, – записали «Дано на август 2018 года»:

  • сильно кастомизированная УПП на платформе 8.1;
  • база данных в MS SQL 2008 размером 1.2 ТВ с ошибками логической целостности (CHECKDB не проходит);
  • сервер 1С и SQL на разных виртуальных машинах в кластере VmWare;
  • около 300 активных пользователей, которые постоянно работают в базе в режиме 12х7. Тут стоит оговориться, режим многих распределенных объектов 24х7, но мы договорились, что бизнес-критичное время – это 12 часов, с 7 утра до 7 вечера. В это время база должна работать стабильно, и мы не можем вмешиваться в работоспособность, если только не появились какие-то критические вещи;
  • 2 специалиста 1С – сильный разработчик и сильный аналитик-консультант. Эти ребята пришли в компанию вместе со мной, мы с ними работаем давно, поэтому в их компетентности я не сомневался и делал на них очень большую ставку.

Проблематика – все работает медленно и периодически падает. Это классическая проблема.

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

Но иногда руководителям трудно объяснить, что происходит в ИТ, поэтому приходится импровизировать, придумывать какие-то аналогии. Мне в этом часто помогает визуализация.

 

 

Вот реальная картинка общего состояния нашей информационной системы в состоянии «А».

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

С этого и начинали.

 

 

Отдельно стоит отметить, что мы сначала построили, а потом уже сделали этот доклад. Поэтому какие-то вещи вносились уже постфактум.

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

Я могу предположить, что первые два пункта этого списка появились после работы с франчайзи или с внутренними ИТ-специалистами.

  • Первое, на что ссылались, – слишком большая база, поэтому все тормозит.
  • Второе – классический тезис – старые медленные сервера, их надо менять, поэтому все тормозит.
  • Особо негативно настроенные пользователи, люди, у которых сложился негативный опыт, говорили, что 1С не может работать быстро, нужно внедрять SAP. Сами понимаете, Лукойл – компания достаточно большая, и ресурсы позволяют. Поэтому было движение, подталкивающее к внедрению другой системы.

 

 

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

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

 

Этап первый – железо

 

 

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

Поэтому мы разобрали виртуальный кластер, выделили из него достаточно мощный физический сервер, на нем установили операционную систему, сервер 1С и SQL. Сделали все настройки по Best Practices – Shared Memory, разнесли лог и файлы базы данных по разным дискам, и т.п. Все, что можно было выжать из этого железа, сделали. И в принципе, больших просадок по производительности в мониторе ресурсов не было. Но отдельно скажу, что железо было старое, 2011 года, и SSD там не было. Поэтому в пике по очереди к дискам могли быть большие задержки.

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

Как мы это решили? Я прекрасно понимал, что самостоятельно с этой задачей мы не справимся, поэтому нужно искать специалистов. У меня были хорошие контакты с ребятами из команды gilev.ru – в 2015 году я у них учился на курсе по оптимизации производительности. Мы с ними пообщались, и они сказали, что возьмутся за решение нашей проблемы. Основной фактор, по которому мы выбрали именно этих ребят, – это фиксированная стоимость услуг и понимание уровня компетенций специалистов. У них на сайте есть прайс, где можно увидеть, сколько реально стоит та или иная операция. Когда мы пробовали обращаться или консультироваться с фирмами-франчайзи у нас на локальном рынке, нам сначала предлагали провести аудит за много денег и никто не мог назвать сразу ни конкретные сроки, ни сумму, ни то, что получится в результате. А Дмитрий Юхтимовский из команды gilev.ru достаточно быстро нам определил стоимость для ожидаемого результата.

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

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

Но были и два позитивных результата:

  • Первый – для меня было очень хорошо то, что база после обрезки начала проходить check database. То есть проблема была именно в тех данных, которые мы в конечном итоге отрезали, и головная боль, как вылечить базу, пропала.
  • Во-вторых, объем базы сократился примерно до 400 гигабайт. Это сильно упростило развертывание тестовых баз, сильно сократило время на регламенты и высвободило необходимые ресурсы.

Чтобы полностью завершить первый этап и развеять мифы о том, что все работает плохо из-за старых серверов 2011 года, мы в январе 2019 купили новые сервера. Там все сделали по рекомендациям ИТС или gilev.ru – SSD-диски, разделенные mdf- и lgf-файлы, много оперативной памяти и т.д.

 

 

Подытожу первый этап:

  • После того, как мы переехали на новый сервер и свернули базу, мои коллеги (администраторы, разработчики 1С) заметили, что база стала работать чуть стабильнее, стали быстрее выполняться какие-то регламентные операции.
  • Но как вы думаете, что сказали пользователи? Они сказали, что стало хуже и мы вообще зря на все это время тратили вместо того, чтобы сделать еще один отчет. Чтобы объяснить им, что произошло, мне опять пришла на помощь визуализация, я показал им такую картинку – автобус остался примерно тот же, но из него убрали лишнюю гармошку, покрасили, поставили новый двигатель. Но это остался тот же автобус, на той же платформе, на том же шасси. Стало комфортнее, но это не то, к чему мы стремились, и не то, ради чего все затевалась.

Если подводить итог, то первый этап был необходимым условием, но недостаточным.

 

Инструменты оптимизации

 

 

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

В качестве инструментов мы выбрали:

  • Корпоративную подписку на сервис gilev.ru – это не реклама, мы ими действительно пользуемся до сих пор. На конференции много рассказывали про ЦКК, другие сервисы 1С, но для нас оказалось удобнее и эффективнее использовать именно сервисы gilev.ru. Многие из них бесплатные, но некоторые, которые входят в корпоративную подписку, дополнительно еще настраиваются и поддерживаются со стороны команды gilev.ru. В подписку входят такие сервисы, как:
    • сервис производительности Apdex;
    • сервис анализа логов технологического журнала;
    • анализ долгих запросов;
    • анализ состояния SQL базы;
    • контроль загруженности оборудования;
    • контроль взаимоблокировок – все то, чем нам только предстояло заняться и с чем работать.
  • Отдельно рекомендую курс по оптимизации производительности Андрея Бурмистрова. Мне удалось лично побывать на многих курсах по оптимизации производительности, в том числе от 1С, но это были курсы именно администрирования. А для своих специалистов, на которых упала эта задача, мы приобрели удаленный курс Андрея Бурмистрова – очень подробный хороший курс, который описывает на уровне понимания, что нужно сделать. В частности, он является одним из этапов подготовки к сертификату 1С:Эксперт. Очень рекомендую.
  • И еще один административный инструмент – мы договорились с генеральным директором на полгода наложить запрет на доработки конфигурации информационной системы. И хотя стек доработок очень большой, очень много функциональности, мне удалось объяснить и доказать, что на непрочном фундаменте нельзя достраивать этажи, нельзя развивать конфигурацию, потому что в конечном итоге все точно упадет, и риск потерять данные будет слишком большой – в этом случае простои будут очень большие.

 

Замеры производительности

 

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

 

 

Представление APDEX мы выбрали именно в таком виде – это скриншот сервиса gilev.ru.

Общее, что нужно понять с этой картинки, – красные области на этом графике отмечают, что по основным пунктам состояние работы системы неудовлетворительное.

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

Видно, что общая оценка производительности системы плохая. Мы четко можем констатировать, что проблема есть, она реальная, вопрос «работает / не работает» не стоит, но чтобы исправить эту ситуацию, нужно, как сказал наш президент, «раздеваться и работать».

 

Второй этап – платформа

 

 

На следующем этапе нам нужно было перевести базу УПП на новую платформу 1С.

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

  • Мы  самостоятельно с помощью небольших манипуляций осуществили обновление платформы с 8.1 на 8.2. Сначала развернули тестовую базу и перевели для нее платформу. То, что вывалилось, сразу поправили самостоятельно. Потом сделали бета-тестирование: для этого разослали информационные письма и обзвонили ключевых руководителей с просьбой зайти в базу и совершить какие-нибудь свои классические операции (провести документ, сформировать отчеты), а если что-то не работает, прислать нам фидбэк, чтобы мы оперативно все исправили. Конечно же, в момент уже реального перехода появились новые ошибки, которые мешали работать, но они достаточно быстро были исправлены нашими программистами. Да, пришлось немного динамически обновить конфигурацию, но мы с этим справились.
  • Второй большой этап заключался в том, что мы перевели базу на управляемые блокировки. Сразу анонсирую, что эта вещь очень сильно влияет на производительность, имеет очень большой эффект и вклад в трансформацию состояния из неудовлетворительного в положительное. Речь про перевод старой конфигурации из режима неуправляемых (автоматических) блокировок, когда блокировками управляет SQL Server, в управляемый – когда вы управляете этим сами на уровне кода. Делали мы это не сами, потому что хорошего практического опыта у нас не было. Обратились к подрядчикам, к той же команде gilev.ru, они нам все достаточно быстро, в течение пары недель, реализовали. Это дало сразу большой скачок по APDEX.
  • На следующем этапе мы обновили платформу с 8.2 на 8.3.10, но без режима совместимости. Это тоже очень важно, потому что с 8.3.10 включается механизм версионирования на уровне SQL, что тоже сильно влияет на производительность, особенно на многопоточную обработку информации от различных пользователей.

 

 

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

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

А мы помним, что у нас есть APDEX, который дает объективную оценку нашей работе.

 

Третий этап – код

 

 

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

  • Проводились спецоперации по корректировке регистров. Мы выявили, что еще с 10-12 регистрами было что-то не так, потому что когда регистр накопления копит-копит-копит, и по нему нет ни одной расходной операции, он не схлопывается в ноль, а там миллионы каких-то записей – явно что-то не так на уровне кода. Также нашли много регистров сведений, которые накопили в себе под миллиард записей, но при этом ни разу нигде не использовались. Наверное, это были ошибки где-то на уровне архитектуры, или когда фирмы франчайзи для нас что-то делали, а потом что-то пошло не так. Такая точечная корректировка регистров позволила сократить объем базы на 100 гигабайт – еще около 100 гигабайт ненужных данных было вычищено из базы.
  • Мы провели оптимизацию кода запросов – это топ-уровень хороших разработчиков, которые не просто пишут код, но и могут разобраться в чужом и сделать это наиболее оптимально. Вручную это делать достаточно сложно, поэтому опять же, помогают сервисы, которые автоматически анализируют топ самых неэффективных запросов или запросов, которые больше всего занимают времени по базе данных. При этом любой запрос к базе данных – это, скорее всего, блокировки – взаимоблокировки или ожидание на блокировках. Мы проанализировали вручную и исправили порядка 15-20 запросов. Из самых вопиющих: запрос реестр накладных выполнялся на одних и тех же данных 220 секунд, а после оптимизации – 2 секунды, обработка печать ценников выполнялась 40 секунд, после оптимизации – 1 секунду. Таких примеров очень много, это, к сожалению, примеры непрофессионализма разработки или недостаточности знаний о работе платформы.
  • Тут мы вспомнили про удаление помеченных объектов. Напомню, что когда регламентные операции не работали, это все копилось, и в результате в базе оказалось около 2-2,5 миллионов помеченных объектов, не удаляемых типовыми средствами. Поэтому длительное время мы в ночные регламентные окна все эти помеченные объекты вычищали.

Стало еще лучше, людям во многом стало комфортнее.

 

 

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

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

 

 

На слайде показаны замеры APDEX на июль 2019 года. Здесь можно увидеть, что зеленого стало гораздо больше.

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

Если посмотреть по верхним пунктам, то самая важная для нас оптимизация – это документ «Реализация нефтепродуктов АЗС». Количество операций в неделю – 3503 операции, среднее время проведения – 2.9 секунды. До этого один документ проводился 15-20 секунд.

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

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

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

 

Четвертый этап – процессы

 

 

Запустив этот маховик, мы уже не остановились и перешли к самим бизнес-процессам.

  • Мы выяснили, что бухгалтеры формируют у нас в базе около 100-150 ручных операций в месяц. Ручные операции – это когда у людей есть доступ в регистры, они туда напрямую приходят и правят там какие-то данные. Зачем и почему – с этим предстояло разобраться. Отмечу, что большинство этих ручных операций было вызвано объективными причинами, потому что не существовало инструмента, который позволил бы отредактировать данные. Но оставшиеся операции делались просто потому, что «исторически так сложилось», так было удобнее – не корректировку сделать, а просто в регистр зайти напрямую и поправить. Все это приводило к потерям производительности, но уже не системы, а людей. В основном ручными операциями пользовались бухгалтеры – они корректировали, например, только бухгалтерский регистр, при этом их абсолютно не волновало, что происходит в управленческом учете. В итоге данные в бухгалтерском регистре и регистрах управленческого учета начинали расходиться: финансисты формируют отчет, у них одни цифры, а у бухгалтеров – другие. Поскольку решают, что правильно у бухгалтеров, финансист и экономист выгружают бухгалтерские ведомости к себе в Excel, крутят данные, делают какие-то отчеты, и все это мучительно вручную сводится. Для предприятия это было колоссальной потерей производительности целых подразделений, которые вынуждены постоянно перепроверять данные, делать сверки друг с другом. Поэтому мы взяли себе на вооружение и точечно в течение месяца-двух отстреливали все ручные операции, постепенно закрывая к ним доступ. На сегодняшний день этого уже нет.
  • Из этой первой проблемы вытекала вторая – финансисты не могли доверять управленческим регистрам по взаиморасчетам. Изначально, в попытках закостылить решения, которые были связаны с расхождением по регистрам, переписывались отчеты, чтобы брались данные для финансистов из бухгалтерских, а не из управленческих регистров – это все приводило к вакханалии. Поэтому мы переписали блок взаиморасчетов.
  • Заодно мы переписали блок учета основных средств и материалов. Это тоже многое дало для производительности.

 

 

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

 

Планы на будущее

 

 

Немного про планы на будущее:

  • Однозначно есть понимание, что нужно разделить базы на оперативную и аналитическую. Аналитическая база будет работать в режиме read only, в ней будут формироваться все необходимые отчеты, в том числе на 1С. Ее необходимо выделить отдельно, чтобы снять нагрузку с основной базы и более внимательно и в спокойном режиме заниматься аналитикой.
  • К этой read only базе мы планируем прикрутить BI аналитику. Не секрет, что хорошая аналитика – это не сильная сторона 1С, его сильная сторона – это учет и простота его ведения. А для аналитики я бы рекомендовал другие системы: Power BI, Qlik и т.д.
  • Третья задача, которую мы планируем реализовать, – это плотная связка 1С:Документооборота и ЭЦП, потому что очень много запросов приходит именно на внедрение электронного документооборота в части подписания документов электронной цифровой подписью. Изначально было представление, что это надо впихнуть куда-то в УПП. Но в итоге решили, что УПП хранит данные, там формируются проводки документов, потом из УПП формируется печатная форма необходимого документа, отправляется в 1С:Документооборот. Там она подписывается, становится юридически значимым документом, хранится и достаточно просто обеспечивается и хранение, и проверка целостности, и легальности данной подписи.

Надеюсь, мы все реализуем. И наконец-то наши пользователи будут довольны.

 

Вопросы

 

  • Очень интересно собирать статистику, смотреть, анализировать перформанс монитор – это вообще очень мощная штука. Я мало знаю людей, которые умеют этим заниматься.
  • Действительно, сервисы gilev.ru работают, технологический журнал анализируется, и это действительно круто. При этом мы практически на это не тратим время.
  • Роман, спасибо за доклад. Вы сказали, что пришли в 2017 году, когда еще были автоматические блокировки и так далее. А вы вообще УПП не обновляли никогда? Где регламентированная отчетность? Она в другой базе?
  • Белорусский рынок и белорусский 1С сильно отличается от российского. Надо понимать, что для Беларуси нет ни одной реально написанной конфигурации. Это все адаптация. Например, в России вышла УПП с российским учетом, в Беларуси какие-то компании ее адаптируют. Но представительства фирмы «1С» у нас нет, поэтому и регламентных типовых обновлений практически нет. Не говоря про то, что ИТС вообще не работает. ИТС нужен только для обновления платформы.
  • Понятно. Еще один маленький вопрос. У вас был road map – обновление платформы с 8.1 на 8.2, потом включили управляемые блокировки, потом перешли на 8.3. Это только обновили платформу или все-таки еще и режим совместимости конфигурации поменяли?
  • Я уже говорил, что делали обновление платформ со снятием режима совместимости. Мы его полностью выключали. Сейчас у нас конфигурация УПП работает на платформе 8.3.10 без режима совместимости в принципе.
  • Вопрос по теме доклада «Замеры APDEX против ощущений бухгалтеров» – как вы построили шкалу APDEX, если у вас, исходя из всего доклада, бухгалтера все равно были недовольны. Как вы выделили нижнюю и верхнюю границы?
  • При любых работах, связанных с оптимизацией производительности, какие-то метрики должны быть обязательно – APDEX либо любая другая. Потому что в процессе очень сложно отличить, изменилось вообще что-то, стало лучше что-то или нет. Да, бухгалтера были недовольны. Но как собирались метрики? Есть типовой набор, когда в метрики добавляются все документы и на них ставятся счетчики на проведение документа. Если я не ошибаюсь, эталон для проведения документа – 1-2 секунды в зависимости от нагруженности базы. Дополнительно мы провели опрос всех пользователей, бухгалтеров, что им еще не нравится. В опроснике мы спросили, за сколько времени определенный документ должен проводиться. По этим значениям мы настроили APDEX, выставили эталонное время и дальше по нему уже работали.
  • Получается, не было такого, что вам бухгалтера всегда говорили, что все плохо?!
  • Они всегда говорили, что все плохо, независимо от того, что показывает APDEX. Но нам важно было не бухгалтерам что-то доказать, нам важно было показать руководству состояние системы до и после изменений без субъективных оценок. Мы внедрили независимого свидетеля этой работы, и ни я не могу повлиять на эту методику, ни пользователи не могут на нее повлиять, ни даже наши разработчики этого не могут. Стоит добавить, что в процессе трансформации системы из состояния «А» в состояние «Б» были человеческие потери. У меня в ИТ-отделе были потери, с некоторыми людьми пришлось расставаться. С некоторыми бухгалтерами пришлось расстаться – особо критично настроенными. Это неизбежно. Но для компании это был положительный момент. Я ещё раз повторю – нашей задачей не было сделать всех бухгалтеров довольными, мы должны были сделать так, чтобы бизнес перестал терять время на медленной работе систем. Именно об этом мы договаривались с генеральным директором. Поэтому степень удовлетворенности пользователей – это важно, но все-таки более важно объективное состояние системы.
  • Но у вас тема доклада про APDEX, который касается удовлетворенности пользователей. А получается, что в данном случае это, скорее, удовлетворенность бизнеса.
  • APDEX показал отличную удовлетворенность. А то, что показывает APDEX, – это не то, что думает бухгалтер. Например, если бухгалтер согласился, что проведение документа за 5 секунд его устроит, сама операция занимает 2 секунды, но бухгалтер все равно недоволен, значит, он недоволен чем-то еще – стулом, компьютером, кабинетом. Но это уже не совсем про информационные системы.
  • Хочу уточнить такой момент: опрос пользователей, который вы делали на APDEX, проводился один раз, и потом вы по нему работали? Либо такие опросы проводились на постоянной основе?
  • Когда мы делали опрос, откликнулись, наверное, только 5% всех пользователей, большинство не дали конкретных ответов. Поэтому мы сознательно добавили в мониторинг APDEX по умолчанию все документы, которые есть в информационной системе. И еще добавили открытие форм, какие-то отчеты, на которые нам указали. У нас есть тикетная система, и если туда прилетает заявка о том, что у кого-то что-то медленно работает, мы этот объект добавляем в APDEX. Мониторинг работает постоянно – мы все его объекты для себя анализируем, а если еще и приходит запрос от пользователя, то мы точечно смотрим, что не так. Бывают моменты, когда выплывает что-то, что мешает нормальной работе системы.

 

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. mpeg1989 124 24.04.20 17:06 Сейчас в теме
С такими вводными просто любо-дорого работать. Тут не просто потенциал, а потенциалище! Железо я бы стал обновлять в самую последнюю очередь при таком раскладе.

1. Управляемые блокировки и 8.3. Простой пример - есть проведение документа, которое выполняется 20 секунд, но блокирует больше, чем нужно и 10 пользователей выстраиваются в очередь. Получаем 200 секунд ожидания. А скорее вылет по таймауту, если его не увеличили до космических значений. Ускоряем обработку, станет выполнятся за 5 секунд. Ожидания - 50 секунд, что больше психологического барьера в 20 секунд. А если просто убрать ожидание, то получаем, что у 10 пользователей ожидание 20 секунд, одновременно. А если одновременно не 10 пользователей, а 100, то выхлоп еще больше, даже если некоторые будут пересекаться в данных и ожидания все-таки будут. И вот на этом этапе узким местом станет как раз железо и пункт 2.

2. MS SQL 2016. Конкретно в 2016 добавилось столько приколюх по умолчанию, которые раньше через флаги трассировки включались.

А виртуализацию бесполезно убрали. 3-10% ничтожно, по сравнению с возможным выигрышем в несколько раз. Скорее даже десятков раз. А в некоторых операциях даже сотен раз.
3. it-boy 21 24.04.20 18:03 Сейчас в теме
(1) Да, работы было много. К сожалению, очень часто приходится сталкиваться полным непрофессионализмом в части проектов 1С, даже на достаточно крупных внедрениях. Сначала одни не думают про архитектуру решения, потом другие не знают, что с этим делать.

В части виртуалиазции - это было необходимо, так как и сама виртуализация была далеко не эталоном развертывания, но главное - это достаточно старая и медленная хранилка на медленных дисках и подключенная по 1 GB\s LAN. Поэтому гораздо эффективнее было разобрать такой кластер и приземлить все локально. Тем более объеденить сервер 1С и SQL для перехода на протокол Shared Memory.
4. 7o2uYXg 44 27.04.20 09:41 Сейчас в теме
(1) А можно ли пример операций или сценариев, где возможен выигрыш в несколько десятков, или даже сотен раз при использовании виртуализации?
9. mpeg1989 124 27.04.20 12:41 Сейчас в теме
(4) Видимо акценты не так расставил. Я имел ввиду, что выигрыш от ухода с виртуализации - 3-10%, выигрыш от разведения блокировок и оптимизации запросов - десятки и сотни раз. Поэтому единственное, для чего следует уходить с виртуализации - это доказать, что она не особо влияет либо криво настроена. Хотя в комментариях написали, что есть еще одна вполне себе адекватная причина перехода.
6. Terve!R 27.04.20 11:58 Сейчас в теме
(1)
Железо я бы стал обновлять в самую последнюю очередь при таком раскладе.

Железо в любом случае надо было обновлять, а такими вот установками, что железо хорошее, прошлая команда и отправилась ставить базы данных на HDD в бедные ларьки)
10. mpeg1989 124 27.04.20 12:44 Сейчас в теме
(6) Я же не написал, что железо огонь и менять его не надо. Сначала блокировки, разведение блокировок даст нагрузку на железо и вот тогда эффект будет уже ощутимым и не надо будет краснеть и что-то объяснять начальству и пользователям, которые не увидели эффекта.
2. пользователь 24.04.20 18:01
Сообщение было скрыто модератором.
...
5. adapter 403 27.04.20 11:54 Сейчас в теме
Интересная статья, редко встретишь реальный кейс на просторах.
Несколько замечаний. У вашего директора очень большое терпение. Видимо потому что команду ИТ сменили до вас, руководству уже некуда деваться, ребята взяли на себя удар )
Если бы прошлой команде дали большой бюджет и полгода на решение без доработок они бы и не уволились)

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

В итоге доработка кода дала самый ощутимый эффект
mpeg1989; Terve!R; +2 Ответить
13. it-boy 21 28.04.20 18:40 Сейчас в теме
(5) Спасибо за отзыв. Замечания принимаются ) На самом деле время доклада жестко ограниченно, поэтому подробно обо всем, что происходило фактически на протяжении года сложно вписать в 30 минут, да и я совсем не претендую на оригинальность или статуc "советчика". Вы правильно отметили, данная статья - это моя попытка рассказать реальный кейс о состоянии информационной системы и процессе оптимизации на достаточно крупном предприятии с определенными возможностями и бюджетом. Кейс из разряда "Богатые тоже тормозят" :-)
14. it-boy 21 28.04.20 18:52 Сейчас в теме
(5) Немного уточню:
команду уже менял я, к сожалению, предыдущие ребята не дотягивали по уровню задач, поддержку еще закрывать могли, но серьезные изменения с ними мы бы не вытянули.
Да и дело вроде как не в бюджете было, а бюджет на сторонние услуги был совсем скромным (в пределах 2-3 ЗП хорошего разработчика 1С). Мне кажется просто нужен был "свежий" взгляд и желание что-то изменить.
В конечном итоге, бизнес остался доволен, хотя, кроме картинок с автобусами, почти ничего не понял о проведенных изменениях. )))
Но, в общем положительный результат сложился из всех этапов, и было бы странно только оптимизировать код, но при этом оставить старое железо, платформу 8.1 и не закрыть ручные операции
user1279931; adapter; +2 Ответить
7. adapter 403 27.04.20 12:09 Сейчас в теме
по железу обсуждать не вижу смысла. Для этого должны быть замеры до\после - утилизация ресурсов, очереди дисков, страницы в процедурном кеше и многопоточное тестирование. Если есть ярко выраженное узкое место, то цена апгрейда. Просто так не глядя менять хорошее на новое можно если бюджет позволяет.
Я не конкретный кей
mpeg1989; +1 Ответить
15. it-boy 21 28.04.20 19:00 Сейчас в теме
(7) Основная причина замены железа - это срок эксплуатации серверов, на которых работает бизнес критичные сервисы, срок первышал номру в 5-7 лет. В 2018 году, базы 1С работали на серверах 2008-2011 года, и хотя после переконфигурации и тонкой настройки, действительно больших просадок по железу не было, мониторы ресурсов чистые и без больших задержек. Все-таки железо мы решили менять. Уже скорее по соображениям безопасности, чем производительности. И именно это я и объяснял генеральному, опять таки на примерах:
"Вот, вы свой мерседес 5-летний поменяли на новый, потому что если он сломается в дороге, будет дорого и неудобно. А если 7 летний сервер сломается, то будет еще дороже и еще неудобнее" ))
user1279931; +1 Ответить
8. adapter 403 27.04.20 12:13 Сейчас в теме
я не в конкретный кейс, а вообще скажу часто бывает так что это результат дуэли руководителей:
директор напал - "почему все не работает. Ты можешь что нибудь сделать" ?
айтишник отбился - железо старое, надо *млн
16. it-boy 21 28.04.20 19:02 Сейчас в теме
(8) У нас как раз обратная ситуация, деньги вроде были, но никак не могли "начать" и объяснить руководителю необходимости достаточно масштабных мероприятий на длительный период. Все хотели "волшебную" таблетку, сегодня деньги - завтра результат.
11. adapter 403 27.04.20 14:28 Сейчас в теме
apdex это интегральный показатель, как средняя температура по больнице. Провели документ в 10 строк - зеленый, в 10 000 - красный. Он конечно лучше чем ничего, но все на свете туда не запихнешь. Кто то отчет запустил самодельный без фильтров и повесил сервак - этого там не увидишь. Я например, писал еще один инструмент для замеров и мониторинга. Он тоже не полностью охватывает все кейсы, но как дополнение весьма хорош. Просто нельзя опираться только на apdex

Монитор кластеров серверов
https://infostart.ru/public/1197376/
17. it-boy 21 28.04.20 19:12 Сейчас в теме
(11) Полностью согласен с вами, на одном Apdex далеко не уедешь, это необходимый инструмент, но не достаточный. Мы пользовались целым набором серсов и анализом долгих запросов, и анализом Технологического журнала, и различными счетчиками производительности по разным выборкам, аудитом SQL сервера подробнее тут http://www.gilev.ru/korponline/

А вашу разработку обязательно посмотрим, как раз 10 стартмани завалялось )
12. SGordon1 27.04.20 20:17 Сейчас в теме
А точно эл документы можно через документооборот гонять? Важны же не только печатные, но и всякие цифровые формы , СФ, ЕГАИС, ИСМП..... Или у Вас нет таких букв?
18. it-boy 21 28.04.20 19:22 Сейчас в теме
(12) У нас действительно таких большинства таких букв нет ) Есть СФ (счета-фактуры если я правильно понял), и они как-раз летают через отдельный модуль-подсистему для УПП. В документооборот переносим сами формы документов в электронном виде, а данные остаются в УПП.
Например, отчет о реализации за смену на АЗС (отчет по кассе и магазину) - обязательный документ на 4-5 страниц, который раньше каждый день печатали на АЗС, подписывали и передавали в центральный офис.
Сейчас:
1.1. Передаются только данные из кассы в УПП
1.2. В УПП формируется необходимая печатная форма в электронном виде
1.3. Передается в документооборот
1.4. Менеджеру АЗС прилетает задача подписать документ
1.5. Менеджер локальной ЭЦП подписывает.
1.6. Электронный документ хранится в документооборот, данные в УПП.
user1279931; +1 Ответить
19. SGordon1 29.04.20 11:34 Сейчас в теме
(18) А товаром разве вместе с бензином не барыжите? У нас постоянно было лукойл то купит че то то вернет .....
Если готовые обмены подходят - то потом и какая нить обувь/ сигареты/ что там у вас заработает .....
20. it-boy 21 29.04.20 11:48 Сейчас в теме
(19) Конечно, на большинстве АЗС полноценный магазин с широким ассортиментом товаров. Но готовые обмены и типовые решения - это, к сожалению, не про Беларусь. В РБ с готовими и типовыми решениями в принципе, все плохо, а точнее их фактически нет.
Оставьте свое сообщение

См. также

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

HighLoad оптимизация Бесплатно (free)

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

26.04.2019    15804    Aleksey.Bochkov    8    

Нагрузочное тестирование в 1С:ERP

HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

02.11.2022    2298    Tavalik    23    

Битва параллелизмов: MS SQL vs PostgreSQL

HighLoad оптимизация Бесплатно (free)

Чем отличаются подходы в построении плана запросов для PostgreSQL и MS SQL? Какие запросы хорошо параллелятся, а какие нет? Кто в итоге круче в параллелизме – MS SQL или PostgreSQL? Вадим Фоминых протестировал обе СУБД на эффективность параллельной работы и рассказал о своих выводах в докладе на конференции Infostart Event 2021 Post-Apocalypse.

31.10.2022    5382    Shmell    4    

MS SQL Server: ваши статистики не работают! Так ли все плохо на самом деле?

HighLoad оптимизация Бесплатно (free)

Состояние и качество статистик критически важны для эффективной работы системы. Но у заметной части типовых конфигураций статистики просто не могут работать эффективно. О том, почему так происходит и что с этим делать, на конференции Infostart Event 2021 Post-Apocalypse рассказал Александр Денисов.

27.09.2022    1835    Филин    11    

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

HighLoad оптимизация Бесплатно (free)

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

29.07.2018    12802    Aleksey.Bochkov    9    

Быстрый фронт в базе размером 6.8 терабайт – наши стандарты при разработке и рефакторинге запросов

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

От быстродействия запросов, которые обращаются к крупным таблицам, напрямую зависит скорость работы всей базы в целом. Артем Кузнецов, тимлид команды 1С в компании ООО «Финтех решения» на конференции Infostart Event 2021 Moscow Premiere рассказал, как оптимизировать производительность при поддержке больших систем. Показал, на что следует обращать внимание при код-ревью запросов, как оптимизировать RLS, виртуальные таблицы, индексы и условия, и как доработка архитектуры решения может ускорить работу базы.

29.08.2022    4503    Chernazem    44    

Ускорим проведение в 1С:Управление холдингом

HighLoad оптимизация Запросы Платформа 1С v8.3 1С:Управление холдингом Бесплатно (free)

В 1С:Управление холдингом есть "нехороший" запрос, который съедает значительную часть времени проведения документов. Если его подправить, то проведение заметно ускорится.

10.08.2022    4404    sapervodichka    57    

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

HighLoad оптимизация Бесплатно (free)

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

05.08.2015    69846    Sergey.Noskov    119    

Миссия невыполнима. Общие реквизиты разделители против временных таблиц

HighLoad оптимизация Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

05.08.2022    1348    1CUnlimited    0    

Методика похудения для 1С – 100%

Свертка базы HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

28.07.2022    4774    1CUnlimited    37    

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

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

22.04.2015    46702    Gilev.Vyacheslav    1    

Экспертный кейс. История расследования одного небыстрого закрытия месяца в 1C:ERP. Пример неочевидных путей расследования в виде детективной истории

HighLoad оптимизация Механизмы платформы 1С Запросы Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

11.07.2022    4678    it-expertise    27    

10 «заповедей» эксплуатации крупной информационной системы 1С

Управление ИТ-подразделением Внедрение ИТ-системы HighLoad оптимизация Бесплатно (free)

Крупные системы 1С давно уже перешагнули и десятки терабайт, и тысячи пользователей, но во многих случаях подход к эксплуатации таких систем остаётся не на должном уровне. Антон Дорошкевич на конференции Infostart Event 2021 Post-Apocalypse поделился более чем 10-ти летним опытом эксплуатации подобных систем, сведя его к 10 «заповедям», соблюдение которых сделает 1С надёжнее, а труд разработчика – благодарнее и благороднее.

11.07.2022    6741    a.doroshkevich    33    

Производительный режим работы RLS

HighLoad оптимизация Роли и права Платформа 1С v8.3 8.3.14 8.3.6 8.3.8 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х Бесплатно (free)

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Каждый из режимов имеет свои преимущества и недостатки относительно другого. Основные из них будут рассмотрены в данном материале.

14.06.2022    4665    Neti    6    

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

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

16.09.2012    37169    Aleksey.Bochkov    29    

Любовь. Быстродействие. 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

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

26.05.2022    3524    vasilev2015    20    

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

HighLoad оптимизация Администрирование СУБД Платформа 1С v8.3 8.3.14 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

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

24.05.2022    3487    avolsed    15    

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

HighLoad оптимизация Бесплатно (free)

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

15.03.2015    48005    gallam99    17    

Заметки эксперта. Расследование длительного выполнения отчета “Движение ТМЦ и затрат в производстве” (1С:ERP 2)

HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Кратко: в ходе проведения нагрузочного тестирования “1С:ERP 2” под ОС Linux на СУБД Postgres выявлено существенное замедление формирования отчета “Движение ТМЦ и затрат в производстве” - до 60 минут. После проведенного расследования и точечной корректировки СКД в отчете, без изменения бизнес-логики результатов его работы, работа отчета была ускорена в 80 раз - средний показатель формирования составил 30 секунд.

19.05.2022    1926    it-expertise    19    

Нагрузочное тестирование 5000+ пользователей онлайн — играем в игру

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

Тестируем ERP под Postgre SQL. Альтернативный нагрузочный тест.

16.05.2022    6020    ivanov660    52    

Тестирование - игровое моделирование

HighLoad оптимизация Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Мы рассмотрим подход к тестированию с применением элементов искусственного интеллекта

25.04.2022    1274    ivanov660    0    

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

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

22.01.2014    71395    yuraos    112    

Анализ кода, потребляющего ресурсы СУБД MS SQL, контекстами 1С

HighLoad оптимизация Бесплатно (free)

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

21.04.2022    2004    pashamak    1    

Несколько слов про платформенный механизм оптимизации RLS

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Смотрим, как работает платформенный механизм оптимизации RLS, сравним поведение на разных СУБД MS SQL, Postgres 11,13,14.

07.04.2022    3341    ivanov660    23    

Почему после обновления Бухгалтерии в марте 2022 года отчеты стали такими медленными

HighLoad оптимизация Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

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

05.04.2022    4405    DBOdin_Lab    33    

Ускорение реструктуризации таблиц Промо

HighLoad оптимизация Бесплатно (free)

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

12.09.2013    54468    OLEG4120    32    

Экспертный кейс. Расследование фатального замедления времени расчета себестоимости в 1С:ERP 2

HighLoad оптимизация Механизмы типовых конфигураций Запросы Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

При выполнении нагрузочного тестирования информационной системы на базе 1С:ERP для одного из клиентов с целью оценки возможности миграции системы на PostgreSQL и Astra Linux мы столкнулись с неприемлемым увеличением времени выполнения расчета себестоимости. Строго говоря, сценарий тестирования закрытия месяца не был выполнен вообще – он не укладывался в таймаут выполнения теста, 24 часа. По прошествии 18 часов всё ещё шло выполнение операции «Распределение затрат и расчет себестоимости». Более 16 часов выполнялся подэтап “Расчет партий и себестоимости. Этап. Расчет себестоимости: РассчитатьСтоимость”. Всё это время выполнялся запрос, который в текущей инфраструктуре клиента (СУБД MS SQL Server) выполняется чуть более 3 минут на аналогичных данных.

25.03.2022    4785    it-expertise    92    

Экспертный кейс. Расследование деградации производительности системы. Проведение документа “Поступление товаров и услуг” (1С:ERP 2)

Механизмы платформы 1С Запросы HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

В ходе проведения нагрузочного тестирования одним из наших клиентов была выявлена сильная деградация производительности системы в целом и, в частности, выполнения ключевой операции “Проведение документа поступление товаров и услуг” в течение выполнения теста. Согласно данным подсистемы БСП “Оценка производительности”, время выполнения ключевой операции “Проведение документа поступление товаров и услуг” возрастало в процессе тестирования с 15-20 секунд в начале тестирования до 150-200 секунд в его финале.

02.03.2022    3574    it-expertise    47    

Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками

HighLoad оптимизация Технологический журнал Платформа 1С v8.3 Бесплатно (free)

Рассмотрим по шагам процесс обнаружения, анализа и решения проблемы производительности на примере базы ERP, сравним отличия в работе Postgres и MS SQL.

28.02.2022    10293    ivanov660    18    

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

HighLoad оптимизация Платформа 1С v8.3 1С:Управление торговлей 10 1С:Управление производственным предприятием Бесплатно (free)

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

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

Ускорение работы конфигуратора 1С с большими прикладными решениями

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Ускорение работы 1С конфигуратора с большими прикладными решениями путем размещения системных каталогов 1С на RAM диске.

13.01.2022    6602    stg2005    105    

AMD RYZEN 5600X: погоня за попугаями

HighLoad оптимизация Бесплатно (free)

Все по-взрослому...

08.12.2021    6117    starik-2005    256    

Ошибка производительности при проведении этапа 2.2 в ERP 2.4 и ERP 2.5

HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Хочется поделиться одним подводным камнем, с которым могут встретиться другие пользователи ERP. Искал решение в интернете, но ничего похожего не нашел. Поэтому решил создать эту тему.

06.12.2021    1548    Rokky78    6    

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

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

19.02.2013    62849    Gilev.Vyacheslav    46    

Инструкция по получению плана запроса через Extended Events

HighLoad оптимизация Бесплатно (free)

Доброго времени суток, коллеги. Хочу рассказать, как можно посмотреть план запроса через механизм Extended Events. Я хочу ответить на вопрос - как разработчику через SQL Management Studio посмотреть, что запрос, который он сделал, работает оптимально. На Инфостарте есть несколько статей, которые посвящены трассировкам в этом механизме. Мне, когда я не понимал, как это правильно делать, не хватало простой пошаговой инструкции. Я напишу инструкцию, выполняя которую можно будет увидеть план запроса, который выполняется из базы данных.

22.11.2021    2133    Andrei_Ivanov    3    

Подходы к организации информационной безопасности в корпоративных проектах

HighLoad оптимизация Государственные, бюджетные структуры 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

Оформили в виде статьи наш доклад на недавно прошедшем семинаре партнеров 1С на тему требований к информационной безопасности на проектах, с которыми всё чаще встречаемся мы и наши партнеры. В статье рассмотрено, почему этими вопросами стоит озаботиться уже сейчас. Куда бежать и что делать, если вы попали на проект с требованиями по информационной безопасности…

29.10.2021    4277    it-expertise    11    

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

WEB-интеграция HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

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

20.10.2021    3936    sorter1    2    

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

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

11.02.2013    38880    gallam99    19    

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

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

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

07.09.2021    11055    ivanov660    26    

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

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

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

18.08.2021    3707    vasilev2015    7    

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

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

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

18.08.2021    10687    FB_3393521717335803    2    

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

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

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

03.11.2012    46009    madmpro    32    

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

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

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

13.08.2021    11041    Shmell    8    

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

HighLoad оптимизация Бесплатно (free)

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

09.08.2021    4636    blackhole321    8    

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

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

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

02.08.2021    14281    ivanov660    77    

1С:Предприятие 7.7. Оптимизация. Промо

HighLoad оптимизация Платформа 1С v7.7 Конфигурации 1cv7 Россия Бесплатно (free)

Разгоняем 1С:Предприятие 7.7. Выжимаем последние соки.

31.01.2009    50936    alexk-is    110    

Fill factor

HighLoad оптимизация Бесплатно (free)

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

02.08.2021    3515    vasilev2015    6    

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

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

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

01.06.2021    14044    vasilev2015    17    

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

HighLoad оптимизация Платформа 1С v8.3 Управление блокировками Конфигурации 1cv8 Бесплатно (free)

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

28.04.2021    7574    vasilev2015    14    

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

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

22.04.2021    7005    a.doroshkevich    6