Оптимизация 1С – Проблемы производительности
- Ограничения платформы «1С:Предприятие 8»
- Общие рекомендации по решению проблем производительности
- Возможности масштабирования платформы 1С
Любая компания стремится к росту, развитию и расширению, вследствие чего увеличиваются требования к скорости работы информационной системы. База, которая ранее легко справлялась с нагрузкой, с течением времени может перестать соответствовать запросам компании.
Нередки случаи, когда скорость работы системы постепенно замедляется, или же в один из дней без видимых причин некоторые операции начинают работать очень медленно или нестабильно. И это не «глюки» платформы, это типичные проблемы производительности.
В таких ситуациях обычно начинается поиск «виноватого», к сожалению, через этот этап проходит большинство IT-отделов. Если, к примеру, еще вчера система работала нормально, то подозрение ложится на системных администраторов – «они опять что-то сделали с сервером». Этот вариант хоть и не исключен, но администраторы виноваты далеко не всегда.
Далее, как правило, вместо детального анализа причины замедления начинаются поиски «волшебной таблетки», которая решит все проблемы разом. Программисты просматривают форумы и перебирают бесконечное число вариантов настройки системы. Администраторы ищут решение в покупке более мощного сервера и т.д.
В итоге, потеряв уйму времени, лишь немногие приходят к правильному решению – начать постепенный анализ проблемы для выявления причины ее возникновения самостоятельно, либо нанять 1С:Эксперта.
Ограничения платформы 1С
Довольно распространено мнение, что «1С:Предприятие» – система исключительно для малого и среднего бизнеса, и она в принципе не способна справиться с системами на сотни и тысячи пользователей. Но это применимо только к 1С версиям 7.7 и 8.0, они довольно плохо масштабировались, их архитектура не предназначалась для больших систем, а возможность параллельной работы пользователей была сильно ограничена.
Но ситуация кардинально изменилась с приходом 8.1. В ней и в последующих версиях появились такие возможности как масштабирование, управляемый режим блокировкой данных, временные таблицы, изменилась структура таблиц на уровне СУБД для увеличения параллельности работы пользователей и многое другое.
На данный момент существуют 1С базы, в которых тысячи пользователей работают одновременно, причем в режиме 24/7.
Таким образом, сейчас на базе 1С возможно строить информационные системы практически любого масштаба. Платформа не имеет каких-либо ограничений, и масштабирование возможно до необходимого вам уровня.
Но теперь появилась другая проблема – люди не успевают за технологиями.
Ограничения при разработке
Разработчики конфигураций привыкли писать код «по старинке», не учитывая высокую нагрузку базы, большое количество параллельно работающих в ней пользователей. Решения не тестируются под нагрузкой, а разработка ведется на тестовых базах, далеких от рабочих и по составу, и по объему.
Складывается ошибочное убеждение, что код работает быстро, ведь никто не учитывает тот факт, что разработка ведется на базе, которая в десятки раз меньше рабочей.
Не стоит забывать и о том, что через несколько лет компания станет больше, и нагрузка на систему сильно возрастет. Безобидный запрос в цикле, наспех написанный «лишь бы успеть сдать проект в срок», в будущем может привести к серьезным проблемам со скоростью, блокировками и перегрузке дисковой подсистемы сервера СУБД, что отразится на работе всех баз.
К тому же разработчики конфигураций зачастую не используют (а иногда не знают, как использовать) новые механизмы платформы для повышения параллельности работы системы –управляемый режим блокировок и режим разделения итогов. Их правильное использование может существенно повысить пропускную способность практически любой конфигурации.
Практика показывает, что 90% проблем с производительностью – результат ошибок в коде конфигурации либо методологических ошибок, то есть виновато не железо, не СУБД и не платформа. Обычно все дело в прикладном коде. Это также относится и к коду типовых конфигураций, в которых нередки ошибки и неоптимальные участки.
Напрашивается вывод: если большинство проблем вызвано кодом 1С, то нужно исправить этот код. Необходимо только найти конкретное место в коде, которое приводит к замедлению, выяснить причину и устранить ее.
PDF-версия статьи для участников группы ВКонтакте
Мы ведем группу ВКонтакте – http://vk.com/kursypo1c.
Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.
Статья в PDF-форматеВы можете скачать эту статью в формате PDF по следующей ссылке: Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)
«Ускорение и оптимизация систем на 1С:Предприятие 8.3 (2016). Подготовка на 1С:Эксперт по технологическим вопросам»
Содержание курса и форма заказа: https://курсы-по-1с.рф/1c-v8/optimization/
35 учебных часов, подготовка к 1С:Эксперт, правильная настройка серверной части, оптимизация кода, мониторинг загруженности оборудования и прочие взрослые вещи.
Полностью согласен, что большинство проблем лежит в коде.
Но, во-первых, ценность системы во многом определяется насколько легко она позволяет писать такой кривой код и какие штатные средства она предоставляет для его отладки.
Те же “запросы через точку”, “запросы в цикле”, “полезность функции ВЫРАЗИТЬ в запросе для составных данных” и т.п. – неужели IDE не в состоянии сообщать про потенциально проблемный код и давать какие-то хинты?
А чем заменить элементарные юнит-тесты?
Во-вторых, в статье по производительность системы, присоединяюсь, хотелось бы все же прочитать нечто полезное.
Как пример, могу привести то, чем довольно часто делится уважаемый мной Евгений Гилев в своих общедоступных статьях на сайте.
Больше конкретики есть в других статьях, она у меня тут не одна :)
Спасибо, понял, буду искать.
А как объяснить безумные тормоза при отрисовке интерфейса в УФ? Или первый запуск УТ, когда кэширование длится нереально много времени? И невозможность никак настроить динамический список, который всегда будет тормозить при просмотре большого количества записей?
Здравствуйте, Андрей!
С каждой проблемой надо разбираться отдельно. УФ может открываться медленно по разным причинам, не исключены, конечно, и ошибки платформы, но это случается реже, чем ошибки программистов. В динамических списках так же чаще всего допускают ошибки именно программисты, пишут слишком сложные запросы, делают обращение через несколько точек и т.д. Часто динамические списки используют в роли отчетов, возвращая огромное количество полей и делая сложные условия.
Вот пара примеров, где после грамотной настройки и “выпрямления” кода в базе работают тысячи пользователей:
http://v8.1c.ru/expert/cts/cts-202-010.htm
http://v8.1c.ru/expert/cts/cts-218-001.htm
Прошу прощения за критику, но то что написано в статье можно было записать в одном предложении “1С хорошая платформа, в ней все хорошо, если у вас проблемы, научитесь их решать или позовите эксперта 1С, у платформы проблем нет, они есть у вас”.
Можно придраться ко многим предложениям в этом тексте, но возможно я просто не понял что хотел сказать автор своим материалом. На этом ресурсе(http://курсы-по-1с.рф) и в этой статье я ожидал увидеть, как минимум какой-то обзор типичных проблем с производительностью 1С и какие механизмы реализованные в платформе, помогают решать эти проблемы, возможно очень кратко, но чтобы после прочтения, можно было верить, что на многие проблемы с производительностью базы 1С, в платформе 1С есть механизм для обработки подобных ситуаций, нужно просто знать когда его использовать.
Еще одно большое замечание, если хотите обратить внимание на проблемы с производительностью то, пожалуйста, расшифровывайте, что имеется ввиду под фразой “На данный момент существуют 1С базы, в которых тысячи пользователей работают одновременно, причем в режиме 24/7”. Какие требования накладываются на эти базы? Какие объемы базы? Какие приимущественно операции совершаются с этими базами? Не надо громких высказивыний. Я видел адаптированные решения сделанные на уровне СУБД, в которой механизмы внешней интеграции с другими системами, собственный тонкий GUI, Web-gui , и даже проблемы с производительностью решались через написание низкоуровневых plugin’ов. Боюсь нельзя считать наличие этих костылей, заслугой СУБД на которой базируется решение.
Я, к несчастью, не верю что в платформе 1С нет проблем с масштабируемостью. В частности для меня критичен вопрос с изменением конфигурации в которой работают тысячи пользователей и которая работает в режиме 24/7. Необходимость выделения технологического окна является проблемой масштабируемости 1С или нет? Как сильно падает ли производительность и стабильность системы при динамическом обновлении и фоновой реструктаризации? Можно отнести эти вопросы к вопросам о производительности 1С? По-моему да, это не относится к производительности конфигурации, если производительность считать в попугаях в пиковые моменты, но это относится к общей производительности системы 24/7, на которую, как вы сказали может претендовать платформа 1С имеющимися механизмами масштабирования.
P.S. Прошу прощения, если был в чем-то неконструктивен или предъявил притензии, которые к обсуждаемой теме не относятся, делал это из благих побуждений, чтобы помочь улучшить текст. Я ожидал, что статья наведет некоторый порядок в моей голове, но пока этого не получилось.
Добрый день, Виталий!
Спасибо за критику. Учтем в будущих статьях.
Вот несколько примеров, когда базы работают без костылей под высокой нагрузкой:
http://v8.1c.ru/expert/cts/cts-202-010.htm
http://v8.1c.ru/expert/cts/cts-218-001.htm
http://v8.1c.ru/expert/cts/cts-123-001.htm
А как провести аналогию с такси, когда сеанс завершен, а соединения продолжают висеть. )
Пассажир выпал из такси по дороге, а такси продолжает ехать до дому?
Здравствуйте, Евгения!
Не понятен Ваш вопрос. Имеется ввиду ситуация когда сеанс завершен, а соединение просто зависло?
Если так, то это нештатная ситуация.
Если Вам нравиться аналогия, то это будет похоже на ситуацию, когда такси доставило пассажира по адресу, пассажир вышел и такси сломалось :)
Честно говоря статья ни о чем. Есть 1с, есть проблемы производительности в ней, есть кривой код и …?
Здравствуйте, Дмитрий!
Смысл статьи в том, что большая часть проблем производительности именно в коде.
Есть большое количество людей, которые думают, что проблемы в железе или в платформе или в том что Меркурий сегодня в Козероге и т.д.
Мы же пытаемся донести мысль, что большую часть проблем можно решить кодом и грамотной настройкой.
Согласен. Статья ни о чем. После прочтения нет желания покупать курс из-за опасения, что и в нем будет аналогичная “ниочемная” информация
Добрый день, Михаил!
Как выше упоминали – это статья общая, она не нацелена решить Вашу проблему.
На сайте были опубликованы и другие статьи автора, а самое главное – видео из тренинга.
Логично именно по этим материалам делать выводы.
А то получается – “Я не буду покупать курс, потому что автор пьет латте. А я люблю пуэр…”.
Впрочем дальнейшая дискуссия бессмысленна – набор на тренинг уже закрыт.