Оптимизируем и удешевляем нагрузочное тестирование 1С с помощью современных технологий

30.07.25

База данных - HighLoad оптимизация

Рассказываем о том, как с помощью облачных технологий и подхода «инфраструктура как код» можно значительно упростить и удешевить нагрузочное тестирование 1С. Автор делится кейсом реального проекта, архитектурой решения и инструментами, которые использовал в работе.

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

Меня зовут Овчаренко Дмитрий, я технический архитектор. С 1С я работаю уже более 14 лет. Последние пять лет плотно занимаюсь вопросами DevOps и управлением качеством кода, разрабатываю собственные инструменты и контрибьючу популярные проекты. Например, вы могли видеть меня в списке контрибьюторов jenkins-lib, BSL Language Server, Vanessa Automation и так далее.

Я работаю в компании «Корус Консалтинг», у которой 15 различных направлений, и хотя мы работаем не только с 1С, именно эта практика самая большая по численности сотрудников. Наши проекты, как правило, очень крупные.

 

 

Вот список наших клиентов – уверен, большинство из них вам знакомы. Это крупные проекты, и они ставят перед командами нестандартные задачи, требующие креативного подхода.

Именно решение одной из таких задач и подтолкнуло меня к разработке фреймворка, о котором я расскажу.

Для тех, кто с нагрузочным тестированием не знаком, я коротко расскажу о его специфике и особенностях.

 

Специфика нагрузочного тестирования 1С

 

 

Тест проводится с помощью расширения 1С:Тест-центр – это стандартный подход. Оно встраивается в базу, в нем пишутся обработки, которые потом должны выполнять виртуальные пользователи.

 

 

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

 

 

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

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

Далее я сосредоточусь на инфраструктуре и проблемах, с которыми, уверен, многие сталкивались.

 

Проблемы с ресурсами

 

  1. Когда мы проводим нагрузочный тест, очень сложно выделить достаточный объем ресурсов. Если это существующая система, нам нужно выделить контур, аналогичный продуктиву, а то и более мощный. Это первая проблема.

  2. Даже если ресурсы есть, их нужно настроить: установить все ПО, настроить мониторинг. Когда мы делаем это для заказчиков, это трудоемко как для нас, так и для них, потому что нужно задействовать специалистов, согласовывать наряды со службами инфраструктуры и так далее. Это довольно сложно.

  3. И третий пункт, о котором мало кто говорит, но который, по моему мнению, значительно снижает эффективность, – это простой стенда большую часть времени.

 

 

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

  • Когда мы готовим этот проект,

  • Когда мы проводим несколько итераций нагрузочного тестирования,

  • Когда мы пишем отчет.

Стенд нагрузочного тестирования мы создаем примерно в конце фазы подготовки. А когда все сервера уже развернуты, то они остаются развернутыми и занятыми на протяжении всего проекта. То есть мы не можем использовать их для других целей.

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

 

Кейс заказчика и идея решения

 

Перейду к кейсу нашего заказчика: он довольно стандартный, и с подобным сталкивались многие.

Мы делаем для этого заказчика проект на базе УТ 11. Сейчас он работает в продуктиве на Windows, но бизнес расширяется, и через несколько месяцев в базе будет примерно в 5 раз больше пользователей. Поскольку заказчик планирует переезд на Linux, необходимо понять, как это все будет работать в Linux.

База сильно доработана: есть функционал управления товарными матрицами, очень большой ассортимент, сложная логика ценообразования – нагрузка высокая. Из тысячи пользователей 50 могут нагрузить базу так, что мало не покажется.

Для тестирования нужно не только создать аналог продуктивного стенда, но и 16 терминальных серверов.

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

Тогда появилась другая идея – поднимать стенд в облаке только на время выполнения тестов. То есть использовать ресурсы только на короткий период, чтобы они не простаивали, и мы за них не платили.

Идея хорошая, но, очевидно, довольно проблематична в реализации, потому что:

  • Разворачивать стенд с нуля на каждой итерации – очень трудоемко,

  • Повторяемость каждой итерации не гарантирована, ведь где-то что-то могли забыть доустановить или донастроить,

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

 

Рождение концепции

 

Соответственно, родилась концепция, которую я сейчас кратко опишу. Когда идея созрела, я понял, что нужно делать, мысленно попросил коллег «подержать мое пиво» и ушел разрабатывать репозиторий – описывать инфраструктуру нагрузочного теста в виде кода. По сути, наш стенд создается из этого репозитория и применяется в облаке.

 

 

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

Мы применяем наш репозиторий, содержащий код инфраструктуры. Это и есть IaC – инфраструктура как код. Прогоняем нагрузочный тест. В конце получаем логи, отчеты и скриншоты для последующего анализа. А стенд удаляется – мы за него не платим. Попользовались, оплатили, удалили.

 

 

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

 

Архитектура облачного решения

 

 

У нашего департамента есть аккаунт в облаке Selectel, на схеме он выделен красной рамкой.

 

 

Зеленая область – это область, где мы держим выделенные серверы, такие как сервер лицензирования и файловый сервер.

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

 

 

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

Помимо очевидных серверов баз данных и серверов приложений (RDP), создаются еще два служебных хоста. Они имеют публичные («белые») IP-адреса, то есть доступны извне, и к ним можно подключиться. Один хост используется для размещения инструментов мониторинга, а второй – это Windows-хост, созданный исключительно для удобства: чтобы можно было на нем вручную открыть базу и проверить что-либо визуально.

 

 

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

 

 

У нас заранее настроен облачный проект – мы создали его и настроили роутинг. Я клонирую репозиторий с кодом инфраструктуры себе на компьютер и открываю конфигурационный файл. Буду называть его «тем самым конфигурационным файлом», потому что в нем хранятся все параметры стенда: количество RDP-серверов, их CPU, объем оперативной памяти, диски и так далее. Файл довольно большой, параметров, может быть, около 50, и это еще не все – есть желание добавить больше.

 

 

Далее, после редактирования параметров, я запускаю простую команду – terraform apply. Подробнее о terraform я расскажу дальше, но суть в том, что эта команда создает серверы в облачном проекте.

Можно представить, что terraform apply – это бригада строителей, которая возводит здания, подводит электричество и воду, но не делает внутреннюю отделку. Отделкой занимается ansible.

 

 

В данном контексте «отделка» – это установка программного обеспечения, настройка и размещение различных файлов и так далее.

В репозитории описаны несколько плейбуков, пронумерованных строго по порядку (например, 00, 10, 25). Пропуски в нумерации предусмотрены для добавления промежуточных этапов, если это понадобится. От человека, проводящего нагрузочный тест, требуется только запустить их последовательно. Параметры уже заданы в конфиге. Мы просто выполняем плейбуки по порядку. Сначала запускается плейбук 00-site.yml, который устанавливает инструменты мониторинга и другие служебные компоненты – всю эту основную, низкоуровневую часть. Далее идет создание базы и другие этапы, о которых я расскажу подробнее.

Когда, например, мы выполнили плейбук 30-start-agents.yml, это означает, что на всех RDP-серверах запущены агенты тест-центра.

 

 

Теперь мы можем подключиться к Control host через RDP, открыть базу и, предварительно настроив тест, запустить нагрузочное тестирование.

После завершения теста запускается последний плейбук 99-report.yml, который обходит все узлы стенда, собирает всю информацию и сохраняет ее локально.

 

 

После этого мы можем смело выполнить команду terraform destroy – все облачные серверы будут уничтожены, мы перестаем за них платить, в облаке от них не остается никаких следов, и все довольны. А мы переходим к анализу полученных результатов. Как я уже упоминал, все результаты сохраняются локально.

 

Используемые инструменты: Terraform и Ansible

 

.

 

Terraform. Это стандарт де-факто в области облачной инфраструктуры – продукт, который позволяет развернуть серверы и многое другое, используя всего один файл конфигурации. Он параметризуется с помощью «того самого конфига»: все необходимые параметры прописываются в нем, и Terraform создает нужные серверы.

 

 

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

 

 

Эту задачу он решает с помощью файла Inventory. Это, грубо говоря, очень продвинутый аналог файла hosts. В нем можно группировать машины и указывать различные дополнительные параметры.

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

 

Детали настройки серверов и базы данных

 

СУБД

При развертывании кластера на уровне СУБД устанавливается версия Postgres Pro, указанная в конфигурационном файле. Можно выбрать версию 15, 16 или любую другую – она будет установлена автоматически.

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

Затем загружается база данных. Мы берем файловый сервер, который уже примонтирован к служебному хосту СУБД. Мы знаем, откуда взять в нашем случае DT-файл. Загружаем с помощью ibcmd, выполняем VACUUM ANALYZE и активируем расширение pg_stat_statements на этой базе.

 

Кластер 1С

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

На каждом узле 1С мы собираем кластер – точнее, включаем серверы в кластер. Выполняются соответствующие скрипты. Если серверов в кластере больше одного, назначаются ТНФ для централизации журнала регистрации и полнотекстового поиска.

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

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

Далее добавляем базу в кластер – операция тривиальная.

Затем мы запускаем базу в специальном режиме со специальной обработкой, которая формирует JSON-файл с соответствием между именами таблиц БД и именами объектов 1С по каждой таблице.

 

RDP и тонкие клиенты

На RDP-серверах мы аналогичным образом загружаем и устанавливаем тонкие клиенты 1С. Причем, чтобы не качать их на каждый сервер отдельно (их может быть много), мы сначала скачиваем дистрибутив на один хост, а затем копируем и устанавливаем его на все RDP-серверы.

Также база добавляется в список баз – просто для удобства.

Регистрируем консоль кластера, чтобы не запускать соответствующий bat-файл вручную для подключения к кластеру.

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

 

Организация мониторинга

 

 

Чуть подробнее о том, как устроен мониторинг. На служебном хосте Bastion размещены центральные компоненты средств мониторинга: Prometheus, Logstash, ClickHouse и Grafana. Это довольно стандартный стек для мониторинга 1С.

Что касается экспортеров, то здесь тоже используется стандартный набор:

  • node_exporter для Linux-машин,

  • win_node_exporter для Windows-машин,

  • postgres_exporter для СУБД,

  • prometheus_1C_exporter для сбора метрик 1С через RAS.

 

 

На каждом сервере 1С ведется технологический журнал, и для его обработки установлена программа Beats. Это компонент ELK-стека, который следит за изменениями в файлах техжурнала и отправляет каждую запись в Logstash. Перед отправкой она собирает многострочные записи техжурнала в одну строку.

 

 

Logstash не просто принимает эти записи, но и использует словарь замен, который для некоторых полей техжурнала меняет имена таблиц на термины 1С. После обработки данные сохраняются в ClickHouse, который служит источником данных для Grafana, а в Grafana можно визуализировать практически любую информацию.

 

 

Вот как это выглядит на практике. Хочу подчеркнуть, что эта панель мониторинга становится доступна сразу после развертывания стенда и выполнения первого плейбука. Никакой дополнительной настройки не требуется – просто запустили плейбук, открыли браузер, и все работает.

 

 

Здесь мы мониторим сессии и лицензии.

 

 

Длительность серверных вызовов и обращений к СУБД.

 

 

Здесь показана визуализация данных из ClickHouse – длительное суммарное ожидание на управляемых блокировках, сгруппированное по областям. Обратите внимание, области блокировок представлены в терминах 1С, прямо как в конфигураторе. Мне кажется, это очень удобно и круто.

 

 

Длительность вызовов на примере реального проекта нагрузочного тестирования. Тут видны отдельные точки (короткие вызовы) и некий «забор» – это работа тех самых пользователей, которые умеют очень эффективно нагружать базу.

 

Сбор результатов тестирования

 

 

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

 

 

Происходит выгрузка логов PostgreSQL.

 

 

На основе этих логов формируется отчет pgbadger. И здесь еще одна киллер-фича: в pgbadger также реализована замена технических имен таблиц на термины 1С.

 

 

Далее используется утилита, которая проходит по дашбордам Grafana и делает скриншоты с каждой панели, сохраняя их в PDF-файл.

 

 

Отдельно из логов PostgreSQL с помощью специального Python-скрипта извлекаются планы запросов. И в этих планах тоже присутствует замена имен таблиц. Планы запросов сохраняются в отдельный каталог, причем файлы именуются так, что самый медленный запрос будет первым в списке. Вам остается только открыть нужный файл в текстовом редакторе и вставить его содержимое на сайт explain.tensor.ru – и вы сразу увидите план запроса, представленный в терминах 1С.

 

Проблемы и нюансы, возникшие при разработке

 

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

Еще один нюанс тест-центра: мои коллеги проводили тест на 10 000 пользователей и столкнулись с тем, что 1С:Тест-центр очень медленно запускает виртуальных пользователей.

Также возникли вопросы с лицензированием. Когда я завершал свой проект, мои коллеги из другого проекта уже использовали мой фреймворк для тестирования на 10 000 пользователей. У нас было всего 10 000 лицензий, и если бы тесты запустились одновременно, обе итерации пришлось бы признать недействительными. Мы вовремя это заметили и перепланировали работы. Это важный момент – ресурсы используются совместно.

При именовании объектов в облаке мы столкнулись с тем, что в Selectel определенные виды объектов должны иметь глобально уникальное имя. Эта проблема проявилась снова при параллельном тестировании двух проектов, и для ее решения пришлось добавить в конфигурационный файл новый параметр – префикс. Теперь все объекты в облаке для каждого проекта имеют уникальный префикс.

Что касается облачного провайдера, то мы используем Selectel. Однако можно использовать практически любого провайдера, у которого есть Terraform-провайдер. Важно, на какой технологии он основан. Например, если бы нам нужно было переехать на VK Cloud, где также используется OpenStack, адаптация наших Terraform-файлов была бы минимальной. А вот для Яндекс.Облака, у которого свой Terraform-провайдер, потребовалась бы переработка кода. Но не думаю, что это заняло бы больше двух дней.

Также стоит учитывать дистрибутивы операционных систем. Мы тестировали на Linux, используя Astra Linux и Red OS в разных проектах. Если в будущем понадобится работа с какой-то экзотической сборкой, скрипты также придется адаптировать.

 

Результаты и выводы

 

Мы сократили расходы на вычислительные ресурсы в 7 раз. Представьте, если стоимость инфраструктуры на весь период вашего нагрузочного теста составляет 700 000, то с использованием нашего подхода вы заплатите всего 100 000. Это ощутимая экономия.

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

Бонусом, о котором я упоминал вскользь, стала стандартизация. Теперь мы можем запускать другие проекты на этом же фреймворке, значительно упрощая себе работу. Как я уже говорил, мои коллеги успешно провели нагрузочный тест на 10 000 пользователей с помощью этого фреймворка.

 

 

Визуально разницу в стоимости ресурсов можно представить так: в случае фиксированного подхода (синяя линия) мы создаем все ресурсы и платим за них до конца проекта. В случае динамического подхода мы платим только в момент использования.

 

 

Если вы не знаете, для какой задачи применить облако в вашей ситуации, вот вам подсказка: нагрузочное тестирование, CI/CD (агенты в облаке, поднимающиеся по требованию) и различные интеграции, включая микросервисные приложения – все это решаемые в облаке задачи.

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.

Вступайте в нашу телеграмм-группу Инфостарт

См. также

DevOps и автоматизация разработки Тестирование QA Программист Пользователь 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Зарплата и Управление Персоналом 3 и версии КОРП: 3.1.30.230.

3360 руб.

05.08.2024    3732    21    1    

15

Тестирование QA DevOps и автоматизация разработки Программист 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.17.168.

2400 руб.

04.07.2022    10899    44    1    

35

Нейросети Рефакторинг и качество кода Тестирование QA Программист 1С v8.3 Бесплатно (free)

Искусственный интеллект в код-ревью – это не фантастика, а реальность, которая уже сегодня помогает разработчикам улучшать свои проекты. Расскажем о том, как ИИ может автоматически находить баги и предлагать улучшения, экономя ваше время и ресурсы.

11.03.2025    10345    mrXoxot    53    

56

HighLoad оптимизация Программист 1С v8.3 1C:ERP Бесплатно (free)

Приведем примеры использования различных в динамических списках и посмотрим, почему это плохо.

18.02.2025    6760    ivanov660    39    

61

HighLoad оптимизация Технологический журнал Системный администратор Программист Бесплатно (free)

Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.

24.06.2024    9291    ivanov660    13    

62

HighLoad оптимизация Программист 1С v8.3 1C:Бухгалтерия Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    7304    spyke    29    

53

HighLoad оптимизация Инструменты администратора БД Системный администратор Программист 1С v8.3 1C:Бухгалтерия Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих запросов на sql, ожиданий, конвертация запроса в 1С и рекомендации, где может тормозить.

5 стартмани

15.02.2024    17596    327    ZAOSTG    100    

123
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. user-z99999 76 30.07.25 16:39 Сейчас в теме
Расскажите про тестирование подробней.
Запустить 1с, открыть форму записать значение, закрыть форму, закрыть 1с - это скучно.
У каждого пользователя своя работа, насколько точно и полно вы её повторяете в тестировании?
С боевой базы берете профиль работы пользователей, что они делают?

Зачем нужна аренда сервера? Чтобы угадать размер жесткого диска и оперативной памяти сервера для нового проекта?
Как сильно реальность отличаться от виртуальности (ваших тестов)?
2. ovcharenko.di 109 30.07.25 17:21 Сейчас в теме
(1) очень интересные вопросы задаете!

По первому абзацу отвечу так: мой доклад был не о методологии проведения НТ, поэтому и материала по этой теме у меня нет.

Кстати, моя коллега подала заявку на IE 2025 с докладом как раз по **методологии** НТ (https://event.infostart.ru/2025/agenda/2444833/). В программе есть и другие интересные доклады по НТ от других спикеров, мне самому будет очень интересно послушать.

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

А так да, путем запуска одного и того же нагрузочного теста на разном железе (в том числе на разных моделях процессоров, разных дисках и разном объеме RAM) можно подобрать (именно подобрать, а не угадать) оптимальные параметры. Поэтому подход IaC и оказался полезен: при его использовании такие эксперименты даются очень "дешево".
По поводу отличий стенда от реального железа: да, конечно, они есть. Признаться, я потратил значительную часть времени на сведение характеристик облачного железа и железа заказчика. И все равно это был некий компромисс. Но тут надо понимать, что были и другие альтернативы: 1) не делать НТ вообще, 2) отсрочить переход на Linux и ждать железа для НТ от заказчика, 3) провести тестирование не на 1000, а на меньшем количестве пользователей и как-то экстраполировать результат на 1000.
Понятное дело, что ни одна из альтернатив мной серьезно рассматривалась. Так что незначительное несоответствие в железе мы просто приняли как факт.
3. user-z99999 76 30.07.25 17:47 Сейчас в теме
(2) Базы 1С типовые или самописные?
5. ovcharenko.di 109 31.07.25 18:42 Сейчас в теме
(3) нам с разными приходилось работать: с сильно доработанными типовыми, отраслевыми, самописными на БСП
4. capitan 2538 31.07.25 16:59 Сейчас в теме
Задумка богатая, но как обычно есть нюанс.
Когда будет переход, второй комплект оборудования все равно понадобится и не факт, что админы его настроят так же как и облако.
Я бы на этом не экономил на месте клиента.
Тем более линуксы, это плата только за железо
Он вам больше отдал за вот это чудесное решение
6. ovcharenko.di 109 31.07.25 19:02 Сейчас в теме
(4) если админы заказчика настроят оборудование не так, то мы это легко проверим, потому что все параметры облачного стенда известны и записаны (начиная с идентификатора образа ОС, заканчивая pg_settings)


Я бы на этом не экономил на месте клиента

А там не в деньгах было дело, а в скорости предоставления железа. А на него же еще установить все надо! Это же сколько "бумаги" надо извести на наряды и их согласование. А ведь еще как всегда не с первого раза получится сделать так, как было спроектировано. Да и спроектировать могли с ошибками. Короче, в забюрократизированных крупных компаниях подобную задачу легко можно целый год делать, если делать "по-старинке".
8. capitan 2538 01.08.25 09:48 Сейчас в теме
(6)
если админы заказчика настроят оборудование не так, то мы это легко проверим

вы недооцениваете возможности типового админа
+есть такие вещи как авторизация ОС например, они не помешают при тестировании
7. Yura77 30 01.08.25 04:10 Сейчас в теме
Аэрофлот ещё добавьте в список клиентов
Для отправки сообщения требуется регистрация/авторизация