Visual2000 · Статьи А.Колесова по "1С"

Вопросы производительности и масштабируемости в "1С:Предприятии"

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

© Андрей Колесов, 2007
Авторский вариант. 02.06.2007. Статья пока нигде больше не опубликована


ПРЕДЫДУЩАЯ

ОКОНЧАНИЕ


Первый шаг: 7.х – выход на средний рынок

Строго говоря, подготовка выхода "1С" на lower-midmarket началась одиннадцать лет назад, когда летом 1996 года фирма представила свой первый продукт нового поколения. Примечательно, что это была не традиционная "1С:Бухгалтерия", а "1С:Торговля", изначально ориентированная на многопользовательскую работу. Отметим и то, что ни о какой технологической платформе 7.0 тогда и не было речи – не потому, что не было самой платформы, а потому что "1С" не хотела в те времена использоваться подобные "громкие слова, считая, что технические вопросы – это сугубо внутреннее дело фирмы*. Тогда же, для этого продукта впервые в дополнение к файл-серверному варианту системы появился двухзвенный клиент-серверный, реализованный на базе СУБД Btrieve, на смену которому два года спустя пришла система в составе "1С:Предприятие" 7.5 и MS SQL Server 6.5.

А за точку отсчета начала серьезной работы на lower-midmarket, наверное, стоит принять лето 1999 года, когда на рынке появились "1С:Предприятие" 7.7 и MS SQL Server 7.0 (известный в те времена проект "777"), в применению, которых уже "созрели" и заказчики и партнеры.

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

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

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

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

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

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

В начало статьи

Шаг 2: версия 8.0, переход на upper-midmarket

В отличие от 1СП7 при создании платформы 8 (1СП8) задача повышения ПиМ была уже определена в качестве одной из главных.

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

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

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

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

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

Соответственно, масштабирование серверной части (сервера+СУБД) обеспечивалось двумя взаимодополняющими вариантами:

Появление 1СП8 позволило "1С" начать публичное обсуждение вопросов ПиМ своих технологий. Эта тема была обозначена уже при объявлении бета-версии в марте 2003 года (см. PC Week/RE № 13/2003, с. 36), когда были впервые представлены и результаты проведенного нагрузочного тестирования, в том числе и по 7.7 (рис. 3.1). Тут хорошо видно, что для 7.7 клиент-серверный вариант имеет не очень значительное преимущество перед файловым. Отметим и то, что архитектурные новшества 8.0 проявляются именно для трехзвенной клиент-серверной конфигурации.

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

Более детальное исследование ПиМ было выполнено фирмой "1С" уже после выпуска рабочей версии 8.0 (см. PC Week/RE № 9/2004, c. 44). В целом результаты испытаний достаточно хорошо показывали (рис. 3.2) не только преимущества архитектурные преимущества 8.0 перед 7.7 в плане повышения производительности для одной и той же аппаратной конфигурации (см. графики 7.7 и 8.0-1), но также существенные возможности масштабирования 1СП8.

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

И, наконец, данные еще одного нагрузочного тестирования были представлены в феврале 2006 года (см. PC Week/RE № 14/2006, c. 37). Но в данном случае речь шла не о платформе (как в предыдущих двух), а о флагманском корпоративном прикладном продукте "1С:Управлении производственным предприятием". И тут изучался не вопрос масштабирования, а только производительность (для одной аппаратной конфигурации) в различных нагрузочных условиях. За счет чего же достигается масштабируемость на уровне сервера 1СП? Для ответа на этот вопрос нужно посмотреть, что же делает этот компонент. Тут можно выделить три основные функции:

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

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

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

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

В начало статьи

Шаг 3: Версия 8.1 – кластерный сервер

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

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

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

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

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

Рис. 3.3. Структура кластера серверов на базе “1С:Предприятия 8.1”

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

Один из представленных там тестов показывает преимущества работы 8.1 по сравнению с 8.0 даже в случае использования одного компьютера-сервера (рис. 3.4)**. Здесь видно, что у 1СП8.0 при числе тестовых пользователей более 100 начинается заметная деградация общей пропускной способности системы, а при нагрузке более 150 этот показатель просто перестает расти. В тоже время для 1СП8.1 продолжается практически линейный рост производительности.

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

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

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

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

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

Рис. 3.6. Возможность масштабирования сервера "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С" заявили, что они будут реализовываться в виде ближних и дальних планов (см. PC Week/RE 9/2006, с. 1). Ближние планы были выполнены в виде выпуска 8.1, а на мартовском семинаре уже был представлен прообраз следующего шага в виде проекта "управляемое приложение" (УП). Какой номер получит новая версия платформы – пока неизвестно, но по предварительному графику, ее бета версия может появиться уже нынешним летом, а окончательная – к концу текущего года.

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

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

В начало статьи

Продолжение