Visual2000 · Статьи А.Колесова по "1С"
©
Андрей Колесов, 2007
Авторский вариант. 02.06.2007. Статья пока нигде больше не опубликована
Эти два понятия – производительность и масштабируемость (ПиМ) – являются непременной атрибутом в обсуждении любых технологий корпоративного уровня, и даже используются именно в такой связке, как некая самостоятельная характеристика. Но, как это часто бывает в жизни, при этом их содержательный смысл порой забывается.
Определение производительности ERP-систем связано со способностью выполнения транзакций в многопользовательском режиме. В этом плане важны две основные характеристики: общее число транзакций в единицу времени и время исполнения одной транзакции (имея в виду, что транзакции выполняются параллельно)*. Однако, обе эти характеристики являются динамическими – они зависят от числа поступающих запросов на транзакции, проще говоря, применительно к традиционным внутрикорпоративным ERP-решениям, -- числу активно работающих пользователей (АРП)**.
Соответственно, производительность ERP-системы должна описываться графиком, общий вид которого приведен на рисунке 1.1. Именно он показывает верхний диапазон применимости данной технологии (максимального числа АРП, АРПмакс или предел производительности), который связан с резким замедлением роста общей пропускной способности системы и резким увеличением времени обработки одного запроса. С точки зрения технического задания, довольно часто АПРмакс определяется как максимальное число обслуживаемых пользователей, при котором время обработки одного запроса не превышает установленного предела.
Рис. 1.1. Оценка производительности ERP-системы
Глядя на рисунок 1.1, нужно обратить внимание на два момента:
В свою очередь, АПРмакс не является некой константой, ее нужно всегда оценивать в терминах диапазона (рис. 1.1), который зависит от множества организационно-технический условий реализации и эксплуатации ИТ-проекта у конкретного заказчика. В общем случае, можно выделить три ключевые компонента влияющие на формирование АПРмакс: "возможности базовых технологий вендора" + "квалификация проектировщика" + "эксплуатация заказчиком".
В этой связи нужно обратить внимание на относительность самого понятия "активно работающий пользователь". Даже в рамках конкретного проекта, условия эксплуатации системы могут измениться так, что средний поток запросов от одного пользователя может возрасти в полтора-два раза. И тогда характеристика производительности будет выглядеть вот так (рис. 1.2).
Рис. 1.2. Графики роста производительности при различной интенсивности запросов
Но еще важнее то, что на самом деле, пользователи ERP-систем являются "разнородными", и соответственно запросы от них по уровню сложности обработки могут существенно отличаться. Соответственно, если на первом этапе реализации проекта у заказчика с системой работали 100 операторов, которые выполняли ввод с накладных, а на втором этапе к системе были подключены 5 специалистов, формирующих аналитические отчеты, то вполне вероятно, что график изменения производительности будет выглядеть уже совсем по-другому (рис. 2.3).
Рис. 1.3. Изменение производительности при подключении пользователей-аналитиков
Надо также разобраться – что мы понимаем под термином ERP-система, делая акцент на слове "система"? Отвечая на этот вопрос, я бы выделил три основных варианта ответа на него:
Вполне понятно, что показатели производительности, как экспериментальные данные (такие как АПРмакс) могут быть получены только для конкретного проекта. И в этом плане нужно понимать, что любое нагрузочное тестирование – это лишь исследование ряда тестовых проектов (хотя чаще – одного). Соответственно, показатели о прикладном решении получаются в виде результата статистической обработки данных о реализованных на его базе проектов, а характеристики платформы – на основе о сведениях по созданным на ее основе приложений (рис. 2.4).
Рис. 1.4. Показатели "диапазона производительности платформы" – это результат статистической обработки данных по конкретным проектам.
Таким образом, нужно довольно четко разделять два разных применения АПРмакс: для конкретного ИТ-проекта и для базовых технологий. В первом случае он всегда имеет довольно узкий диапазон разброса (например, 120-140), во втором – существенно более широкий (80-250).
Возвращаясь в теме ПиМ, отметим, что стратегической задачей является расширения диапазона АПРмакс в рамках приемлемых стоимостных показателей, как с точки зрения вендора (это определяет спектр покрытия клиентского рынка), так заказчика (в плане развития его конкретной системы)***.
*** Мы сейчас сознательно не рассматриваем вопрос о нижней границы применимости технологии.
Понятно, что с технологической точки зрения она всегда начинается с 1. А с точки зрения
заказчика она определяется чаще всего стоимостными соображениями: можно, например,
поставить SAP R3 для обслуживания одного человека, но мало кто может позволить себе такую
роскошь.
Довольно часто, говоря о масштабируемости программной системы, мы на самом деле имеем в виду ее способность адекватно (линейно) повышать свою производительность в условиях увеличения потока запросов к ней на обработку.
Но, такое представление является неверным. Правильное определение звучит примерно так:
Масштабируемость – это способность (свойство) системы увеличивать свою производительность за счет подключения дополнительных вычислительных ресурсов, как аппаратных, так и программных. Соответственно, масштабирование – это способ повышения производительности системы за счет ее масштабируемости.
Проиллюстрируем эти положения на примере работы Web-сервера, вычислительные показатели которого также описываются графиком на рис. 1. Но отражает ли линейный участок роста его производительности (до АРПмакс) характеристикой масштабируемости? Вообще-то, нет: тут нет никакого подключения дополнительных ресурсов, скорее, речь идет о повышении КПД имеющегося оборудования.
А вот когда наш Web-сервер подходит к пределу своей производительности в данной его аппаратно-программной конфигурации, то тут и встает вопрос о возможностях его масштабируемости – за счет увеличения памяти, процессоров, использования кластеров и т.д.
Таким образом, применительно к программе, масштабируемость подразумевает возможность не столько увеличения производительности, сколько повышения ПРЕДЕЛА производительности (т.е. того самого показателя АРПмакс).
В определении масштабируемости говорится об увеличении вычислительных ресурсов. Под ними мы чаще всего имеем в виду использование аппаратных компонентов системы (расширение памяти, увеличение мощности процессора, числа процессоров, создание кластеров и т.д.). Но не надо забывать и о возможности совершенствования программной части – как ее отдельных элементов (например, применение более мощных СУБД), так и базовой платформы в целом (если вендор готов к подобному развитию своих технологий). Применительно к 1СП8.0 это может быть, например, переход от файлового варианта к клиент-серверному, от платформы 8.0 к 8.1.
Если же речь идет об аппаратных ресурсах, то под масштабированостью понимают возможность роста производительности пропорционально увеличении мощности оборудования. Но такая трактовка представляется слишком зауженной, хотя бы потому, что ее трудно применить к ряду ресурсов (например, в ОЗУ). Скорее, в этом случае правильнее говорить об эффективности или качестве масштабируемости.
Рис. 1.5. Клиент-серверная архитектура ERP-системы
Если у вас есть некая фиксированная серверная часть, то повышение нагрузки на нее связано с увеличением числа пользователей, т.е. клиентских компьютеров. С этой точки зрения функция производительности на рис. 1.1 отражает свойство масштабируемости за счет увеличения клиентского оборудования (и одновременно – диапазон изменения производительности серверной части)
Но по мере своего развития система заказчика (а иногда и на этапе ее ввода в эксплуатацию) подходит к своему значению АРПмакс. Что же делать?
К сожалению, порой только в этот момент заказчик задумывается: а что представляет собой в архитектурном плане используемая им ERP-система? Например: как реально распределяется обработка запросов между клиентом и сервером? И как следствие – мощность каких вычислительных ресурсов нужно повышать для преодоления достигнутого предела? И есть ли реальная возможность повышения мощности аппаратуры, которая дала бы адекватный прирост производительности системы в целом?
Так или иначе, но понятно, что в сложных многопользовательских системах наиболее критичным ресурсом является серверная часть, возможность повышения ее производительности, в том числе за счет ее масштабируемости. Это в целом относится и к "1С:Предприятию", развитие которого идет в направлении поэтапного переноса вычислительных функций с клиентской части на серверную.
И уж тем более это относится к многофункциональным, распределенными ERP-системам. Тут есть огромные возможности, связанные с реинжинирингом проекта, понимая этот термин в самом широком его смысле – от изменения бизнес-процессов предприятия до оптимизации программного кода.
Если говорить о схеме реализации ИТ-проекта, то она может быть представлена в виде такой цепочки: вендор – системный интегратор – ИТ-служба заказчика – конечный пользователь. Учитывая это, понятно, что у разработчика и конечного пользователя есть взаимный интерес по минимизации зависимости от двух других связующих элементов. Именно это определяет то, что при использовании сложных корпоративных технологий, возрастают к требования к возможностям масштабирования решений, и более того – появляется желание в определенной степени ограничить "технологический реинжениринг".
Вариант с наращиванием ресурсов может быть и не дешевле, чем работа консультантов и программистов по модернизации и настройке ПО (хотя стоимость рабочей силы растет быстрее, чем готовых продуктов). Но для целого ряда проблем, особенно типовых, – это более быстрый и гарантированный вариант решения проблемы, независящий от многочисленных субъективных факторов, в том числе квалификации исполнителей.