Производительность и масштабируемость системы “1С:Предприятие”: от 7.0 до 8.next

--> Дата: Фев 18, 2008 432

Начав в 2003 г. активное продвижение следующего поколения решений “1С:Предприятие” 8 на относительно новом для себя рынке корпоративных клиентов, фирма “1С” (http://www.1c.ru) оказалась, на наш взгляд, в необычном для себя положении. До того компания традиционно выступала технологическим “локомотивом” для своих потребителей из сектора малого бизнеса: ее разработчики постоянно опережали (но не намного, чтобы не оторваться) текущие потребности клиентов. На среднем рынке ситуация иная — у заказчиков уже давно сформировались в целом высокие требования к ИТ, а к появлению новых поставщиков здесь относятся достаточно настороженно.

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

Если же говорить о технологических проблемах развития экономического ПО “1С”, то, безусловно, одна из главных задач (хотя, конечно, далеко не единственная) — это повышение производительности и масштабируемости (ПиМ) ее прикладных решений. О том, что “1С” признает важность этих вопросов, говорит хотя бы тот факт, что сама фирма после выпуска четыре года назад платформы “1С:Предприятие” 8.0 начала регулярно официально знакомить ИТ-общественность с результатами тестирования в этой области. Показательно и то, что первое существенное технологическое обновление платформы “1С:Предприятие” 8, выпуск новой версии 8.1, было связано в значительной степени именно с решением задач масштабирования и производительности (см. статью “Платформа “1С:Предприятие 8.1” уже на подходе, «BYTE/Россия» № 9’2006).

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

1. На графике приведены значения АРПмакс: это не просто число работающих пользователей, а максимальное число активно работающих пользователей (подробнее об этом речь пойдет ниже).

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

Рис. 1. Рост производительности платформы “1С:Предприятие” (оценки автора).

А теперь, чтобы пояснить, как получился этот график, сначала разберемся с некоторыми общими вопросами.

Производительность и масштабируемость — общие соображения

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

Производительность

Понятие производительности ERP-систем связано со способностью выполнения транзакций в многопользовательском режиме. В этом плане важны две основные характеристики: общее число транзакций в единицу времени и время исполнения одной транзакции (имеется в виду, что транзакции выполняются параллельно)*. Однако обе эти характеристики динамические — они зависят от числа поступающих запросов на транзакции, а применительно к традиционным внутрикорпоративным ERP-решениям — от числа активно работающих пользователей (АРП)**.

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

** Для оценки производительности ИТ-проекта с технической точки зрения нужно учитывать именно “активно работающих пользователей”, а не просто число установленных рабочих мест.

Соответственно производительность ERP-системы должна описываться графиком, который в общем виде приведен на рис. 2. Именно он показывает верхний диапазон применимости данной технологии (максимальное число АРП, АРПмакс, или предел производительности), который характеризуется резким замедлением роста общей пропускной способности системы и резким же увеличением времени обработки одного запроса. В техническом задании АПРмакс довольно часто определяется как максимальное число обслуживаемых пользователей, при котором время обработки одного запроса не превышает установленного предела.

Рис. 2. Общий характер роста производительности ERP-системы.

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

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

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

Рис. 3. Графики роста производительности при разной интенсивности запросов.

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

Рис. 4. Изменение производительности при подключении пользователей-аналитиков.

Следует также разобраться, что мы понимаем под термином «ERP-система», делая акцент на слове “система”. Здесь возможны три основных варианта ответа:

базовая технологическая платформа;
типовое прикладное решение на основе этой платформы;
конкретный проект, реализованный на основе типового прикладного решения.

Очевидно, что экспериментальные данные о производительности, такие, как АПРмакс, относятся только к одному конкретному проекту. И в этом плане нужно понимать, что любое нагрузочное тестирование — это лишь исследование ряда тестовых проектов (чаще даже одного). Соответственно показатели для прикладного решения — это результат статистической обработки данных, полученных в реализованных на его базе проектах, а характеристики платформы формируются из показателей для созданных на ее основе приложений (рис. 5).

Рис. 5. Диапазон производительности платформы — это результат статистической обработки данных, полученных в конкретных проектах.

Таким образом, нужно четко разделять два разных применения показателя АПРмакс: для конкретного ИТ-проекта и для базовых технологий. В первом случае он всегда имеет довольно узкий диапазон значений (например, 120—140), во втором — существенно более широкий (80—250).

Возвращаясь к теме ПиМ, отметим, что стратегическая задача состоит в расширении диапазона АПРмакс в рамках приемлемых стоимостных показателей — с точки зрения как вендора (это определяет спектр покрытия клиентского рынка), так и заказчика (в плане развития его конкретной системы). Мы сознательно не рассматриваем здесь вопрос о нижней границе применимости технологии: понятно, что с технической точки зрения она всегда равна 1. А с точки зрения заказчика она определяется чаще всего соображениями стоимости: можно в принципе поставить SAP R/3 для обслуживания одного человека, но мало кто в состоянии позволить себе такую роскошь.

Масштабируемость и масштабирование

Довольно часто, говоря о масштабируемости программной системы, на самом деле имеют в виду ее способность адекватно (линейно) повышать производительность в условиях увеличения потока запросов на обработку. Но такое представление неверно. Правильное определение звучит примерно так: «Масштабируемость — это способность системы увеличивать свою производительность за счет подключения дополнительных вычислительных ресурсов, как аппаратных, так и программных». Соответственно масштабирование — это способ повышения производительности системы за счет ее масштабируемости.

Проиллюстрируем эти положения на примере работы Web-сервера, вычислительные показатели которого также описываются графиком на рис. 2. Но отражает ли линейный участок роста его производительности (до АРПмакс) характеристику масштабируемости? Вообще говоря, нет: в этом случае речь идет не о подключении дополнительных ресурсов, а скорее о повышении КПД имеющегося оборудования. А вот когда наш Web-сервер подходит к пределу своей производительности в данной аппаратно-программной конфигурации, тут и встает вопрос о его масштабируемости — за счет наращивания памяти, числа процессоров, использования кластеров и т. д. Таким образом, применительно к программе масштабируемость подразумевает не столько увеличение производительности, сколько повышение предела производительности (т. е. того самого показателя АРПмакс).

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

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

ПиМ для клиент-серверной архитектуры

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

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

Но по мере своего развития (а иногда и на этапе ввода в эксплуатацию) система заказчика подходит к своему значению АРПмакс. Что же делать? К сожалению, порой только в этот момент заказчик задумывается: а что представляет собой его ERP-система в архитектурном плане? Например, как реально распределяется обработка запросов между клиентом и сервером? А следовательно — мощность каких вычислительных ресурсов нужно наращивать для преодоления достигнутого барьера? И есть ли реальная возможность повышения мощности аппаратуры, которое дало бы адекватный прирост производительности системы в целом?

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

Не только масштабирование

Масштабирование — это не единственный, а зачастую и не самый эффективный способ повышения производительности системы. Например, для того же Web-сервера этого можно достичь за счет оптимальной настройки, в том числе на базе анализа условий его работы, характера потока запросов. И уж тем более это относится к многофункциональным, распределенным ERP-системам. Тут есть огромные возможности, связанные с реинжинирингом проекта, если понимать этот термин в самом широком смысле — от изменения бизнес-процессов предприятия до оптимизации программного кода.

Если говорить о реализации ИТ-проекта, то ее можно схематично представить в виде такой цепочки: вендор — системный интегратор — ИТ-служба заказчика — пользователи. Отсюда видно, что у разработчика и пользователя есть взаимный интерес — минимизировать свою зависимость от двух других связующих элементов. Именно по этой причине при использовании сложных корпоративных технологий возрастают и требования к возможностям масштабирования решений, более того — появляется желание в определенной степени ограничить “технологический реинжиниринг”.

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

Мнение эксперта

Новые возможности платформы — новые требования к специалистам

Андрей Волков,

руководитель отдела типовых решений, ООО «ИТРП»

Компания «Институт типовых решений — Производство» (ИТРП, http://www.itrp.ru) работает на рынке средств автоматизации предприятий с 2000 г., специализируясь в области разработки и внедрения тиражных продуктов для производственных предприятий на основе различных версий платформы «1С:Предприятие». На базе версии 8 мы разработали успешно введенные в промышленную эксплуатацию продукты «ИТРП:Производственное предприятие 8. Стандарт», «ИТРП:Процессное производство 8», «1С:Производство строительных материалов».

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

Изначально для составления и решения системы линейных уравнений использовалась выборка, формируемая одним запросом, — так было понятнее и удобнее для программистов. Однако при выполнении пилотных проектов на ряде предприятий машиностроения и приборостроения выяснилось, что в какой-то момент времени размер выборки, получаемой при помощи «красивого» запроса, начинал превышать объем доступной оперативной памяти, и работа системы завершалась ошибкой. Для разрешения проблемы пришлось переработать алгоритм составления системы уравнений таким образом, чтобы запрос формировался порциями. В новой версии платформы для обхода данной проблемы реализована возможность сохранять выборки больших размеров на диске в виде временного файла. С одной стороны, это действительно решение проблемы, хотя, что называется, «в лоб», с другой стороны — разработчикам прикладных решений все же не стоит особенно рассчитывать на этот способ, поскольку в любом случае необходимо оптимизировать коды прикладных решений для повышения их производительности, используя по максимуму штатные возможности платформы, механизмы и приемы тестирования производительности для определения узких мест в конфигурациях.

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

Технологии “1С” и средний бизнес

Тернистый путь наверх

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

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

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

Конечно, подобное деление (платформа и решение) в том или ином виде имеется у любого разработчика крупной программной системы. Но только “1С” довела этот подход до логического конца: она полностью уравняла в возможностях разработки и модификации прикладных решений своих собственных и внешних разработчиков. Напомним также, что программные продукты “1С” всегда поставлялись в исходных кодах (отличная иллюстрация того, что open source и бесплатное ПО — это в общем случае две разные категории). Таким образом, все желающие (партнеры, заказчики) могут не просто дорабатывать прикладные решения, но и изменять их на уровне базовой бизнес-логики, а также создавать собственные “с нуля”.

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

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

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

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

Средний рынок — что тут нового

Вопросы ПиМ для фирмы “1С” непосредственно связаны с ее продвижением на корпоративный рынок средних и крупных заказчиков.

С точки зрения ИТ для характеристики “среднего рынка”, наверное, лучше использовать подход (его придерживается, в частности, Microsoft), согласно которому к категории средних относятся предприятия с числом установленных ПК в диапазоне от 25 до 500 (midmarket). При этом выделяются две группы: 25—50 ПК (lower) и 50—500 (upper), что принципиально важно. В организациях первой группы, как правило, нет выделенного штатного ИТ-специалиста, и большинство ИТ-решений принимает непосредственно руководитель компании. У upper-компании уже есть хоть и небольшое, но выделенное ИТ-подразделение, которое в той или иной степени причастно к реализации проектов, а его руководитель напрямую участвует в выработке решений. ИТ-решения принимаются на основе долгосрочного планирования, в увязке с состоянием и перспективой развития ИТ-инфраструктуры предприятия в целом.

Казалось бы, с точки зрения поставщика главный показатель — это не столько размер компании-клиента, сколько размер конкретного проекта. И тут тоже можно выделить категории по принципу “мало-средне-крупный” с привязкой, скажем, к числу автоматизированных рабочих мест. На самом деле уровень самого заказчика все же очень важен, так как именно он определяет стиль принятия решений и реализации проектов, перспективы развития сотрудничества и т. п.

Все это мы говорим к тому, что в последние пару лет “1С” продвигается именно в сегмент upper-midmarket, и соответственно успех этого продвижения определяется не только развитием технологий, но и коррекцией бизнес-модели (поставщик-партнеры-заказчики). Суть изменений (в сильно упрощенной формулировке, конечно) выглядит примерно так. Раньше ИТ-заказчиком выступал главный бухгалтер, теперь — профессиональный ИТ-директор со своей командой специалистов. Раньше речь шла о решении автономной задачи автоматизации, а сейчас — о внедрении интегрированного компонента корпоративной системы в целом. Раньше бизнес-целью заказчика было выжить в условиях рынка, сейчас — динамично развиваться и развиваться на многие годы вперед…

Что же касается проблематики ПиМ, то она крайне важна именно для среднего рынка в силу динамичности развития его игроков и соответственно расширения круга и масштаба решаемых ими ИТ-задач.

Динамика развития от 7.0 до 8.next

Версия 7.х, выход на средний рынок

Строго говоря, подготовка к выходу на lower-midmarket в “1С” началась 11 лет назад, когда летом 1996 г. фирма представила свой первый продукт нового поколения. Примечательно, что это была не традиционная “1С:Бухгалтерия”, а “1С:Торговля”, изначально ориентированная на многопользовательскую работу. Отметим и то, что ни о какой технологической платформе 7.0 тогда не было и речи — не потому что не было самой платформы, а потому что “1С” не хотела в те времена использовать подобные «громкие» слова, считая, что технические вопросы — это ее сугубо внутреннее дело. Тогда же впервые в дополнение к файл-серверному варианту системы появился двухзвенный клиент-серверный, реализованный на базе СУБД Btrieve, на смену которому два года спустя пришла система в составе “1С:Предприятие” 7.5 и Microsoft SQL Server 6.5. А за точку отсчета для начала серьезной работы на lower-midmarket, наверное, стоит принять лето 1999 г., когда на рынке появились “1С:Предприятие” 7.7 и Microsoft SQL Server 7.0 (известный в те времена проект “777”), для применения которых уже “созрели” и заказчики, и партнеры.

Однако примечательно, что вопросы ПиМ применительно к “1С:Предприятие” версии 7 сама “1С” никогда не поднимала. Даже говоря о достоинствах клиент-серверного варианта, специалисты фирмы осторожно советовали применять эту схему при числе пользователей более 10—15, но какие-то верхние пределы никогда не назывались. Никаких публичных сравнений показателей работы клиент-сервера и файл-сервера также не проводилось; более того, подчеркивалось, что преимущества первого варианта заключаются не столько в более высокой производительности, сколько в увеличении надежности системы.

Какие-то внутренние тестовые исследования производительности наверняка имели место, но все же основная стратегия “1С” в этом вопросе тогда сводилась скорее к “разведке боем” — проверке возможностей своего ПО путем практической реализации проектов партнерами. Этот опыт показал, что на базе “1С:Предприятие” 7 можно создавать системы с числом АРП примерно от 25 до 70. Но для этого требовались достаточно серьезные усилия со стороны внедренцев, и такие задачи были по силам уже далеко не всем партнерам.

Сама “1С” отмечает, что на базе “1С:Предприятие” версии 7 были реализованы и более масштабные проекты — с числом рабочих мест более 100 (есть пример на 370 рабочих мест). Правда, остается вопрос — это просто подключенные клиенты или “активно работающие”? Но в целом специалисты “1С” признают: реализация проектов на базе версии 7 с числом рабочих мест более 30—50 требовала от внедренцев достаточно серьезных усилий.

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

Для понимания причин этого нужно иметь в виду, например, что “1С:Предприятие” 7 была изначально построена по схеме блокировок на уровне таблиц и реализации бизнес-логики обработки запросов к БД на клиентской части. Объяснить выбор такой простой архитектуры обмена данными довольно легко: в тот момент обеспечение надежной работы сложных прикладных решений на массовом рынке было важнее повышения производительности.

Впрочем, были, конечно, реинжиниринговые методы повышения производительности, которые уже выходят за рамки применения стандартной клиент-серверной схемы “1С:Предприятие” 7. Частый случай — использование терминального режима работы (Windows Terminal Server). Но, строго говоря, данный вариант предполагал не столько повышение производительности, сколько оптимизацию затрат на оборудование. Более радикальный подход — использование распределенных баз данных, когда единая система разбивается на несколько автономных подсистем (например, однородных, но географически распределенных или локальных, но неоднородных), которые могут работать в основном в автономном режиме, периодически взаимодействуя между собой и синхронизируя общие массивы данных. Однако нужно иметь в виду, что в этих случаях речь идет о реализации достаточно сложных проектов, в успехе которых ключевая роль отводится квалификации внедренцев. При этом применение методов реинжиниринга имеет свои очевидные ограничения.

Версия 8.0, переход на upper-midmarket

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

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

Могла ли “1С” пойти на более радикальные изменения ради более успешного продвижения в сегмент корпоративных клиентов (и нужно ли это было делать)? Это вопрос спорный, а главное, сегодня он уже носит сугубо теоретический характер. Но совершенно очевидно, что, принимая стратегические решения о путях развития своего ПО, руководство компании учитывало проблему “наследственности”, выходящую за рамки чисто технических вопросов. Тут в первую очередь нужно иметь в виду готовность к подобным инновациям партнерской сети “1С”, этого краеугольного камня бизнес-модели компании.

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

Собственно, именно в версии 8.0 впервые появился достаточно серьезный механизм управления данными, который можно было размещать либо на клиентской части (для файлового варианта), либо на сервере. Соответственно масштабирование серверной части (сервер + СУБД) обеспечивалось двумя взаимодополняющими вариантами: использованием многопроцессорных конфигураций (реализация многопотоковой обработки на сервере и на СУБД) и разнесением сервера и СУБД на разные компьютеры.

Появление “1С:Предприятие” 8 позволило “1С” начать публичное обсуждение вопросов ПиМ своих технологий. Эта тема была обозначена уже при объявлении бета-версии в марте 2003 г., когда были впервые представлены результаты проведенного нагрузочного тестирования, в том числе и для версии 7.7. Из рис. 6 хорошо видно, что для последней клиент-серверный вариант имеет не слишком большое преимущество перед файловым. Отметим также, что архитектурные новшества 8.0 проявляются именно для трехзвенной клиент-серверной конфигурации.

Рис. 6. Результаты тестовых испытаний на этапе бета-тестирования “1С:Предприятие” 8.0 (Источник: “1С”, апрель 2003 г.).

Более детальное исследование ПиМ было выполнено фирмой “1С” уже после выпуска рабочей версии 8.0. В целом результаты испытаний (рис. 7) достаточно хорошо демонстрировали не только архитектурные преимущества 8.0 перед 7.7 в плане повышения производительности для одной и той же аппаратной конфигурации (см. графики для версий 7.7 и 8.0-1), но и существенные возможности масштабирования в версии 8.

Рис. 7. Зависимость скорости обработки документов при многопользовательском вводе и различной конфигурации серверов.
Обозначения: 7.7 — используется версия 7.7; 8.0-1-x — Microsoft SQL Server и сервер «1С:Предприятие» 8.0 размещаются на одном компьютере с числом процессоров соответственно х = 1, 2, 4; 8.0-2 — Microsoft SQL Server и сервер «1С:Предприятие» 8.0 размещаются на разных компьютерах, соответственно четырех- и двухпроцессорном (источник: “1С”, декабрь 2003 г.)

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

За счет чего же достигается масштабируемость на уровне сервера “1С:Предприятие”? Для ответа на этот вопрос выделим три основные функции данного компонента:

механизм взаимодействия клиентского приложения с СУБД;
исполнение бизнес-логики прикладных решений;
общее управление системой (администрирование, управление правами, обеспечение безопасности и т. п.).

Последняя функция связана с вопросами ПиМ в минимальной степени, поэтому рассмотрим первые две.

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

Однако с использованием сервера связан также вопрос надежности работы системы в целом. Мы не будем обсуждать характеристики “1С:Предприятие” 8 в плане отказоустойчивости, но отметим, что это важный вопрос, который требует отдельного изучения. Кроме того, нужно понимать относительность результатов нагрузочных тестирований, которые демонстрируют лишь основные возможности технологий и общие тенденции их развития. Для более серьезного исследования вопроса требуется технический анализ применения этих технологий в реальных проектах; сведений о публичных работах в этом направлении применительно к “1С:Предприятие” 8 пока нет.

Тем не менее даже самая общая информация о выполненных проектах на базе “1С:Управление производственным предприятием” 8.0 говорит о возможности реализации достаточно крупных систем. Есть примеры использования одного сервера “1С:Предприятие” 8.0 для подключения более 200 АРП, хотя средний уровень проектов характеризуется диапазоном 120—150. Есть и более крупные проекты на основе платформы 8.0 (с числом клиентов до 500 и более), но они реализованы в виде нескольких подсистем (с отдельным сервером) — автономных или распределенных баз данных.

Версия 8.1 — кластерный сервер

Итак, в “1С:Предприятие” 8.0 достигнут существенный прогресс в направлении ПиМ, но все же он недостаточен для полного охвата потребностей среднего рынка. В то же время корпоративный заказчик смог оценить возможности платформы, поверил в них и требовал “продолжения банкета”. Форсированный выпуск в конце 2006 г. версии “1С:Предприятие” 8.1, в которой ПиМ была уже не “одной из”, а главной задачей, стал ответом на эти потребности рынка.

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

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

Принципиальное новшество в “1С:Предприятие” 8.1 — переработанная архитектура клиент-серверного варианта, которая помимо прочего теперь строится на использовании протокола TCP/IP (вместо COM+). Именно это обеспечило работу сервера под управлением не только Windows, но и Linux, а также реализацию кластера серверов “1С:Предприятие”.

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

Рис. 8. Структура кластера серверов на базе «1С:Предприятие» 8.1. Обозначения: ragent — агент сервера “1С:Предприятие”; rmngr — менеджер кластера серверов “1С:Предприятие”; rhost — рабочий процесс сервера “1С:Предприятие”, обслуживающий клиентов.

Данные по ПиМ в “1С:Предприятие” 8.1 были представлены на прошедшем в конце марта партнерском семинаре, причем важность этой темы подчеркивает тот факт, что на мероприятии ей было посвящено сразу несколько выступлений. Главное из них касалось нового исследования самой фирмы «1С».

Один из представленных тестов показывает преимущества работы 8.1 по сравнению с 8.0 даже в случае использования одного компьютера-сервера (рис. 9). Поясним, что во всех нагрузочных тестах “1С” используется программная имитация работы пользователя, при этом темп работы “тестового пользователя” существенно выше, чем у реального среднестатистического (в данном случае соответственно 965 и 300 строк документа в час). Из рис. 9 видно, что у “1С:Предприятие” 8.0 при числе тестовых пользователей более 100 начинается заметная деградация общей пропускной способности системы, а при нагрузке более 150 пользователей этот показатель просто перестает расти. В то же время для “1С:Предприятие” 8.1 продолжается практически линейный рост производительности.

Рис. 9. Сравнение общей пропускной способности платформ “1С:Предприятие” 8.0 и 8.1 для односерверной конфигурации (источник: “1С”, март 2007 г.).

В плане демонстрации масштабирования “1С:Предприятие” 8.1 за счет применения кластера представляют интерес тестовые испытания при пиковых нагрузках (здесь нагрузочные условия были несколько иные, чем в предыдущем случае). Его результаты показывают (рис. 10), что при использовании одного компьютера-сервера пропускная способность 8.1 возрастает в 2,28 раза, а в случае двух компьютеров — в 3,83.

Рис. 10. Сравнение общей пропускной способности платформ 8.0 и 8.1 для односерверной и кластерной конфигурации (источник: “1С”, март 2007 г.).

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

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

Рис. 11. Возможность масштабирования сервера “1С:Предприятие” 8.1 за счет использования многоядерных микропроцессоров Intel (источник: Intel, март 2007 г.)

По данным фирмы “1С” по состоянию на начало мая, анализ проектов, уже реализованных на платформе 8.1, подтверждает возможность увеличения числа АРП в реальных условиях в среднем до 200—300 даже для одиночного сервера. Что касается кластерных конфигураций, то компания, возможно, опубликует данные об их применении в «боевых условиях» в недалеком будущем.

Тут нужно подчеркнуть, что само появление версии 8.1 представляет собой пример масштабирования решений на базе “1С:Предприятие” 8.0 за счет смены базовой платформы: здесь полностью обеспечена совместимость приложений при переходе на новую версию. Эта возможность была проиллюстрирована на мартовском семинаре, где один из крупных клиентов рассказывал об опыте замены 8.0 на 8.1: физически для этого потребовалось остановить систему всего на два часа, после чего она смогла обслуживать более 200 пользователей вместо 100.

Следующий шаг: “управляемое приложение”, версия 8.2?

Еще представляя в феврале 2006 г. перспективы развития “1С:Предприятие” 8, разработчики “1С” заявили, что у них есть ближние и дальние планы. Ближние планы были реализованы с выпуском 8.1, а на мартовском семинаре уже был представлен следующий шаг в виде проекта “Управляемое приложение”. Какой номер получит новая версия платформы, пока неизвестно, но по предварительному графику ее бета-версия может появиться уже нынешним летом, а окончательная — к концу текущего года.

Цель нового проекта сводится к повышению управляемости прикладных решений, но на самом деле она имеет непосредственное отношение к вопросам ПиМ. Нетрудно заметить, что повышение ПиМ напрямую связано с переносом вычислений с клиента на сервер (рис. 12). Как отмечалось, ранее, сервер “1С:Предприятие” в принципе уже сейчас может выполнять функции управления запросами к базе данных и бизнес-логику. Но дело в том, что “1С:Предприятие” исторически была построена как клиентская платформа, и это создает сложности для переноса бизнес-логики на сервер. Проект “Управляемое приложение” требует достаточно радикальной переработки платформы, что позволит реализовать идею тонкого и Web-клиента с перемещением функций обработки на сервер.

Рис. 12. Возможности перераспределения вычислительной нагрузки в версии 8.next.

<Файл pim13>

Масштабированием нужно уметь пользоваться

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

Отметим также, что по мере роста сложности реализуемых проектов повышается актуальность проведения исследований для оптимизации создаваемых у заказчиков систем. До использования в таких работах инструментов типа HP Mercury, кажется, еще не дошло, но сама “1С” уже предлагает партнерам и клиентам собственные средства нагрузочного и функционального тестирования.

И наконец, нужно сказать, что проблемы роста системы “1С:Предприятие”, конечно, не ограничиваются вопросами повышения производительности и масштабируемости. Это лишь необходимое, но не достаточное условие для успеха на корпоративном рынке.