Что такое масштабируемость по рабочим местам в 1с

Опубликовано: 07.05.2025

Масштабируемость — это способность системы адаптироваться к расширению предъявляемых требований и возрастанию объемов решаемых задач. Система 1С:Предприятие 8 имеет хорошие возможности масштабирования. Она позволяет работать как в файловом варианте, так и с использованием технологии "клиент-сервер". В последнем случае используется современная трехуровневая архитектура, когда между клиентом и сервером баз данных (Microsoft SQL Server / IBM DB2 / PostgreSQL),располагается сервер 1С:Предприятия 8.

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

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

Трехуровневая архитектура "клиент-сервер"

Одним из наиболее существенных нововведений 1С:Предприятия 8 является реализация трехуровневой архитектуры "клиент-сервер". В 1С:Предприятии 7.7 в клиент-серверном варианте работы с информационной базой программа, работающая на компьютере пользователя, обращалась непосредственно к базе данных в среде MS SQL Server. В новой версии на одном из компьютеров работает сервер 1С:Предприятия 8. Программа, работающая у пользователя, взаимодействует с сервером 1С:Предприятия 8, а сервер при необходимости обращается к базе данных MS SQL Server. При этом физически сервер 1С:Предприятия 8 и MS SQL Server могут располагаться как на одном компьютере, так и на разных. Это позволяет администратору при необходимости распределять нагрузку между серверами.

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

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

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

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

Файловый вариант

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

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

Параллельность работы

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

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

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

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

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

Масштабируемость разработки

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

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

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

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

Факторы, влияющие на производительность программ 1C

На производительность программ 1с шказывает влияние целый спектр факторов. Основные из них:

Способ работы с информационной базой - клиент-серверный или файловый.

Число одновременно работающих пользователей. При работе одновременно до 11 пользователей – допустим файловый вариант работы, более 11 – клиент-серверный (PostgreSQL или MSSQLServer).

Объем информационной базы. При расширении информационной базы необходимо перейти на клиент-серверный способ работы. Кроме того, для увеличения производительности 1с рекомендуется применять дисковую подсистему на сервере информационной базы данных FC или SAS.

Пропускная способность локальной вычислительной сети. Необходимую производительность обеспечивает класс 100Mbit и выше.

Характеристики аппаратной части сервера и рабочего места пользователя.

Цели тестирования

Одной из задач, которые решались при разработке 1С:Предприятия 8.1, являлось повышение производительности и масштабируемости системы. При этом учитывался опыт использования 1С:Предприятия 8 на больших внедрениях и результаты многочисленных нагрузочных испытаний системы в различных режимах.

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

В частности, была проведена оптимизация:

Работы встроенного языка

Внутренней параллельности сервера 1С:Предприятия

Обмена данными между клиентом и сервером 1С:Предприятия

Алгоритмов записи движений документов

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

Настоящее тестирование 1c проводилось с целью оценки достигнутых показателей производительности и масштабируемости 1С:Предприятия 8.1 в различных условиях.

Были проведены следующие тесты:

Оценка производительности и масштабируемости системы при одновременной работе большого количества пользователей

Оценка производительности и масштабируемости системы при пиковых нагрузках

Оценка производительности на отдельных видах операций

Полученные показатели 1С:Предприятия 8.1 сравнивались с аналогичными показателями для 1С:Предприятия 8.

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

Общие результаты тестирования

1С:Предприятие 8.1 продемонстрировало значительное улучшение показателей производительности на всех проведенных тестах.

Тест

Улучшение
(раз)

Масштабируемость при работе большого количества пользователей

Общая пропускная способность системы

до 1.5

Масштабируемость при пиковых нагрузках

Общая пропускная способность системы

до 2.3

Время проведения документа

до 2.4

Масштабируемость в кластере при пиковых нагрузках

Общая пропускная способность системы

до 3.8

Время проведения документа

до 3.8

Показатели производительности на отдельных операциях

Запись и проведение документа

до 1.6

до 1.8

до 4

Объем занимаемой оперативной памяти

до 1.4

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

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

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

При заданных условиях тестирования 1С:Предприятие 8.1 продемонстрировало значительное улучшение показателей производительности и масштабируемости по сравнению с 1С:Предприятием 8. Так пропускная способность системы при одновременной работе 200 пользователей выросла почти в 1.5 раза, а время записи и проведения документа составило менее 3.5 секунд.

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

Условия тестирования

Тестирование проводилось на примере документа РеализацияТоваровУслуг типовой конфигурации УПП 1.2. При помощи 1С:ТестЦентра был описан многопользовательский сценарий тестирования со следующими параметрами:

• Количество одновременно работающих пользователей: от 1 до 200
• Выполняемая операция: создание и проведение нового документа РеализацияТоваровУслуг
• Количество строк в табличной части «Товары»: 20
• Каждый тестовый пользователь создает документы со своим уникальным набором товаров, то есть все движения документов записываются параллельно, не приводя к блокировкам.
• Количество строк в табличной части «Услуги»: 0
• Пользователи вводят документы с паузой 60 секунд
• Расчет себестоимости списываемых товаров не производится (в выбранном режиме используется механизм регламентного расчета себестоимости).

Следует отметить, что смоделированная нагрузка на систему значительно превышает нагрузку, которая наблюдается в реальных условиях. По результатам опроса обычный пользователь вводит в среднем 300 строк документа в час. В данном тесте при одновременной работе 200 пользователей на 1С:Предприятии 8.1 тестовый пользователь вводил 965 строк в час, то есть интенсивность его работы была выше в 3.2 раза.

Во время проведения документа система выполняла следующие действия:

• Движения по разделам управленческого учета:
  • Взаиморасчеты с контрагентами: увеличение фактической задолженности контрагента
  • Продажи: увеличение объема продаж по предприятию
  • Списание товара со склада предприятия с контролем достаточности остатка товаров
  • Снятие резерва, выполненного под заказ покупателя с контролем достаточности резерва
  • Списание товара принадлежащего организации с контролем достаточности остатка товаров
  • Расчеты с контрагентами: увеличение оперативной задолженности контрагента
  • Движения по регистрам подсистемы НДС
  • Формирование проводок по бухгалтерскому и налоговому учету:
    • По выручке (бухгалтерский и налоговый учет)
    • По НДС (бухгалтерский учет)
    • По взаиморасчетам (бухгалтерский учет)
    • По суммовым разницам (бухгалтерский и налоговый учет)
    • По курсовым разницам (бухгалтерский учет)

    При проведении тестирования измерялись следующие показатели производительности:

    • Фактическая пропускная способность системы – количество строк документов, обработанных системой в единицу времени.
    • Среднее время записи и проведения одного документа

    Тестирование проводилось на следующем тестовом стенде:

    • Сервер 1С:Предприятия:
      • Процессоры: 2 * Intel Xeon MP, 2800 МГц
      • Оперативная память: 4 096 Мб
      • Дисковая подсистема: 2 * Ultra320 SCSI RAID 0 (stripe)
      • Процессоры: 2 * DualCore Intel Xeon, 2666 МГц
      • Оперативная память: 8 192 Мб
      • Дисковая подсистема: 6 дисков в режиме Ultra320 SCSI RAID 0 (stripe)

      Результаты

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

      Рассмотрим диаграмму зависимости количества строк документов, обрабатываемых системой в единицу времени, от количества одновременно работающих тестовых пользователей для 1С:Предприятия 8 и 8.1:

      
      При одновременной работе 200 тестовых пользователей на данном тесте пропускная способность системы на платформе 1С:Предприятие 8.1 составила более 190 000 строк документов в час, что почти в 1.5 раза выше соответствующего показателя для 1С:Предприятия 8.

      1С:Предприятие 8.1 уверенно справляется с этой нагрузкой и не достигает предела общей пропускной способности при данных условиях тестирования. Система демонстрирует устойчивую тенденцию к дальнейшему росту общей пропускной способности при увеличении количества одновременно работающих пользователей.

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

      
      При увеличении количества одновременно работающих пользователей в 10 раз (с 20 до 200) относительная пропускная способность системы на платформе 1С:Предприятие 8.1 уменьшается всего на 4.6%. То есть, подключение к системе новых пользователей практически не отражается на общей производительности системы.

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

      Рассмотрим диаграмму зависимости среднего времени записи и проведения документа от количества одновременно работающих тестовых пользователей для 1С:Предприятия 8 и 8.1:

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

      Таким образом, 1С:Предприятие 8.1 демонстрирует значительно лучшую масштабируемость по сравнению с предыдущей версией на тесте с параллельным вводом документов большим количеством пользователей.

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

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

      В условиях пиковой нагрузки 1С:Предприятие 8.1 продемонстрировало значительное улучшение показателей производительности по сравнению с 1С:Предприятием 8. Пропускная способность системы выросла в 2.3 раза, а среднее время проведения одного документа сократилось в 2.4 раза.

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

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

      Условия тестирования

      Тестирование проводилось на примере документа РеализацияТоваровУслуг типовой конфигурации УПП 1.2. Параметры данного теста были идентичны предыдущему за следующими исключениями:

      • Количество одновременно работающих пользователей: 20
      • Пользователи вводят документы без паузы
      • Количество строк в табличной части «Товары»: 5

      Тестирование проводилось на следующем тестовом стенде:

      • Сервер 1С:Предприятия (для работы без кластера и для процесса 1 в кластере):
        • Процессор: DualCore Intel Xeon MP, 3000 МГц
        • Оперативная память: 8 192 Мб
        • Дисковая подсистема: 4 * Ultra320 SCSI RAID 0 (stripe)
        • Процессор: 2 * Intel Xeon MP, 2800 МГц
        • Оперативная память: 8 192 Мб
        • Дисковая подсистема: 8 * Ultra320 SCSI RAID 0 (stripe)
        • Процессоры: 2 * DualCore Intel Xeon, 2666 МГц
        • Оперативная память: 8 192 Мб
        • Дисковая подсистема: 6 дисков в режиме Ultra320 SCSI RAID 0 (stripe)

        Результаты

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

        Рассмотрим диаграмму фактической пропускной способности системы (строк документов в час) при использовании 1С:Предприятия 8, 1С:Предприятия 8.1 без использования кластера и 1С:Предприятия 8.1 с использованием кластера из 2 рабочих процессов.

        Масштабируемость — это способность системы адаптироваться к расширению предъявляемых требований и возрастанию объемов решаемых задач.

        Работа одного прикладного решения в разных условиях

        Система «1С:Предприятие 8» имеет хорошие возможности масштабирования. Она позволяет работать как в файловом варианте, так и с использованием технологии «клиент-сервер».

        
        

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

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

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

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

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

        Многопользовательская работа

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

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

        В модели данных, поддерживаемой системой «1С:Предприятие 8», не существует таблиц базы данных, однозначно приводящих к конкурентному доступу со стороны нескольких пользователей. Конкурентный доступ возникает только при обращении к логически связанным данным и не затрагивает данные, не связанные между собой с точки зрения предметной области.

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

        Механизмы оптимизации

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

        Управление блокировками в транзакции

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

        Выполнение на сервере

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

        Кэширование данных

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

        Работа встроенного языка на сервере

        При работе в клиент-серверном варианте вся работа прикладных объектов выполняется только на сервере. Функциональность форм и командного интерфейса также реализована на сервере.

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

        Аналогично командный интерфейс формируется на сервере и отображается на клиенте. Также и отчеты формируются полностью на сервере и отображаются на клиенте.

        Примеры технологических параметров внедрений решения «Управление производственным предприятием»

        В этом разделе публикуется развернутая информация о технологических параметрах внедрений «1C:Предприятие 8. Управление производственным предприятием» на предприятиях различного масштаба и профиля деятельности.

        Цель раздела — ознакомить ИТ- специалистов с данными о реально используемом оборудовании и с примерами нагрузки реальных внедрений «1С:Предприятия 8».

        Также эта информация может быть полезна и для пользователей всех программ системы «1С:Предприятие 8».

        1С:Центр управления производительностью — инструмент мониторинга и анализа производительности

        1С:Центр управления производительностью (1С:ЦУП) — инструмент мониторинга и анализа производительности информационных систем на платформе «1С:Предприятие 8». 1С:ЦУП предназначен для оценки производительности системы, сбора подробной технической информации об имеющихся проблемах производительности и анализа этой информации с целью дальнейшей оптимизации. Подробнее…

        1С:ТестЦентр — инструмент автоматизации нагрузочных испытаний

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

        Внедрение корпоративных информационных систем на платформе «1С:Предприятие 8»

        Опыт внедрения прикладных решений на платформе «1С:Предприятие 8» показывает, что система позволяет решать задачи различной степени сложности — от автоматизации одного рабочего места до создания информационных систем масштаба предприятия.

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

        База знаний по технологическим вопросам крупных внедрений

        Фирма «1С», совместно с сертифицированными «1С:Экспертами по технологическим вопросам» и другими техническими специалистами, ведет и регулярно обновляет базу знаний по технологическим вопросам крупных внедрений.

        Выпустив летом 2003 г. на рынок новую платформу “1С:Предприятие 8.0”, фирма “1С” перешла к решению важной для развития бизнеса задачи: расширению сферы применения своих прикладных решений за счет расширения их функциональности, производительности и масштабирования. Все это время наряду с появлением новых программных продуктов шло наращивание базовых функций и самой платформы, в силу чего постоянно существовал вопрос: справится ли ядро системы (в том числе заложенная в него архитектура) с растущим объемом навешенного на него прикладного ПО?

        Ответ на него был дан разработчиками “1С”, представившими на проходившей в конце февраля партнерской конференции результаты тестирования своего флагманского продукта “1С:Управление производственным предприятием” (1С:УПП).

        Рис. 1. Количество строк, обработанных за час системой 1С:УПП

        Напомним, что весьма представительное исследование “1С:Предприятия 8.0” на примере решения “Управление торговлей” на предмет масштабируемости и производительности было проведено фирмой “1С” еще в конце 2003 г. (см. PC Week/RE, № 9/2004, с. 44). Его задачей было показать преимущества архитектуры новой платформы перед ее предыдущей версией 7.7 в условиях увеличения запросов на обработку документов. На этот раз цель была гораздо скромнее — подтвердить возможность масштабируемости многофункционального решения 1С:УПП при одновременной работе большого количества пользователей.

        Рис. 2. Среднее время записи и проведения одного документа

        Исследование выполнялось на примере операций, наиболее критичных с точки зрения нагрузки на вычислительную систему, и с параметрами, типичными для большинства организаций-заказчиков. Использовался клиент-серверный вариант 1С:УПП, в соответствии с которым серверы “1С:Предприятия” и базы данных были установлены на разных компьютерах. Работа пользователей (от 1 до 150 человек) — запись и проведение документа — эмулировалась программным образом; причем автомат между вводом документов делал паузу в 60 с. Но несмотря на это интенсивность ввода информации все равно была в несколько раз выше по сравнению с реальными условиями.

        Тестирование проводилось для документов различного объема — 5, 20 и 40 строк, а также для двух разных степеней конкурентности номенклатуры во вводимых данных: когда наборы товаров у тестовых пользователей вообще не пересекаются и когда они совпадают в каждом четвертом случае.

        Анализ представленных результатов показал следующее.

        1. В максимальном тестовом варианте при одновременной работе 150 пользователей (для документов объемом 40 строк) система обрабатывала более 300 тысяч вводимых строк в час (рис. 1). Однако это еще далеко не предел возможностей решения по нагрузке.

        2. Объем обрабатываемой информации рос практически прямо пропорционально увеличению входной нагрузки (количества одновременно работающих пользователей), при этом объем обработанных документов (в среднем 8 тыс. в час) практически не зависит от размера каждого документа. Характер зависимости говорит о том, что система справляется с данной нагрузкой и не достигла насыщения (предела пропускной способности), то есть при дальнейшем росте количества пользователей объем информации, обрабатываемой системой в единицу времени, будет возрастать.

        3. Другой важной характеристикой является время записи и проведения одного документа в ситуациях с различной степенью конкуренции вводимых данных (рис. 2). При росте числа активных пользователей оно возрастает, но не настолько существенно, чтобы говорить о серьезном замедлении работы операторов. Тем более, что данный показатель не соотносится напрямую с объемом информации, обработанной одним тестовым пользователем в единицу времени, а демонстрирует только среднее время, затраченное на запись и проведение каждого документа без учета пауз между их вводом. (Тем не менее разработчикам из “1С” было бы полезно подумать о применении асинхронного режима при массовом, потоковом вводе данных, чтобы во время обработки документа можно было начинать ввод следующего.)

        Увеличение времени обработки объясняется блокировками при параллельной работе с конкурентными наборами данных, увеличением нагрузки на все программные и аппаратные компоненты системы, а также ростом накладных расходов, связанных с обслуживанием большего количества пользователей. Однако время обработки одного документа ни в одном тесте не превысило 10 с. Важно также подчеркнуть, что при тестировании на конкурентных наборах данных не наблюдалось конфликтов взаимной блокировки (deadlock).

        Это очень важный момент, поскольку проведенный ранее анализ конфигурации 1С:УПП выявил фрагменты кода и структуры данных, не позволявшие серверу БД эффективно блокировать нужные участки данных. В версии 1.1.7 эти проблемы были устранены.

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

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

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

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

        Что поможет бизнесу пойти на контакт с IT-специалистами и вникнуть в особенности масштабирования систем?

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

        5 ключевых вопросов о масштабировании

        По нашему опыту разработчики затрагивают 5 главных вопросов, когда говорят о масштабируемости:

        1. Есть ли понимание планируемых возможностей системы?

        2. Какие типовые действия будут осуществлять пользователи системы?

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

        4. Что более принципиально для системы – отказоустойчивость или высокая производительность?

        5. Откуда может возникнуть потребность в масштабируемости системы?

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

        Есть ли понимание планируемых возможностей системы?

        Что за этим стоит:

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

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

        Пример:

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

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

        
        

        Взять на вооружение:

        Чётко формулируйте цели IT-проекта и составляйте план или график прогнозируемой посещаемости сайта. Желательно с указанием временных интервалов.

        Разработчики задают вопрос о возможностях системы не из праздного интереса. Им необходимо заранее предусмотреть лазейки для дальнейшего роста возможностей системы. Если бизнес планирует завоевывать мир, необходимо предельно ясно обозначать свои цели. Скажем, когда на сайт с ежедневной аудиторией не более 300 пользователей придёт 10000 уникальных посетителей за раз, система не должна падать.

        Какие типовые действия будут осуществлять пользователи системы?

        Что за этим стоит:

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

        
        

        Пример:

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

        Взять на вооружение:

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

        • Как вы хотели бы, чтобы пользователь взаимодействовал с системой
        • Как это может происходить на самом деле

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

        Что за этим стоит:

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

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

        Пример:

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

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

        
        

        Взять на вооружение:

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

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

        Что более принципиально для системы – отказоустойчивость или высокая производительность?

        Что за этим стоит:

        Разные системы требуют разного подхода. Разработчикам важно понимать, какую задачу они решают – отказоустойчивости системы, её высокой производительности, или обе сразу.

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

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

        Пример:

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

        
        

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

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

        Взять на вооружение:

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

        Откуда может возникнуть потребность в масштабируемости системы?

        Что за этим стоит:

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

        Пример:

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

        Взять на вооружение:

        Ответьте себе на вопрос, что вы понимаете под масштабируемостью системы в текущем IT-проекте. Разделите понятия:

        • У вас в базе данных 10000 пользователей и вам нужно наращивать возможности сервера для хранения информации
        • На ваш веб-сайт единовременно приходят 10000 пользователей и сервер нуждается в подкреплении своих вычислительных мощностей

        
        

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

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

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

        Подпишитесь

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

        Читайте также:

          
        • Работа администратора медицинского центра в чем заключается
          
        • Идет ли биологам медицинский стаж
          
        • Можно ли в тюрьме отказаться от работы
          
        • Как попасть в префектуру на работу
          
        • Работодатель покажите что вы умеете