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

ТЕСТИРОВАНИЕ ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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