1С:УПП: проверка на масштабируемость пройдена

Исследование выполнялось на примере операций, наиболее критичных с точки зрения нагрузки на вычислительную систему, и с параметрами, типичными для большинства организаций-заказчиков. Использовался клиент-серверный вариант 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С” отмечали, что одной из задач данной работы являлось подтверждение того, что платформа позволяет создавать весьма масштабируемые решения. Но заказчики смогут оценить эту потенциальную возможность только в случае ее грамотного применения для оптимизации наиболее типовых бизнес-процессов прикладных решений.